1. Document early, document as you code:
We have a event system for network communication, and usually the event sent in one platform is handled by another programmer who work on other platform. Therefore we create a google spreadsheet to track all event, whoever call the event should write down when they’re called, what are the data sent along, and how it should be handle. This is an easy and helpful way for documentation that we are seldom confused by those sixties events.
Some of the code is poor documented like the path editor I made. It supposed to be very easy but it end up having more communication cost as we start using.
2. Tech meeting for finding the “best practice”
If we do it again I wish we spend more time discussing the structure of the code before starting a task. Right now a lot of stuff are created in a hurry and their implementation are naive.
For example what’s the best way for enemy wave editor for a “shmup” game? Should it be procedurally generated? Or premade prefab? Right now the waves are arrays of enemies that procedurally generated them at certain time. This is totally make sense in our scenario. But when I was making the tutorial I have to not only make enemy waves but also add some scripted events. In this case I make the waves a link list of premade prefabs that I can add stuff in between events very easily, which I feel is more efficient. And maybe I’m wrong or maybe there are better solutions that I haven’t found.
Another example is whether that game should be in one single scene or separated to different ? It makes sense if we put the menu into different scenes, but then we may need to restructure a lot of things like making something class singleton.
3. Consider automated QA
We didn’t do it this project, but definitely consider in the future if there’s a team like ours. Since we have so many programmers, one small change in one’s code may cause an error in other’s. It would be nice if we have a way to find out if our latest code is bug free.
Another reason automated QA is important is that our device is super hard to test by one self. We already have debug keys to fast forward some login process, but it would be nice if it’s more structured and consistent and generated actual user input.
Also, at the end of semester we actually have no space on keyboard for “debug key”, so it would be nice to have a console system to send debug commands and automated test functions.
Organic QA tester is viable but not recommended in ETC.
4. Make Juicy Feedback. Polish Early?
This is just my random thought, but I think it make sense if we assign one artist and one programmer do the “polish” part early. Ex: We could actually start working on the on-hit feedback as soon as we decided our theme.
In fact this is about how you define your “minimal viable product”. For a battle oriented game like ours, I won’t call it a game (product) if it lacks of juicy feedback. Therefore I strongly recommend that programmers should implement this kind of features as early as possible.