Week 2 Recap
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
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
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.
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…).
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!
Geili Flagge, Stef