Saturday, October 21, 2017

October 2017 Gamedev Project - Post-mortem

I decided to spend the month of October working on putting together a rough little game prototype. I thought it would be good practice to put in some time every evening after work, as well as the weekends. At the end of 21 days, the resulting product I had was less than I was expecting, however the lessons learned were much more valuable.

1.    Fail Fast

We’ve all heard this plenty a time before, along with its matching adage about avoiding the Sunk Cost fallacy. Everyone knows that it is important to persevere and push forward, however there is a point that one passes where no amount of hard work or good intentions will salvage a project. 

It bears repeating at the beginning of each day’s session: build prototypes that can be discarded and will be learned from, not projects that need to be committed to.

2.    Start with a gameplay idea, not a theme

The biggest demotivation for me didn’t turn out to be discovering that after 3 weeks of work, my little game was not fun, but rather the fact that it didn’t have any gameplay at all, whatsoever. 

I had a pretty good idea of what I wanted theme wise: I had a fairly good idea of the setting, the general ambience and atmosphere I wanted. I had a vague idea of what games it would be similar to, but I hadn’t nailed down the most important and fundamental question: what was the basic gameplay loop?

There were no decisions for them to make, puzzles to solve, nor challenges that faced them. Money slowly came in, and the upgraded their buildings. The gameplay was about as shallow as an idle or clicker game. In the end I had a little program that did its own thing and practically ran itself: the player had no incentive to participate.

 

 3.    Choose your tools and stick with them

I wasted most of the first week fiddling and fighting with tools and indecision. I had initially decided on using Typescript and Phaser, then switched to Pixi, added Physijs for physics, then ended up switching to Three.js because I wanted to use 3D models. A lot of time was wasted getting up to speed with each framework’s nuances, as well as sorting out quirks first in Visual Studio Code, then Brackets.io. 

Then there was everyone’s favourite 3D modelling program, Blender. I feel like each time I boot up Blender after not using it, I spend at least a week before I’m comfortable enough to actually make anything.

4.    Don’t waste more time than you need to on placeholder art

Having nice looking art is great, anyone can tell you that. What I did however learn first-hand is, that fancy looking art doesn’t count for much when the actual game has about as much gameplay as an animated wallpaper. 

Early on I told myself to do the absolute basic for the placeholder art. Tall cubes for buildings, squashed triangles for ships. At some point, the creative corners of my mind must have taken that as some sort of challenge: “I bet you can’t make proper art.” Luckily I only spent 3 or 4 days out of the 21 on the art, and to be honest it was a lot of fun. Once you get into the flow of it, you can burn through hours and make a reasonable amount of progress. That’s great if the gameplay side of the project is done, so until then, prioritise and settle for placeholders.

 

 5.    Minimum Viable Product – Cut, cut, cut, every day, twice a day

I’m going to end the main lessons learned section on one of the most important: focus on the Minimum Viable Product. Cut away as much as you can. Trim every excess feature and only implement what is absolutely necessary. 

Again, we’ve all had this drummed into our heads, and I diligently did this at the beginning of the project. It turned out to not be enough. In hindsight, it’s something I needed to be doing at the beginning of each session, something to be done every time I open the day’s To-Do list. Your resources are limited, so don’t give yourself unnecessary work.
 


If there were only 5 lessons I could take away from this, it would be the above five. I may not have made a playable game by any definition of the word, but I gained a lot of practical hands-on experience. That said, there were a few more lessons learned:

6.    Keep a notebook on hand at all times

I found that while I wasn’t actively working on the project, I seemed to come up with lots of pie in the sky ideas that weren’t practical to implement by any definition of the word. I also came up with lots of ideas for other games that were completely tangential to the project, in some sort of evasive and distractive working manner of the creative mind. 

One minor mishap I had here was separating Ideas for Implementation, and Ideas for Creativity. A lot of the ideas I had weren’t feasible to put in the game, but I spent a lot of effort trying to shoehorn them in anyway. Instead, I need to draw a clearer distinction about what ideas are going in (and scrutinising it against Minimum Viable Product and Cutting), versus what ideas I’d use to help encourage creativity for other projects.

