Editor Demo

Not just some text and a few pictures. Here is a basic version of the editor running. Its not ready for any kind of public testing yet, but I did make a video demo showing off a few of the things that are/almost done.
The demo shows a number of things:
-The basics of how building ships/assemblies will work
-The current GUI
-Saving and loading

As I add content to the program, I will periodically release a video demo. Once I think its bug-free and content rich enough, I will release a limited alpha.
Let me know what you think in the comments!

What this project is about.

After reading through all my previous blog posts, I realized I still had yet to explain in depth what this project is!

There are two core goals for this project:
-To create an environment that can be used to create and test complex dynamic AI's.
-To create a game environment that gives the user the most freedom in terms of control over their own abilities in the game.

In order for the first of these goals to be met, there needs to be a well developed core infrastructure to the game. In other words, the environment has to be tried and true before development of an AI can begin.

The second goal, is a bit more ambiguous. To explain it a little bit clearer: what I want to do, is allow the user to create and experience what it is like building and designing assemblies for use in space. My goal is to have it to such a level, that you could design your own missile, carry it with your ship, and fire it. My goal is to allow the user to create a ship that can do things it was never meant to do, like disassembling mid flight to avoid an anti matter missile, or split your ship into two and control both ships as if they were one. My goal is to allow the user to create their own AI ship if they so desire. These are the things I want to allow the user to do, and in a (somewhat) realistic fashion. Your ship wont fly because it just does; it will fly because you installed antimatter reactors directly next to thrust vectored engines. It will shoot because you attached some huge capacitors next to your customized high power feed laser. I would like it even possible to have multiple people controlling the same ship, star treck style.

These goals are a bit ambitious, you may say: "okay that's cool, but how are you going to do all that?" and I say: "one step at a time".

The first steps involved concept art (mostly in my graph paper notebook) and background planning; ie how to allow the user to do these things.

I came up with idea of using "modules" to build the ship out of. Modules are great because they are stand alone, can be used in complex configurations, and they can allow complex behaviors. As of now they all connect with triangular sides, but the code is in place for any kind of polygon to be used as a connection side; as long as it connects to a side of the same type.

The different kinds of modules that could be used:
-Engines
-Power Generators
-Laser Weapons
-Shield Generators
-Shield Emitters
And anything else that ends up being cool

I also plan on each module to have customization options, like the ability to balance how much power goes into the wavelength of the laser, and how much into the amount of photons fired. The goal is to have as much customization as possible while still keeping things balanced. Also, i would like to make it possible to place things on top of the modules, that are not actually modules. More like accessories. This would let you coat everything with armor, or attach antenna and other sensors in various places on the ship.

So that's the goal of this project. Now, anyone have an idea for a name? I originally called it polyhedra wars because many of the modules I had in place resembled polyhedra (ie octahedrons, tetrahedrons etc). But modules are not all going to look that way, many are going to have their "insides" shown. Anyway, let me know what you think in the comments.

Concept ship design, its hard to draw polyhedra by hand!

Unity GUI - Graphics

There are two parts to making a GUI in unity; the graphics and the programming. These two parts mix a bit, but when I say graphics here, I mean the GUI skin. Unity's GUI system is a bit tricky to work with, and making your own customized skin can be a bit daunting. I realized that the default unity GUI wouldn't work, not even for testing, because all its controls are translucent and very dark. Most of the time in space, there are really dark colors. The default unity GUI tends to become nearly invisible against this kind of backdrop, and that's when I realized that I would need to make my own. If you want to see the results, skip to the bottom.

Note: before you go ahead and make a full blown GUI skin; make sure none of the ones on the asset store will do. There are a lot of decent skins for $5, and even some nice free ones. I neglected to do this, and as a result spent a lot of time making my own skin when it may not have been necessary, though it was an interesting experience.

Once you have come to the conclusion that the unity skin, the free skins, and the non-free skins are not options, then that's when you make your own. Before you even get started though, draw it out on paper, preferably graph paper. You do this so that when you finish making the skin, you don't go back and realize that 30+ images need to be redone. This also helps prevent redoing a simple image 20 times to get it just  right. Once you got a good idea of your skin down on paper, you can get started with the computer stuff.

One thing that needs to be taken into account, is how unity handles images. I spent 2 hours trying to figure out why my "crisp clean images" were all blurry before I realized the import setting : "texture type" of each image had to be set to GUI. The other settings can also be important depending on your image type. Its not usually to hard to figure out settings that work, the important part is making sure texture type is set to GUI.

The filter mode handles how the image is stretched. Point just scales the pixel, biliniar is good for textures with gradients, triliniar does something with mippixels. All this info is available in detail at the Unity Texture 2D documentation page found here.

