Last week I outlined some of the tasks that I would have in creating the pioneer wagon, so this week I want to explain some of the basic questions I had to answer when I started programming it, and why.
To begin with, it might be important to mention that I always try to reuse code if possible. This makes it both faster to create new systems, and means that future changes and bug fixes can be done centrally, rather than having to be copy pasted multiple times. So with that in mind, I had of course hoped to reuse the code I am using for the other “units”, i.e. villagers with the pioneer wagon. This would mean I could use the same system to give movement orders as the soldiers, could use a similar UI to what we have for the villagers when the player opens the book, and many more.
However, there are of course many differences between a regular villager and the wagon, which led to some essential questions that needed to be answered to see if it actually made sense to reuse the villagers’ code. Starting with the first important difference: Villagers always have an accommodation, and require food. This is woven quite deeply into the code and affects many different aspects (including how to handle their death or reassignment), so there would need to be a lot of checks that recognize not to run this code for the wagon.
However, this code is also not run for pirates. Pirates have been around pretty much since version 0.1 of the game, and so much of the more complex code has been added with them already in mind - checking if the current person is a pirate, and acting accordingly. Which begs the question: should I treat the wagons, at least for those purposes, as a pirate? This would have been a potentially quick way of creating a wagon that doesn’t require food or an accommodation, but otherwise benefits from many of the mechanics that apply to villagers.
Of course there were many more considerations: Pirates are treated differently by the game not just for their food and accommodation needs, but also for how they handle different tasks (they are all soldier units after all), whether they initialise GUI elements (since players can’t interact with them in the player book, there is no need to have a GUI element after all), and many more aspects. So, making them straight up pirates would simply not be good enough.
Overall, there were a couple more questions that I ended up going through (and discarding): Should wagons be treated as moving buildings instead? (Especially when realising that they will be the accommodation for the 4 villagers they carry until they create their outpost.) Should they instead be a completely new type of unit (and if so, are there additional units in the future that may use similar code, such as the ox carts?), etc, etc.
In the end, I decided that I was indeed going to create all new code for them. I will of course copy a lot of the relevant code from other units, but I think that they are sufficiently unique in how they function, that creating a new unit for them is justified. Creating this code is going fairly well so far, so I will keep you updated!
Until next week!
Weekly Update 156 - Creating the Pioneer Wagon
Hi everyone,
In Weekly Update 87 (so quite some time ago), I mentioned my plans for the pioneer wagon. Back from holidays, I am now finally working on it, so let me give you the rundown.
To start, let me recap what the pioneer wagon is going to be: The pioneer wagon will be a unit that allows you to more efficiently start up your outposts/new villages. You will be able to create it in a dedicated building, fill up with resources and villagers, and move across the map. Once you have decided where you want to place your new village, you can “activate” the wagon, place the blueprints for a market, a warehouse, and 2 small houses, and the wagon will “unpack” to construct these buildings - without taxing the logistics of any of your other villages.
This solves a big problem the game has at the moment, which is the slowdown when it comes to expansion - and often the death of your home village logistics (and therefore your villagers) when you try to expand. With the wagon, there will be no strain on your home village logistics until you have at least some logistics in your new base - which should help to reduce the stress created by distances between the villages.
So what will it take (me) to create the wagon? Firstly, I will need to create the new building, let’s call it the “wagon maker” for now. This wagon maker needs to be set up a little differently from any previous buildings, as it creates a unit but isn't its accommodation - so I will need to create new functionality for it (as well as the model). The wagon maker building will ideally also function to create the ox carts which will ferry goods between your villages in the future, but I will not focus on that for now.
Secondly, I will need to create the functionality for the wagon (the model is already finished, see today’s image). The movement and “unpacking” for the new village should not be too difficult, but creating a system in which the new villagers will spawn from the port and remain in the wagon in a sort of stasis until they have created their own housing may be a little more challenging. While the model is finished, it will also need some animation and will need to be set up to adjust to slopes, etc - so that will also take a little while.
And lastly, I will need to adjust the logistics system to only allow warehouse workers to transfer goods between villages for now, which should allow for players to keep their idle workers for intra-village tasks.
As usual, I will keep you updated on the progress!
Until next week!
Weekly Update 155 - Intermission
Hi everyone,
I was travelling last weekend and helping with a move, so I was unfortunately unable to write a proper post and am just going with a quick intermission.
Rather than write another double post at the end of the week, I think this will not keep you in suspense and I will be able to dedicate a single longer post to a topic at the end of the week.
Until next week!
Weekly Update 154 - Windmaps
Hi everyone,
As I believe I had mentioned before, I had asked Tom to go over our old art files and bring them in line with the standards we’d established since their creation - with some unexpected benefits I want to talk about today.
Without going on a long explanation, I had mentioned before that many of our game files had been developed over years, leading to some having been created with completely different techniques and standards than others. Considering my ongoing efforts to bring things in line with our current standards, I had asked Tom to go over the old assets and modernise them accordingly.
As a result, however, we were able to create two big improvements for the foliage in general: more consistent normals, and windmapping for the tree trunks of foliage.
The first of these is a result of reapplying a new technique to old foliage. While our newest foliage already had fairly consistent normals, some of the old trees still had their branches with normals coming out at right angles, leading to a much less natural look. With the update, the foliage overall will look more consistent and natural, and less jarring in terms of the lighting.
The second improvement comes from moving the windmapping from a texture based approach to a vertex based approach. With this, we can now also add wind to our tree trunks, making them sway together with the branches. This is of course a nice visual improvement, as it adds to the world feeling more alive, and since we are building this from the ground up, it has allowed me to also get more control over the wind in general - making it consistent across the world, with pockets of stronger and weaker winds aligning much better.
It will still be some time before all of this has been updated and I will upload the changes - but we are getting a little closer every week.
Until next week!
Weekly Update 153 - Windmaps
Hi everyone,
As I believe I had mentioned before, I had asked Tom to go over our old art files and bring them in line with the standards we’d established since their creation - with some unexpected benefits I want to talk about today.
Without going on a long explanation, I had mentioned before that many of our game files had been developed over years, leading to some having been created with completely different techniques and standards than others. Considering my ongoing efforts to bring things in line with our current standards, I had asked Tom to go over the old assets and modernise them accordingly.
As a result, however, we were able to create two big improvements for the foliage in general: more consistent normals, and windmapping for the tree trunks of foliage.
The first of these is a result of reapplying a new technique to old foliage. While our newest foliage already had fairly consistent normals, some of the old trees still had their branches with normals coming out at right angles, leading to a much less natural look. With the update, the foliage overall will look more consistent and natural, and less jarring in terms of the lighting.
The second improvement comes from moving the windmapping from a texture based approach to a vertex based approach. With this, we can now also add wind to our tree trunks, making them sway together with the branches. This is of course a nice visual improvement, as it adds to the world feeling more alive, and since we are building this from the ground up, it has allowed me to also get more control over the wind in general - making it consistent across the world, with pockets of stronger and weaker winds aligning much better.
It will still be some time before all of this has been updated and I will upload the changes - but we are getting a little closer every week.
Until next week!
Weekly Update 153 - Thoughts on Competitive Play
Hi everyone,
I realise that I am uploading this post quite late, so you will get more or less of a double-post with tomorrow’s update again.
While the majority of our players have been interested exclusively in single-player and co-op play, there is a small minority of players who are still very excited (and insistent to tell me) about the possibility of competitive gameplay for PtP. Even though this is a minority, I still think that there are ways of making some competitive gameplay work, and my holiday has given me some time to think about how this could be realised in the (far) future.
One of the main issues I’ve had in adjusting from our initial competitive gameplay to the coop modes have been balancing and timing. In general, competitive gameplay lends itself more easily to quick matches (or at least somewhat contained timeframes), with fast, predictable, and balanced progression. For 0.9, I am intending to move away from this even further by embracing random resources and adapting to what you find even more - which makes competitive play yet more difficult.
However, I think that there is a possibility for a sort of player vs player vs environment gameplay. Rather than simply pitting the players against each other with randomness potentially allowing one to beat the other early on, pitting two players against each other in getting the artefact from a well established pirate fortress may be a better bet. In this situation, players will both be slowed down by having to overcome the AI, and both players will have enough time to adapt to what they find and make the most of it.
This could lead to rather interesting gameplay, where a dominant player needs to consider not only how to advance against the AI, but also how to protect themselves against their human opponent. Likewise, the player who is lagging behind may get opportunities to disrupt the dominant player, or to simply steal the artefact away from them as they are weakened by the AI.
Of course all of this will be far in the future, after creating a fun and balanced gameplay loop for singleplayer and coop - but I think the possibilities for competitive play are still there in the long run!
Until tomorrow!
Weekly Update 152 - Holiday
Hi everyone,
Considering I am on holiday at the moment, I am going to just take a quick moment to explain what is going on, and when development will resume.
As some of you already know, I am on holiday from my day job at the moment, and have decided to also extend my break to the game. Considering the double work usually takes a toll on my free time, I think that taking a “joint break” is going to help me recover a lot more effectively, which should lead to faster development after.
During this time, Tom is continuing his overhaul of some of the art assets, so some work is being done even while I am not working. And, of course, I am continuing to think about the game - and have had some really good ideas (or so I think) over the past few days already, which I am excited to be sharing with you in the upcoming posts.
My holiday will end in early September, so actual development will resume then.
Until next week!
Weekly Update 151 - The Importance of Player Feedback
Hi everyone,
I want to take this post to talk a little bit about the importance of player feedback on this project, and give you two examples of why bug-hunting is difficult to do just by myself.
My first example is that of the broken strategy map. I had repeatedly gotten reports (mostly from John), that the strategy map can’t be interacted with after some time of playing the game. My own tests of this were never able to replicate it. Any time I tried to use the map it would work - placing various combinations of buildings didn’t change that, letting the game run for hours didn’t change that, and hiring different combinations of units also had no impact. Finally, one of the players of the game managed to not only report the bug, but was able to tell exactly what was wrong: Trying to use the strategy map while having your tool out meant that the game would simply ignore any clicks on the strategy map, while interacting with it without the tool meant that it would work without a problem.
The main issue here was how I interact with the game. Whenever I play, I always put the tool away unless I am specifically trying to use it. John, on the other hand, keeps the tool out for the most part - in case he needs to cut something down. This leads to the larger issue at hand: The game has multiple “pillars” of gameplay, and there are many different ways for how to play it. Some players will focus more on the FPS aspect of the game - others on the RTS or the base building side. If I am the only person looking for bugs, I will find and eliminate all bugs that are created by my specific playstyle - while missing many, many others. Getting feedback from other players is therefore incredibly important in helping me figure out not only what bugs I need to fix, but also what quality of life improvements are needed to improve the experience for others.
Let me give you another example here: When we first changed the progression of the game to require outposts, John’s outposts would always take much longer to build than mine - and destroy his logistics much more than mine. For weeks, I couldn't figure out what the problem was, until I finally watched him play and saw the problem: Whenever John would place a building blueprint, he would cut down the closest tree, and add the wood to the construction inventory. Let’s say that the building needed 50 wood to be completed - John had now added 10 wood, which meant that the construction worker who came to drop off the 50 wood dropped off only 40, then brought the remaining 10 wood back to the main base - before returning to construct the building. Meanwhile, my own worker would drop off 50 wood, and start constructing straight away.
Again, this difference meant that I was struggling much less than him, and that the construction workers needed an adjustment to finishing the construction before dropping off the excess wood (something that is on my to-do list).
Overall, I want to say that I am very grateful for all of the feedback that I have received over the past months (including on the tutorial), and that I am continuously learning more about how people interact with the game.
Until next week!
Weekly Update 150 - Lessons from the Tutorial
Hi everyone,
Considering I was explaining the new tutorial only yesterday, I will take another post to talk about some of the “lessons learnt” from creating the tutorial (which frankly are also a lot of lessons learnt from 0.8).
First of all, I had started redoing the tutorial thinking it was going to be a quick upgrade, but as every time before I had to realise that upgrading the tutorial is a considerable amount of work. This also applies to 0.8 - I recently took stock of all of the changes that have happened since 0.7, which can only be considered a massive scope creep from what I envisioned would be in 0.8. Adding maps led to adding different soldiers. Improving pirate’s peak led to major changes in balancing, etc. From this point on, I will try to keep things a little more contained to themes, and will try to build each part realising that it will probably end up being a much bigger undertaking.
Secondly, on to the smaller things: As I had mentioned before, I have come to very much regret any quick additions or fixes I had put in place for the tutorial while creating it. Between the various issues it caused with the other systems of the game, and the lack of any benefits created by them in the latter part of the tutorial, this “tech debt” really wasn’t doing me any favours. Re-enabling just the ammo purchasing, for example, turned into a relatively big undertaking, considering how “quick and dirty” I had disabled purchasing previously.
Thirdly, I really need to update my debugging statements. The majority of the debugging statements had been put in place as a result of looking for specific bugs - but this means that many of them are not particularly useful when trying to find a new bug that has just occurred in someone else’s game. Once 0.8 has been finalised, I’ll take a few days to update my code to more sensibly provide me with log data, which should help get better control of the sheer size that this project has become.
Finally, I very much enjoy the guidance given by the tutorial to get to the final goal of destroying the pirates. Even though I am not planning on adding substantial quests to the game before 0.10, I may add a limited amount of intermediate quests to the game for 0.9. Having more manageable steps that can be achieved every hour or so should really help break up the otherwise very long-winded final goal in Pirate’s Peak.
Until next week!
Weekly Update 149 - v0.8 Tutorial
Hi everyone,
With (a bit of) a delay, I have finally uploaded the new tutorial for 0.8 to the experimental branch. I’ll take today to talk about what that includes.
First of all, the size of the tutorial may have gotten a little out of hand. I did mention that I was going to have a longer tutorial with open play after, but I did not expect that it would come out to: 210 tutorial steps, about 1500 lines of explanation, and about 2 hours of actual gameplay. Once again, I feel like this is a good blueprint for any future quests we will implement, so even though it is currently the only “guided task” in the game, there will be more of them in the future.
The tutorial follows along 6 chapters (FPS survival, FPS construction, basic village interaction, advanced village interaction, village expansion, and military command), and you can save any time after finishing chapter 1 (load your game from the singleplayer menu). Chapter 5 (village expansion) is mostly teaching you just how much your logistics are getting bogged down by trying to expand, but you can consider it to be a placeholder for when the pioneer wagon gets added to the game.
As an added change that will affect the regular game, I have re-enabled purchasing for ammo only. This means that you can supply your ranged units at the wood tier with ammo as needed, though it will come at a relatively steep cost.
Now considering how far into the week it has taken me to upload this:
