Spring It Postmortem: Programming


After releasing my first game, I still do not feel like a programmer.  Real programmers are the people who obsess over efficient code, a real programmer would have done this whole project faster, a real programmer would not have any of the bugs Spring it currently has,  Right?

I know all of the 100+ scripts in Spring It, I can easily debug the problems we experienced, yet the game still has bugs.  Every time I play the game, each bug reminds me that the game, that I, could be better.    One of the saving graces of playing the game, is that it is still fun and after a few levels, I can quickly ignore the bugs.  Realizing that I can honestly say I am proud of the game.

But now, I would like to take a look at some of the systems I implemented that could have been done better, ignored all together, and finally ones that I feel were done really well.

Scripts to be improved

The script that Spring It uses to build the levels from Tiled has a few rules that make it very particular to work with.  As of right now, it can only support having one collector in each level and that collector cannot have anything underneath it.  This isn't a problem for any of our current levels but we could definitely explore that design opportunity if this game goes any further.  Also to that point.  Our collectors and spawner scripts and models are very limited in their implementation.  The spawner can only face right and the collector can only collect from the left.  This really limited level flow and can lead to many levels feeling the same.  If we do plan to expand upon this project in the future, this will one of the first changes I implement to the project.

A few minor scripts that were quickly implemented near the end of the project were the credits auto-scroll, and the script to place the background that can be scene through the window.  Both of these could have used more time to create a slightly more robust system that could be more versatile.  They work for what they are needed for right now, so they will remain that way until I need to improve upon them.

Should have been ignored

I made a post back in December called Revamping the UI: Select Your Level. This who process, while useful as a learning exercise, is not longer used in the game.  We thought to make a really cool Level Select screen, but ultimately it was more work than it was worth.  after we had a second artist look at it, his design was better and much easier to implement.  I think this mistake was ultimately a lack of design direction for elements outside of the game's core entertainment loop.  We will be watching for this problem, as it caused multiple problems throughout development, when we create our next game.

The next system was something I thought would be really cool and would end up saving us work in the long run.  I modified the Unity editor to create tutorial pages for us and track all of the currently created pages. It was harder to implement that I thought it would be, but even more, I learned that tutorial pages need a personal design touch to make them actually look good.  So we ended up ignoring this tool all together and creating the pages by hand.  This was my fault for relying too much on tools.  I should have designed a few tutorial pages first, and then see if they could have been implemented easily by the unity editor.

Time for a pat on the back

The are some scripts that I am really happy with their implementation.  They are flexible and/or small all while getting the job done.  The first two scripts that really stand out are the VFX and Audio Containers that I made.  These containers can be put on any object in Spring It and they will handle all VFX or audio that needs to be associated with that game object.  The scripts themselves are clear and the code is easily changed and added to.  These are definitely scripts I would like to emulate in later projects.

The next system that was very flexible and easy to work with was my centralized Event system class.  This is talked about in detail in my post Revamping the UI: Consider Events Handled, so I will not go into detail about its function here.  The main point I have about it is that it allowed me to go back and add new events very easily. It also allowed me to search through all my current events just by typing eventHandler into Monodevelop.  These two things really benefited me near the end of the project when I needed to come up with quick solutions to the bugs we were experiencing.

Finally,  despite talking about this system in some regard in the things to improve category, I am actually very happy with the scripts I use to build the levels for the game.  It allowed Jeremy to easily update and change levels as he was designing them; based on his feedback I believe the system saved him a large amount of time design wise.

Although I do not feel like a real programmer, looking back at what I have accomplished, this feeling most likely stems from the fact that I now know enough about programming to realize how much more there is still left to know.  My next game will be smoother in implementation and I plan to apply a lot of what I have learned making Spring It.