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.