CaveX16 was a game I worked on for BGMC16, for more details, have a look at the page for it. Some things I did while working on this game were a great idea, and other things I would do differently, or was forced to re-do during the week of the competetion.
First up, about a day before the start of the event, when I had the game plan sitting in front of me, I suddenly realized how huge the project was. Over that week I put in many many hours. Probably slightly in excess of a normal full-time week. I'm surprised it didn't fail spectacularly.
Things that went well
Several things contributed to it being possible to develop the whole game in under a week.
Time Management
I started with the map, then mining, then the units and finally the UI. Any other order and I don't think it would have gone so well. If I hadn't had a map and been able to mine, there wouldn't be much of a game would there? Big things first. That said, the gameplay suffered because I didn't have any way to see "is the game fun" until it was completed. As it turned out, it is repetitive and boring, a feeling shared by others during play-testing.
I got onto the game early and focussed on code, and, well, it got to a playable state.
Simple Graphics
Even with plain material vehicles, I still spent a lot of time on modeling and texturing. The decision to ignore complex textures and realistic shaders was a good one. It also meant it was possible to play on lowish-spec laptops.
Planning
This was one of the most planned games I have made. Before the event started I had a stack of paper planning the game. I had narrowed the scope of the project, scaling it from something unachievable to something that was meerly a rush. It was solidified into something devoid of feature creep and last minute ideas. A large part of this is thanks to my good friend PPski, who came up with the original concept and kept chasing me to make it smaller and simpler.
The planning was detailed. It outlined the UI, how the user would interact with objects, how worlds would be generated, what units would look like and so on. So when I sat down in the morning, code and resources just came out. They had been bottled up and started being developed in my head a long time before they became physical. This was only possible because I had a plan in advance.
Version Control
I use gitlab for my projects. Understanding and using a VCS meant that I wasn't afraid to make changes that could (and did occasionally) break the game. In a couple cases I reverted the tile meshes, viewed diffs against old versions to find where bugs were introduced and so on. Git worked well because were exactly two logic bricks in the main game and blend files contained a single thing. Everything else was code, and could be properly version controlled.
Pylint
Keeping your code neat, or at least, putting red underlines on things that aren't... While I do not like working with it, it sure did help keep the game sensible as it scaled.
Things that went wrong
I sure learned a lot, and mostly from the failures. So where did things go wrong?
Harder than expected
There were two new parts for this project I had never approached before. They were pathfinding and map modification. Fortunately map modification ended up easier than I feared, and took only a few hours after map generation, and fortunately PPski took care of the pathfinding. Without that, it would have been a very poor game.
Poor architecture
This hindered me through the last few days of the competetion. Things I simply hadn't thought of came up, and the modularity of the game suffered as a result. I also ended up rewriting the map class entirely three days out from the end. It only took two hours, but with better initial design, could have been avoided.
I now know that (very often) objects should know about what environment they are in. Units should know what map they are on and so on. From any given object, it should be possible to retrieve the the very core of the game. I ended up using a couple globals for retrieving things like the map and the schedular, decisions I came to regret.
No formal testing
All the testing was done in-game, and was only possible because I had a PC fast enough to boot the game quickly. When working on my laptop development was a lot slower as testing things took time. (a 20 second startup time). I need to investigate proper methods of unit-testing my code."defs.py"
It was a shambles. It started out as a way of defining gameplay constants (Eg world size, starting resources), and ended up being a stewpot for blend file paths, a place that settings were hacked into (to which pylint complained suprisingly little). It is completely unmanagable.
In future, I'll split this into smaller files, one for gameplay, another for blend paths, yet another for blender entity names, and another for user-controllable settings.
Summary
It was a fun project. I don't think I'll make another RTS, but it was definitely worth doing at least once. Next time things will be better. Were I to make this game again, it would be far better....