After all the import settings are taken care of, the next step is to setup a test script that shows off all the GUI elements that you plan on using. I followed the tutorial here, which has a nice little script for this purpose, though it doesn't use all the elements (I made this; it has all the elements. The code is a bit messy but its only for visual testing). The tutorial also shows how unity handles stretching of textures at different places to make small textures seamlessly scaleable. The tutorial doesn't cover everything but its good for an introduction. After finishing it, its not that hard to just follow the same pattern of making images with the right borders, then changing the border setting in the skin to make it fit right.

Some elements do not follow the same pattern though and need a bit more work to get working. Notably is the toggle. When you make the toggle, make sure that you leave a section of pixels to the right for whatever you want stretched beneath the toggle text. Usually this is just blank alpha.

<-- That bit of white to the right is alpha used by the toggle text.

When making a skin, its also good to have the default textures available for reference, they can be downloaded from the asset store for free, and also on the unity forums here.

For scroll bar buttons, you need to make sure the fixed width and height are set above zero; otherwise they will not show up in your skin. Only do this if you actually want them to show up.


After finishing the last GUI texture, its a bit satisfying to see a nice GUI when you are done. I will not say its easy, but it can be rewarding to make your own custom skin. Below are some pics:

I ended up making two versions, a translucent version, and a solid version. The translucent skin looks like a better fit, so I will likely go with that one. Making the skin translucent isn't that hard, especially for flat styled skins. You simply take each solid texture, copy the solid color, adjust the alpha value to about half (I used 125 on 0-255 scale), use a paint bucket tool on replace mode where you took the color from, then save the image. If by any chance you don't want to make your own, and you really like this skin, its on the asset store here.

That about concludes making a unity GUI skin, next comes the programming. This was more of a list of common pitfalls, or at least ones I fell into, then a GUI tutorial. There are lots of tutorials on youtube and in many other places, so don't just go by this if you decide to make your own skin.

Planning a project and parsing texts

In my experience it is always best to work on the part of the project you are least confident in your ability to finish. The reason being that you do not want to finish everything else and find that you are, indeed, incapable of completing that particular part. While working on all my projects I have kept this in mind. There are other benefits as well; if you are capable of finishing that part, and you do finish it, then you got the hardest part done first. In addition, this helps keep you encouraged throughout the projects completion because every step brings you much closer. It could be argued that it makes it harder because starting with the hardest part is discouraging. But it will have to be faced at one point or another anyway.

This way of working on projects is best used when you already have experience, because otherwise your project is mostly a learning experience and may not be finished. Working on the toughest part of a project without at least some experience, can be much more daunting, and also much more discouraging.

The reason I bring this up, is because working on my project by using this strategy has lead to some interesting decisions. For instance, the next part of my project was going to involve the gui, so I planned it out by drawing what I wanted it to look like when it was done, and how I wanted it to function. Next I planned the lower level stuff, like how It was going to have that functionality in the first place. And finally, when all that planning was done, I looked at what was the most important and what was most difficult and worked on the next step that most balanced these two.

The gui that I planned was entirely for the ship editor aspect of the game. This aspect is what I consider the most important because it is what makes my game unique, and as a result is what I want the most polished. Since everything else is in place it is also the last step before there can be another release, so it makes sense to work on the ship editor part next.

The gui's layout has parts you can select to build with on the left, and on the right of the screen is the interface for configuring controls or activation keys. Now, because the editor is such an integral part of the game, it will be able to be accessed during flight, allowing real time editing of the ship. The user will be able to switch back and forth between the editor and the flight modes even during a battle, though during a battle would be dangerous.

At default the windows will pop out when the user hovers the mouse at that edge of the window. This makes it easy to access what you need and get the display out of the way quickly. In addition, there will be a toggle that when toggled, will keep the window out even when the mouse is not hovering over the window. Each icon represents a module that can be placed on the ship, or as I like to call it, assembly; because it may not necessarily be a ship that is being built. The list of modules also has a list of tabs at the top, to help categorize the modules.

This gui is nice and all, but I also needed as convenient a place as possible to store the available modules in the unity project. I also wanted something that was easily changeable and even moddable in the future. At the time I decided this, my unity project was in dire need of "housecleaning", it had many unorganized files and resources that were not even being used. I figured it best to start a new project and import what I needed as I went. After this was done, I got to the modding/module organization system.

The system works like this: in the project and build, there will be a folder with a list of .module files. The files can be in sub-folders and really in any order as long as they are in the modules folder. When the game is started, all these module files will be parsed for their contents. Each module file contains a list of all the aspects of the module, and in the future, references to texture and mesh files. In the meantime prefabs already in the built project will be referenced. Any of the .module files can be edited by a text editor, or new ones can be added. Parsing these files appeared the most difficult, as a result, that is what I worked on next.

