I’m not going to bombard you with paragraphs so here are quick points for a postmortem:

 

 

SO SO: I used old base code from my turn-based strategy game experiments. It was not the best fit. There were some few unused pieces of code that I had to clean up (“I don’t think I’m using this function, I should delete it, it’s distracting me… but is this part really not used? I have to check…”).

 

 

GOOD: Clearly define the scope of what you’ll do. That goes without saying, and yet some people don’t get this. When I see others saying “I’m gonna add this and this and this, I think it’s ambitious for the time-alloted, but I think I can pull it off LOL” that’s already a red flag right there. Do you even have a concrete plan to do all that?

I put it out there that I can create either a singleplayer game or a multiplayer game, but not both. At least, not within the 7 days. So I asked in the Ludum Dare website which they want first. Of course I want to add both eventually, but I have to choose what to finish within the 7 days.

 

 

GOOD: Create a “testbed” level to quickly prototype ideas. A sort of playground level without victory/defeat conditions so you can test things quickly. I do this all the time. Shigeru Miyamoto does this, so why wouldn’t you? Don’t you love Miyamoto-san?

 

 

GOOD: Sound software engineering practices. Abstract low-level details with high-level convenience functions! Reduces clutter, makes it easier for you to think! I’m going to write a separate article about this.

 

 

GOOD: Used NGUI! Worth the $45 (got it on sale)! NGUI’s WYSIWYG workflow allows you to design GUI layouts fast!

 

 

GOOD: Used free art assets from the Internet! Some editing was required but still lessened amount of work!

 

 

GOOD: Made my own 3d animations! Better control on how I want attacks to move.

 

 

GOOD: Used primitive shapes for my 3d models on purpose. Didn’t add legs to lessen work! No need to animate legs! Looks cute according to some people! (?)

 

 

GOOD: Made use of free 3d models from blendswap.com (i.e. the skulls of the units) to lessen amount of work.

 

 

SO SO: I probably should have made use of a state machine to facilitate low-level behaviour of units. But with the behaviour tree plugin I integrated, I think I can make use of that instead. I did not choose to do this though, as I concentrated on multiplayer instead as requested.

 

 

GOOD: The good thing is all the ugly code is hidden behind a clean interface & facade class. So eventually I can clean up my ugly code without adversely affecting the rest of my code.

 

 

KIND-OF BAD: Should I name my function FaceUnit() or TurnToUnit()? Can’t decide! Drives me crazy!

 

 

GOOD: The network code I made includes a lobby and match-making service, which I could use later on for other games.

 

 

GOOD: Although I use the built-in Unity network library, I modularized my code so I can swap it for a different network library instead (Photon or uLink, maybe?). This is probably likely as I’ve heard many complaints that Unity’s built-in network library is buggy in real-world use (when there are dozens of connecting clients).

 

 

SO SO: This game jam forced me to learn git subtrees. I lost sleep wrestling with the damn thing, but now I can use it.

 

 

BAD: Live streaming? With the quality of Internet connection in this country, forget it. Tried it. 90% of my streaming video’s frames were getting dropped.

 

 

GOOD: Keep two versions of your builds: one for the clean, playable, version, and another for your experimental version where you are adding new stuff. In case what you’re adding won’t make it to the deadline, simply use your last clean, playable version.

I usually release my Unity web builds on Dropbox. But I realized I should have put two versions on Dropbox, i.e. the two versions I mention. There would be a StratSoulsRelease folder and a StratSoulsExperimental folder. Once I’m sure of my experimental version’s stability, I simply copy the necessary files over to the release folder.

Tags: postmortem, Strat Souls