All in all, I managed to pen in more than 100 pages of my A5 (6x8”) notebook that I carried around everywhere. Useful material for next time, I hope.


 7.    Design 3D models that look good in game, not in renders

Related to #4 above, I spent many hours getting the models looking as picture perfect as my skills allowed in Blender, only for them to look incredible lacklustre in game. I then spent more time baking textures and importing lightmaps, and this worked until I realised that this technique wouldn’t work if I’m going to be swapping pieces of the models in and out. 

By day 21, a lot of the time I had spent on making the models picture perfect were a complete waste and didn’t carry over at all to the final product.

8.    Write good enough code, not perfect code

I spent a lot of time trying to write code as well as I could. I discovered that every time I wrote code for something, I’d end up refactoring everything at least once, leaving not a scant trace of the earlier code. By the third week I came to the conclusion: write the initial code to be just good enough, because regardless of how good you write it, you’re going to end up refactoring it anyway.

In addition to that, I made the mistake of not splitting the code from the data as early as I should have. Many things which should have been sitting in data only files were hardcoded, and meant I wasted a lot of time later separating them.

Lastly on the topic of code, getting the UI, the game, and the data to mesh was really unpleasant. I didn’t look forward to the evenings when working on it was on the To-Do list. I really need more practice in implementing the Model Viewer Controller pattern, and getting the foundations for it set properly the first time around.

9.    Rather underestimate on your To-Do list and over-deliver on your actuals than vice versa

This is more of a personal motivation character trait, but I found that if I set out an easy To-Do list, I’d end up doing more than the list prescribed and in general ended up being more productive for the evening. On the other hand, if I had a longer To-Do list, I found it more of a chore. 

The important thing for me was just to sit down and get started with something: the easier and more persuasive I made that step, the easier it was to get work done.

10.    Watch and listen to lectures by other gamedevs

Lastly, I found listening to lectures and talks by other gamedevs to be a lot more motivational than I would have been willing to admit. I’m not a fan of motivational speakers telling people to just be more product and procrastinate less, but there is something contagious about the enthusiasm and passion of people that you can relate to on some level.


So, that’s all for now. For my next project I’ll definitely aim for a much smaller and more realistic target. I’ll definitely shorten the time frame as well. I found that around the three-week mark, my enthusiasm began to taper off rapidly. Lastly, and most importantly, I’ll make sure that I won’t start until I have an actual gameplay mechanic or idea to build the game up around.

Monday, October 2, 2017

Monday, 02 October 2017

Today I came home from work to discover that they've finally started building the new fence around the apartment building. Finally, after untold suffering, I will finally be free of the curse of having to deal with drug addicts fighting over crystal meth at 4 AM in the morning. I am overjoyed beyond words at this surprise, it is truly better than any birthday or Christmas present.

I have long since lost track of how many hours of precious sleep I have lost due to their ceaseless screeching that was akin to nails scraping down the chalkboard of one's mind. In comparison even the most boisterous banshee would have seemed as quiet and peaceful as a sleeping kitten. I predict that the quality of my sleep will increase approximately one hundred fold.

Of course, knowing my luck, my lease won't get expired in December, and I'll end up having to move into a new apartment, only to find that they're already waiting under my new balcony.

Wednesday, September 13, 2017

Atlas Shrugged

I finally got around to reading Atlas Shrugged. Only took me 10 days, not bad. First half was great, had a whole dystopian economic apocalypse going for it. After that it began to slow down, and the last quarter was drearily painful. Last 200 or so pages were some of the driest reading I've had to plow through, disappointingly.

That being said, the book was plentiful in quotes. I'mma dump some of them, with no context or checking, because I'm tired and lazy.

Sunday, March 5, 2017

One Month of Learning JavaScript gamedev

About a month ago a friend of mine guilt tripped me into trying to learn JavaScript and gamedeving in it instead of whining about Unity whole day. I reluctantly accepted, and began learning how to use Pixi.js

 
Day 1 of many

Sunday, September 4, 2016

Don't make your first game your dream game

Of all the advice I've seen, read and received, "Don't make your first game your dream game" is probably the best advice.