First I planned out the syntax of each module, then I did a ton of research on the String class in the msdn libraries. For fellow unity developers; msdn is the place to go for all lower level code references. I also looked up how to parse a string in google; this provided a few handy results like: reading a text file line by line, and one method of text parsing. These weren't the only results, but they were the most useful. Anyway, how you parse a file mostly depends on the layout and syntax of it. So for my .module file I decided to read each line one at a time using the method described in the first link. Then I split each line along the = sign using String.Split. Properties on the left side were used to describe where to put the value described on the left. In some cases there were values that were compound. Take for example the custom Side type, it has a position, rotation, name, and variable for the number of sides(polygon sides, not Side type objects). (This is used to describe how to handle the connection sides in the game, ie what connects two objects together) For this type, I declared Side, followed by { and all the variables followed by a }. The text parser, when it read "side" would go into a corutine, reading all the lines until it got to the }. Then the parser would resume its normal operations.

The main task of the parser is to produce a list of modules that the gui can list as icons and the user can place as modules. In addition, only modules loaded this way are used to load a save game, or a saved assembly.

Now...time for that gui.

A word on Quaternions and doing complex rotations

Its been some time since I last made a post here. Not for lack of working, but rather of lack of something to post. For the past several months I have been working quite a bit in Unity3d on Quaternions.

I will talk about that below; the first point is that I haven't made many posts here. To keep whoever bothers following this blog on my project interested and up to date, I will write a blog post (to the best of my ability; post is still not guaranteed) every Saturday with some info on what has been worked on/ updated etc. And for those that even that is not enough, I plan on making a twitter account with daily updates on progress. Now as a warning to those who wish to read on, below is a rant/very long post on quaternions which some may find fascinating and others boring.

Quaternions are what unity uses to describe rotations. Unity also has something called eulerangles, which  has the more easily interpreted 0-360 notation that we are used to using for rotations. The main reason unity uses quaternions as the underlying way of calculating an objects rotation though, is because quaternions don't suffer from something called gimbal lock. The major disadvantage of quaternions, is that their representation is very complex, so much so in fact that quaternions are best simply referred to as variables instead of their individual values. For a mathematical explanation of quaternions, here is a good explanation that might give you a little bit of an idea of what the values actually mean. However, the explanation went a bit over my head, and the variable method of representation is sufficient.

My problem with quaternions started when I tried to do something a bit complex, and all at once. The idea was to add a hook function for rotating one side of a module to be facing another side of another module.  So I setup something simple for selecting the sides that needed to face each other. I set it up so all that was needed was the new rotation to rotate too.

Each object stores its side as a rotation and position relative too the center of the module it is on. This greatly reduces lag from object creation and destruction compared to when I had an entire GameObject representing each side, but it added a complication; instead of rotating one module to be facing another, I had to rotate one rotation of a modules side to be facing another rotation of another modules side.

In the below example side one is selected to rotate facing side 3, and the goal was to rotate it so it looked like side 2; both sides plains are parallel, and the corners of the modules are aligned.

My first solution to get a rotation that would rotate in this way was to try rotating all at once, and i came up with this line of code:  

gameObject.transform.rotation*Quaternion.Euler(orbit))*(Quaternion.Inverse(Quaternion.Euler(side.orbit+Vector3(0, 0, 180)))

note: orbit is the sides relative rotation in euler angles to the module it is on. Quaternion.Euler converts it to a quaternion.

This line is the result from hours of trial and error and was by no means the most efficient time I spent. However, it still worked to provide the desired rotation. I am honestly still not entirely sure why it works, but it does, so I was fine with it. That is, until I tried to rotate the resulting rotation. 

At some point I realized I needed to rotate the returned rotation, the reason being that if you connect modules into a "loop" where there are connections connecting in a loop pattern, the assembly will destroy itself. In the example below the red shows the "loop" that would be created. The blue shows the corner of the side that would rotate toward the other corner of the other triangle if the above line of code was used to provide the target rotation.

If a joint is added with this rotation as the target, then the assembly literally flies apart. So as a solution I attempted to use the angle axis function to rotate the resulting rotation in a way that would return the correct target rotation. Only problem was, using the angle axis function seriously messed up the rotation; it rotated on some arbitrary axis as a result of the original rotation calculations. I spent a long time attempting to rectify this, but nothing worked and I was forced to attempt a different approach.

I was back to square one and I did what I should have done from the start: rotate in steps. Eventually I came up with a rotation that would align the faces of the two objects, which was really a modified LookAt function. From there I was able to use angle axis to rotate the previous rotation to the final rotation. This resulted in the desired rotation of the modules.




To sum up: Do quaternion rotations in steps; it will save you a LOT of trouble, and will certainly not cause you to learn a million things about quaternions you never needed to know.

note: the last part of the above sentence is not guaranteed not to occur. 

Edit: The details (with the actual code) on how this was solved can be found here.