Originally Posted in the Dev Pub
The content presented below was originally brewed in the oak barrels of the Dev Pub forums. After allowing this thread time to properly age, it is now ready for public consumption and has thusly been moved into this forum for all to enjoy. Please note that finely aged Dev Pub threads may contain outdated designs and information. That said, we still encourage you to leave feedback as we'd love to get some new opinions on all this.
Accessing the Dev Pub
The Dev Pub is available for anyone who backed the Kickstarter at the Land Shaper tier or higher. (If you backed at those tiers but don't yet have access, just head to the Backer Verification Thread and we'll get you set up.)
Since last time, my work in code has been primarily progressing on the jobs. The process has mostly been a smooth one although it has taken a while to get them to start taking shape (with some detours improving editor features + workflow here and there).
Following the design docs I decided to mostly concentrate on the two minigame heavy jobs (blacksmith and apothecary). Despite the subject matter (carrying out a job...in a videogame?!) these are something that I'm quite looking forward to playing when everything is in place but, for now, very little is in place as we haven't had any art for them as yet!
This seems like a fair place to put a warning that what is shown below is not going to be nice to look at and certainly nowhere near finished, so I hope you can bear with it till it one day looks pretty! The aim at this stage for the code is just to get something representative in place for a controls perspective and to try and make the code reusable and easy to adapt for changes. Putting too much effort into getting something that looks pretty in the early stages can actually be a bit detrimental in my opinion because it places a larger cost on rework. At the very least it makes it harder to change knowing that it already looks good to go. In some cases even visuals aren't enough and it's only when the sound is in place that it really clicks together.
Apologies to those aesthetically inclined for the large amount of blue background on show - it's my default background colour of choice so it pops up a lot! So without further warning, here's a few screenshots of how the blacksmith and apothecary look in their very rough initial states!
The 'UI_ScreenBase' Code Base
The two jobs both have a very mild overlap with each other in the way they are setup/updated/drawn, so they do share a common base in the code called 'UI_ScreenBase' but this is bare bones and is just a way to enter and leave the screens.
First was making a basic flow for them which was done with an enum going through the states they would pass through and setting up the controls that would go from one state to the next and drawing what was going on. If it gets sufficiently complex then it might be worth actually making each state into its own class to make it easier to follow but for now it wasn't really necessary. While making the flows I noticed that I had a lot of input checking in each state and not a lot else. Currently most of the game/editor input logic is in the update loop for each mode it goes into; this works and perhaps is easiest to read linearly (because everything is in one place). However, for the sake of simplifying the setup for keybinding I changed it over to use an input manager that has its own update loop running each frame and fires off callbacks as necessary when something has happened. One benefit to this is that holding keys and repeating the effect of input (holding a direction to move up and down a list for example) is neatly wrapped up and easy to customise. Eventually, everything will need to be changed over to this system but there are a few special setups that need to be figured out to make that possible (this includes things like analogue stick movement where we might want to control what angle of the stick counts as pointing in a 4 or 8 way direction and a minimum sensitivity level which might avoid mistaken input and control the speed).
The blacksmith minigame has the player use the 'face buttons' to move between different stations. This leads to a slightly less linear progression between states for the player, and will require more testing to ensure that it doesn't break in doing so. In contrast, the apothecary minigame stations are more spread out:
This makes the individual setup a lot more linear and easier to handle and test.
Item Wheel Enhancements
In the process of making the apothecary ones, I noticed our item wheel was being used a lot for choosing what to use as ingredients. I took this an opportunity to rework the wheel slightly, in particular the one in the prototype is quite slow in changing between items. This is because there's a threshold of rotation that has to be passed before an option is changed. This meant that quick presses of left or right on controller or keyboard will nudge the item so that it feels responsive and won't change to the next one by accident. Sometimes it can be nice to make an action very deliberate in this fashion but I think when the option comes up a lot then it becomes less acceptable to many players to have that delay (much like how holding A for 0.3 seconds was originally in the prototype but this was changed to be instant following player feedback!). So I made a change that guarantees a very short nudge will still push on to the next item in the list and it feels a lot more responsive now! In the process though, I have temporarily made it look less finished in that it snaps immediately to the next item instead of smoothly animating to a rest. To address this, I'll likely use an easing function (http://robertpenner.com/easing/) that kicks in when the player lets go of the control to move it to the resting position.
As a slight aside, one aspect of working with our own bare bones engine based off Monogame Framework is that we don't have much in the way of builtin animation control. In UE4 and Unity they have an animation graph that controls a lot of properties on nearly any given object within the game and that gives a nice visually powerful way to work on animating a UI. It's certainly possible to replicate the actions in code or write scripts or a similar animation graph control or find an equivalent third party and make it compatible with our engine, but this comes at a time cost that likely favours the existing engines. Our likely plan for this is to have a way to script animation and the UI and then perhaps look to a timeline graph solution further down the line time permitting.
After an initial pass through, which took a few days, I then went back through each and improved them in terms of look; the original versions were so abstract I dare not show them! Then I spent time ensuring they tied properly in with the game logic (in particular making sure the items they used and created were valid in the game so other systems could use them).
The Ledger
After constructing the minigame I then worked on the ledger that handles the management of the jobs. This isn't something the player will have control of in the early stages of the game (it's for when you are an adult and own a shop!) but is good to get in now so that the system can be hooked up and linked together for the gameplay loop! The ledger is split into different tabs covering a variety of areas the player has to think about like stock/staff/accounts. Like the other UI parts making it responsive and feel satisfying will help keep it fun to use over the course of the game. In the process of getting this in place based off the design docs there were a few aspects that got changed or added to make more sense ingame, I'm sure this will continue to be a theme going forwards of having to adapt from playthroughs! There will need to be some work here on the simulation side so that when the player has staff take over running of the shop there's some metagame script update to ensure it is all running smoothly but trying to ensure the player can always do it better.
The Signposts
After getting the ledger it was time to hook up the next piece of the puzzle, the signposts... Once a signpost is interacted with then the shop is open for business and customers should come by to make requests. Balancing the rate of this happening is something that'll be worked on for a while, but for now it's a random chance based on time from last customer as well as a reduced chance for blacksmith based on how many orders are already required (otherwise you'd run into the situation of not having enough time to fulfill the orders!). For the game we'll have two types of customer, residents and wanderers. Wanderers are a little easier to work with because they'll pop up, make their request and then either have it fulfilled or not. I've made a basic script that handles this behaviour by having them pop in offscreen, wander into the shop, make their order and either wait or leave based on the job's urgency. The residents will require something slightly different which I haven't done as yet but am thinking of it as basically flagging someone as having a request, carrying out a behaviour that pushes the shop to fulfill the request and then returning to everyday activities. The residents can then have some opinion/comments based on how this went to use in opinion/conversation later on.
Having the customers appear also brought about a slight switch of pace to add the new villagers into the game! At the moment we're experimenting with heads and bodies being separate sprites rendered on top of each other which helps ease the number of similar but not identical sprites needed.
Tune In Next Time
I think that brings to an end the stuff to cover this time, any thoughts/feedback welcome! Apologies for the slow arrival of this post, it's been almost ready for a couple of weeks but it's been hard to stop tinkering with it! Code has been progressing further in the meantime on the other jobs, events, asset setup, and editor improvements.
