just about every tutorial says that when you start in game development you need to start small. Then progress with experience. We however started really big… bigger than both of us imagined.. I was confident that with my past experiences it could not be THAT hard…
…turns out I was wrong. I think that at this point about 85% of the originall Triplane: Furball code has been refactored or completely rewritten. It’s the way you yourself can see that progress has been made. When you are looking through your old code and constantly asking: “Who was the monkey that wrote this and what was going on in his head?” it’s definitely time for some refactoring :D
Progress means refactoring
In a year, I have rewritten the plane physics from scratch, there are at least 3 versions of the anti-air gun code. Our trooper code has been rewritten once and it’s on the backlog for seconds, bomb physics multiple times etc.. So in my case starting small meant doing “bad code” and then improving on it when the engine and language is more in the first name terms. Well it’s not necessarily “bad code” but it’s messy to read and debug and not much optimized either. If I am not happy with it, it’s gone.
My best example of progress is my love hate relationship with our Menu UI/UX. I had this “tiny” attitude problem towards coding UI, it’s a lot of work to get right and I think the most important element between the user and the developer. In my experience as a gamer, if the user needs to battle through your menu system to get into the game it will wreck the whole experience for them. After multiple revisions I still don’t know if the menu is “right” but after working with it so long and doing it again and again I really start feel committed to it and in secret even start to like making UI’s a little..:P
I really like the style of the inGame UI in Papers please! So it serves as an archetype for our menu and you can really see in the comparison above how it has affected the whole style of our “Menu book”. I really love the notebook style as it seems to fit really well thematically to our game. You can feel it lying around at a table of an hangar somewhere all dusty and torn. (If you haven’t played Paper Please! go do so..Its awesome! Glory to Arstotzka! :)
Delving into code
Looking back at the original Menu and its code I am glad that progress has happened. Every button was it’s own object and menu was “handbuild” in the room editor. Button click changed a room so new room was needed again to be built for every menu “page”. It was the most stripped out menu ever but it served it’s purpose to start the game room.
The main point of having a god object I think is that it runs all the code collectively so you don’t have to find the right object where the code needed is running. So the old menuGOD object really misses it’s mark but it was necessary step for me to learn about the engine and it’s basic capabilities. Menu building started by doing a class diagram and design document. Second one listed all the menu options we wanted and the potential routes. First one showed if our menu routes were unnecessary complicated. Iiro had this idea that there should be a one-click button that would get you straight into the game. Our new skirmish page achieves this in two clicks so it’s really arguable that we need one anymore. The original skirmish page that you can see in the old class diagram had multiple pages and it was lot of back and forth action for setting up the game (It’s a hassle out there! Right?!). All of this was fitted on a single page and I think it was a really good change! :)
Before any rumours appear or any hopes in the matter, I need to clarify the class diagram. Sadly there will be no online functions for triplane: furball as it was and probably still is way over my capabilities with gamemaker and we really need to ship this project in due time. Rebuilding the game with online code implemented would prolong the project indefinitely or at least way too long. Maybe for Furball 2 ;). I also take no responsibility for the accuracy of the class diagram or if it made correctly. It makes sense to me :D
After yet another rebuild the whole menu system was changed to far superior system. The whole thing is built with code and it’s much more dynamic and able to handle different resolutions. Also support for localization is there so its not too much work to implement it in the end. The biggest changes are that the menu is now in one room only and the magic is done with surfaces. Button function is done with the buttonParent object and set in the newMenuGOD. So if I need to change anything at all everything is in the GOD object. There are some special cases which are just easier to do in separate objects. When it’s your project you’re allowed to be lazy now and then as there is no one to bark at you for cutting some corners ;) In comparison the newMenuGOD has about 600 lines of code and the old one has just under 100 lines. Of course it’s not too comparable as the old menu didn’t have nearly as much functionalities and it was all scattered around different objects. So if I would have built current functions with the old menu system there probably would be 3000 lines of unnecessary code :D
In the backlog for the menu, we have animated BG which shows some action packed clips from the game. Also I think that its bit too static currently, all the other devs are creating these cool lively menus which have neat animations and feel much more responsive so there is some work to be done there. There is also a really rare bug occurring that sometimes messes up the clickbox of the buttons so it wont work properly. Also at this current stage you can’t navigate the menu with gamepad. Menus should always work with any input device you can use ingame so as gamepad support is a must so, so are gamepad supported menus.
In the part 3 of this series, I will write about custom controls which have given me the most pain in the lifespan of this project and next week Iiro has the stage again :)