JAN. 23 – Feb. 2
The final stretch, there were nine days until the presentation, and another day until the playtesting day, so I had to hurry and get everything to work! I had never in my life spent so much time working on something, I must have accumulated about 120 work hours in those days, in addition to the presentation itself, and discussions with teammates. I don’t think calling it a death march would be an overstatement.
I knew that death marches can happen in studios even if managers try to avoid it, so I’m actually glad I had this experience. I would like to never experience this again though, so I absolutely plan on starting on a prototype sooner from now on! To be honest, I did still enjoy it though, I wrote code, fought with UI, made sure the Art assets were all properly aligned to fit the game and it was a real blast.
I also had to keep working on prototype after the presentation, since I still had to implement the deckbuilder and staff cards, as well as all of the card effects…
I managed to implement the first two, and got started on the card effects, but I could not stay awake any longer and only managed to finish about 7 card effects. Implementing the deckbuilder however was well worth it, it felt really good to look at your card collection, and being able to change the cards in your deck!
GUI and Game Mechanics
I had finally started to work on the deckbuilder and the help overlay in the main menu. With the experience I gained with the UI Canvases from the game scene, it took me about 5 hours to implement both of them, although the deckbuilder only visually. I spent another 2-3 hours on the functionality on the deckbuilder later.
I talked with Andreas and Owen about implementation of the card collecting, and we got to the conclusion that implementing it online, with the website and user logins, would not be feasible in the remaining time. Instead we went with Emergency contingency plan Beta23.05f that we would scan codes with our in-app scanner, and save the collected cards locally on the device, through player prefs.
I also had an intense discussion with matthias about our core game mechanic, profit = cashflow or profit = accumulation of cashflow (check this post for more info). I felt that the game at its current state simply wasn’t fun enough, so Matthias and I discussed whether it was still possible time-wise to change it, and whether it would improve fun!
Matthias slept over it and weighed the decision as well, and eventually agreed that it would probably improve the game to change, so we pitched it to the rest of the group, and they agreed.
I realized that people sometimes have very wrong ideas of how long it would take to make something. People suggest a mechanic or idea, with the intention to save you work, but not realizing that another (possibly even better) option takes just as long, or even less time to program!
Things like this were why I had decided to be extremely blunt about suggestions. Especially with artists, because I honestly didn’t have much of an idea about their work process. I would also try to present all options I could think of, with an added explanation of what I would personally prefer for Game Design reasons, and what would be less work for me to implement.
I sometimes felt that this was not received well but in this group, I had the feeling that the others appreciated it!
Assets and Production
I made a new Dropbox folder for Final Art Assets and a google doc folder for playtesting, documents for known bugs and expected bugs, with color coding for status.
I also made a final “Template/Example” XML file for Matthias, so he knew exactly to write in the XML file.
I once again realized that I often find problems, or something no one has thought of before, while working on the protoype, and wonder it was my responsibility to think of that beforehand… I try to plan a lot before I start working, but I’ve found that it doesn’t really help me so much, but maybe I would have to plan even more?
I had to update two of the Testing-Android phones for them to work with the QR scanner Owen implemented. The oldest one took about 2.5 hours to update, with at least 6 reboots!!
I realized how important it is to make a prototype ASAP, to make a build and to make EVERYONE test it, so everyone is on the same page about how the game works! In this case, someone had a different idea of how the menu structure worked. Luckily it wasn’t problematic, but it could have been!
Sometimes during coding I have to concentrate a lot, and need to turn off my music, lest it distract me from thinking. That was the case while I was implementing the multiplayer aspects, because it was new and unfamiliar.
When I was finally back on familiar territory, working on gamelogic, I could finally put on headphones, turn on noisy music and really crank it up!
Writing bad code was… liberating. I always build some errorcatching functionality, to check for human (my) error, but while I had so little time left, and the goal was only to make it work somehow, I learned a lot of new things!
And it was relaxing somehow, not having to think of how a certain case would be handled. If the player does something totally unexpected, the game crashes, or some undefined behaviour happens, I didn’t know, but it didn’t matter because it was only a prototype!
Also, here is a quick guide on how to finish a game for a tight deadline:
We held a Mini Gamejam at my house on the 29th featuring Owen, Andreas and myself. Unfortunately didn’t get a lot done on my end because there were a lot of uncertainties about how we would implement the mixed reality and how we would compile it, in order to present it at CGL! I thought the time was worth it though, also to make sure the QR scanner is working as it should! After Andreas left and Owen crashed at my place because he missed the last train, I could implement the discard phase from start to finish, which took up only around an hour! After that I went back into the matchmaking scene and made that a little better but annoyingly, the final button the player had to press was still too small…