It has been a most productive first week. I had estimated that I would need the entire week to get the character spawning and NPC following working to a basic degree. Turns out it only took about 2 days. This is partly due to the inclusion of the excellent A* Pathfinding Project navigation library.
Those systems still need some work, but the groundwork has been laid so I can easily extend it. Since that went in so quickly, I also did some work under the hood. The loading process was mainly nested in the main game logic script and would just freeze the game for quite some time. Now, actual terrain generation is done correctly in a loading scene (with an updating loading bar). This may not sound like much, but was actually quite a big deal. If you do not care about the technical side, skip ahead.
The thing about the loading process is this: Unity is inherently not thread-safe. This means that everything it does – input capture, physics, script execution, rendering – is done in the main application thread. Consequently, computationally expensive processes block the execution of the main thread, which makes the game unresponsive (hint: this is shit!). Unity does allow for some way to circumvent that: Coroutines. For those of you who are familiar with it, coroutines are basically generator functions. They are called each frame and execute one step until they yield. So that at least solves the responsiveness problem. But you still need to split up computation into steps which are short enough to execute within a frame and we are targeting at least 60 frames per second these days. Furthermore, the computation still runs on the main application thread, which can only be run on a single CPU core. Current CPUs have at least 2 cores, often more, and those cores lie barren, lonely and unloved when running most Unity games. But not in this game, bitch! Because I put those lazy fuckers to work. Essentially I wrote a custom thread pool (the integrated Mono .NET thread pool has some issues) which can be controlled and polled from coroutines. Heavy processes can now use the full extent of your machine’s computing power, as it should be. As a side effect, the new thread pool reports progress based on the number of tasks it received and how many have finished. The loading bar has a purpose now.
A good practice in product development is building a minimum viable product (MVP) as soon as possible to get feedback. The MVP should contain only the bare minimum of features as is required to ascertain the future product’s viability. In Charge! is rather complex in its envisioned design, because a lot of mechanics need to interact before a good feel of the final vision will become apparent. Nonetheless, the MVP approach can be used iteratively. If I can keep up the current pace, a first alpha build should be possible in April. When the time comes, I am going to add a feedback forum to the page and invite testers.
That being said, I will focus the next work tasks on reaching a first alpha stage. Next week’s tasks are:
- Add ramps to terrain, so characters can move freely across the map
- Basic survival mechanics for NPCs
- Find and consume water and food
- Make fire
- Get shelter; probably just tents at this point
- New game sequence on a new map
- Spawn player and companions close to the map’s border
- Simple quest system for player (“Claim land for your settlement”, “Stockpile food”, etc.)
- Set NPCs to autonomous survival when land is claimed
- Implement a hint box for information display (e.g. for tutorial messages)
As a small developer, snowballing a reputation by positive word-of-mouth is one of the most successful (and often the only affordable) kinds of marketing available. Consequently I want to start as soon as possible. If you like what you are seeing and where this is going, please consider recommending this page (or the Facebook page and Twitter feed) to your friends who might also be interested.