I will keep the retrospective short this week. Reasons include the first alpha release and a hangover.
Another week of system building has gone by. From last week’s menu re-implementation I still needed to complete the actual placement of objects in the world. With that done, I can now put in new placeable objects in minutes. As another UI improvement I have made context-sensitive button icon displays on interactable objects. The system is still not completely fleshed out, but already improves usability for new players.
The big task this week has been enabling NPC behaviour based on tasks which they are signed up for. This meant coming up with a code architecture which lets me define behaviours for each task condition. Right now, there is only one behaviour: build an object (currently a tent). But again, I can now easily extend that to match any task and condition. Here’s a little sequence showing how objects are placed and NPCs haphazardly build their tents:
Looking Forward
Today I am releasing the first, extremely early and unfinished alpha version. I hope to get some bits of good feedback. If you are interested in a first look or even helping me out, consider registering on this site. This will get you access to the forum where I will post download information for any releases.
Next week I plan to improve NPC behaviour to make them look more alive. No more segway-driving lamp posts! Of course I will also keep track of testing feedback and work on the most pressing issues.
Apparently I am really bad at planning tasks for my own work. Again I have found myself working mainly on code which enables the stuff I actually wanted to do. Fortunately, all the stuff I have done keeps making my job easier. Earlier this week I had shown off a screenshot of trees and little bushes on the terrain:
The addition of these props was a logical prerequisite of NPC survival behaviour: those guys need resource nodes to gather food and materials, hence trees for firewood and bushes for berries. I thought went a bit overboard with the prop system when adding it. However, when it came to making video material for today’s update, I was able to add two more kinds of props within a couple of minutes. Time well spent.
I put some more work into the task and quest system, which was actually planned. Again, adding some more steps and conditions is really easy now. Here’s a video showing off the slightly expanded first steps:
At the end of the video, I also demonstrated the completely redone context and building menu. I had done an iteration on that before I started the game in earnest, but decided to scrap that in favor of a cleaner version because I have learnt a great deal more about Unity, already.
Here is another video showing what happens behind the loading screen:
Looking Forward
I still want to release the first alpha version at the end of next week. I will invite a batch of testers in time. As for the game itself, I plan (hah!) to do the following:
Flesh out settlement quest
Add camp fire
Add tents for player and NPCs
Add stockpile
Start NPC survival mode
Start work on player-NPC interaction
Define and assign tasks
Filler stuff
Move pathfinding navigation data processing to loading scene
It is a boogie wonderland and I fell down the funky rabbit hole. Actually, several rabbit holes. Deep ones. No light. No hope. Just work.
Before I continue my lament, have a look at the current state of a player’s start on a new map (the video is annotated):
I only got around to doing 3 of the tasks I laid out last week:
Add ramps to terrain
Quest system
Hint box
Each of these tasks opened up several issues beneath. In the end, I actually did the following in addition to or as a prerequisite of the aforementioned tasks:
Terrain Geometry Refactoring
The terrain is generated in a three-dimensional array which holds the terrain type of each discrete block. Within that array, I had to find suitable patterns for ramp placements. I made a 5 units sized “sliding cube”, analogous to a sliding window, of exposition data (i.e. a cube position has either a solid in it or exposes one). The window is compared to pre-defined patterns for valid ramp positions which yields candidates for placements. The next step is changing the terrain data to represent the ramp. Accomplishing that requiresd another sliding cube of 3 units to detect “steps” in the terrain, which are then turned into the ramp slopes as seen in the video.
Calculating all that crap required some re-shuffling of the terrain code, which did not make it easier, either…
Modal Dialogs and Hints
Info box as displayed at the start of a new map
Some game steps require hints to be displayed. At the start of a new game or map, the player had no guidance whatsoever. I have built a modal information box which displays hints to a player and blocks other input (e.g. movement) to communicate important stuff to the player.
Similarly, when the player presses the button to claim the land and start the settlement, there is a confirmation dialog to check if this is really the location the player wants to choose. To make sure that the player knows which button to press, a flashing message displays critical information such as that at the bottom. By the way, I also updated the entire input system with a new component which also allows displaying the name of buttons configured for specific actions.
Quest / Task System
Task panel with one task displayed
The picture above shows the task panel, which is the UI part of the task system. Both the display and the system underneath are already quite elaborate. The panel can hold several tasks and will automatically position them. The task system is ready to accept new tasks with conditions, which are checked whenever a character works on a task. Player tasks are not yet checked correctly, because players can work on several tasks in no particular order and require different methods to properly attribute their contribution to any task.
Miscellaneous
Apart from copious refactoring, I also took another look at the context menu I had done a while ago (before I started full-time). After a day of shuffling stuff around and restarting work on the menu I re-focused on the more important parts.
Fiddling with the pathfinding component took a chunk out of my time, too, and the calculation of the navigation data still needs to be transferred to the loading scene. Maybe I even need to switch the navigation type eventually, but that should be painless (yeah right…).
Looking Forward
So, with a brimming backlog and a bunch of half-completed work, this is what I plan to do next week:
Finish settlement start
Properly check task conditions on the player
Display task completion in task panel (small animation)
Improve NPCs
Re-do previously implemented behaviors with newly integrated components
Try adding object avoidance to pathfinding
Basic survival behavior
Filler stuff, if I get to it
Move pathfinding navigation data processing to loading scene
Day-night cycle
More work on the player context menu
I still think pushing for an alpha release at the end of week 4 is realistic. I suppose I just need to really focus on the important stuff…
And that is it for this week. Thank you for reading!
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.
Debugging visualization of navigation meshes
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.
Terrain being built off-camera in loading scene
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.
Looking Forward
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)
Reaching Out
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.
Originally I had planned to make a progress update on Friday. But since I have been able to get quite a bit done in such little time, I would like to share some bits already.
First up is a look at the current iteration of the game’s menu structure and new game setup. It is still very rough, but should give you a good idea where this is going:
This short sequence shows the main menu, character creation mock-up and map creation screens. This is work I had already completed before starting full-time on the game.
Next, we take a look at some in-game footage right after entering a new game:
The video shows the first iteration of companions following you around in an initial caravan. In the character creation screen, players can select a number of companions which whom they will start their settlement. Right now, everything is made up of placeholders. But soon, those companions will be reflected in the game. At first, you are going to be dropped at the border of the chosen region and travel some distance into the land to select a settlement site. Up until that point, you will be safe. Dangerous wildlife and other threats will only become aware of you once you have established a foothold.
Since this progress, with all underlying and not apparent changes was my planned goal for this week (hence the early update) I will now use the time to improve code and maybe do some visual stuff. On Friday, I will share my plans for next week’s tasks.
P.S.: Sorry for the potato-quality videos. I still have to set up a process which gets us good footage and does not take hours to upload.
