GitHub

Yesterday I was able to get the project up onto a github repository:

https://github.com/qarnac/windexplorer3d

There were several problem I ran into using git with github.  First, it turns out that if there is a git repository already created on github, I need to pull it into my local repository even though the one on github is empty.  Trying to just push or clone my repository onto github will not work.  Second, there is a bug in the JME3 IDE git plugin as far as I can tell.  The git plugin would return authorization errors trying to push onto github, even though the same exact command from a command line would work.  This took me a long time to figure out.

Bring it all together to present

Last Friday I presented my project, along with a poster, to the people of ViaSat and also TeraData.  Since the project is still in development, there were a lot of temporary assets and debugging features turned on.  On Thursday night I went through and replaced most of these to make the game more presentable.

I added a background for the main menu and also changed the buttons a little bit.  Here is the current look of the main menu:

I replaced all the intro scene to the demo level so that it now tells a story to the player about why they are flying around.  Here is the new intro scene:

These are actually STILL temporary assets, since I am not an artist.  However, they are much better than what they replaced.

Finally, I wrapped up a lot of debugging/temporary code to make the game playable.  Things such as turning back on the altitude ceiling so the user cant go up forever, etc.

Fixed the bugs from yesterday

Today I fixed the bugs from yesterday's updates. 

Specifically, I fixed a bug where when the user presses the space bar to "land" and see if that spot is correct, the timer would get stuck until that text went away.  This was caused by a new "textLockout" function I put in yesterday to stop the input of new text to the HUD while something important is being shown.  This also stopped the timer from being redrawn to the screen, though it was still being updated in number(the time was correct, just not visible for 6 seconds or so).  I reorganized how the HUD system worked and it fixed the bug.

Another bug fixed was the string input from the user trying to "land" being super long.  I was unable to think of a good way to auto shorten these inputs to be displayed on the HUD, so I made it so that in the config file where these strings are placed, the maker can add "++" at the end of each line to indicate the next line is apart of that string  also and to add a "\n" in between them.  For example:

This is an example++
of my fix.

Would become "This is an example\nof my fix." in my program, and would display correctly in the HUD.

There were also a few other small fixes, mostly from the win screen breaking some functionality of the sounds.

Lots of work done today

 Today a lot got done.  I made a lot of progress on some of the items what were missing from the game.  For example, there are now indicators on each of the placement objects, telling the player where he/she should fly to, to see if they should build a wind farm there.  This was done in the form of smoke rising from the ground.  Eventually I want to put an object at the origin of the smoke.

Also, there is a win condition now!  That makes this officially a real game now, as you can run out of time and lose the game, or you can find the correct build spot and win the game.  Right now the player just presses the space bar and gets a message on the HUD about the area, but in the future it is planned that the player will land and get a short speech about the area.

There are several bugs that came up from today's building, but I ran out of time to fix them, so that will be for tomorrow.

Finally, you can check out the progress I made today by running my webstart application:

moe006.cs.csusm.edu

some more tools to help make levels

Today I made some more tools to help design levels.  Mostly a bunch of small little changes to make the level designer not have to dig through code so much.  One example of something I added is a debug flag you can set to true to create and texture shapes for the placement objects, which are read in from the config files, and show them in the game.  This will make is far easier to visualize where these shapes are and to make sure the whole map has a shape under it. Here is a picture of two test shapes in my level:

I am also using the height setting that I added last time for these shapes.  Normally these shapes would be invisible and below the terrain, but I make them visible and above the terrain while I'm building this level.

Sounds and More

So today was mostly about sounds.  After making another scene where the user can win the game, I saw a need for some little sound bits to play.  So, I experimented with an easy way to create simple 8-bit sounds.  I have created a few that I will put in the game for now.  Unfortunately Blogger will not let me upload the .wav file I created as a "video", so I will have to find another way to play sounds here.

Also, I went through and replaced some older code that was put in place temporarily to get level one developed.  This old code was hard wired to start level one, making adding more levels difficult.  Now there is a small system that level designers must use so that they dont have to dig through the code so much.  In the Main class, wherever there is a point where the engine must display something that is dependent on what level the user is on (for example: display the game over scene... but which level's game over scene do we display!?!?!) the game engine will call a router method.  This method is just a big switch so that the level designers can make sure the appropriate scenes and what not are displayed for what level the user is on.  Here is an example:

    public void routerForEndLossScene(){
        if(currentLevel == 1){
            show level one's loss scene   
         }//if
        if(currentLevel== 2){
            ...
        }//if
        ...
    }//method

I'm not sure if this is the best way of handling this sort of problem, but it is a simple one.  All these router methods are in the same location, making adding levels somewhat easier.

End game

Today I made an end game!  By that I mean that there is now a "game over" scene that plays when the time runs out in any level.  There also can be different game over scenes for each level, if the designer so chooses and can be made to happen via the introscene config file.

Here is a quick video of the game over screen, along with its ability to return to the main menu once the user has seen the game over screen for a defined amount of time: