Devlog #3

Howdy everyone, welcome back to our 3rd Devlog. We've got a lot of exciting stuff in store (including an actual store) for you. We did a lot of work on a few large issues, last month, instead of getting a whole lot of small issues like roads, UI, and such working. Whilst the previous Devlog was more about making our game look like a game, in this devlog, we are making our game play like an actual game, having an actual gameplay loop.

What do we mean by that? Well, if we shipped the game today, you'd get some actual usability and game for your money. Don't worry, we're not putting the game in its current state yet in early access, we're not that evil.

Now, sit back and enjoy reading through our devlog, of course, if your eyes are tired, you can also check out the video version of our devlog, with some more gameplay footage as well.

Adding a whole new dimension

At the end of the last Devlog, Thomas had already started working on the 3D world. Now, this was one of the first things that got more or less finished. When I say finished, I am mostly referring to the 3D world generation though.

The first design decision we had to make was the world style, smooth, or voxel-based. We ended up going with voxel-based as it's more regular and easier to implement features like height. Because of this simplicity, a lot of indie devs go for voxel-based worlds. Think about games like Minecraft, Cubeworld, or Teardown.

Then we got to how we want our world to be created. First, we were considering making our own static world, but that would mean we have to create our own voxel world editor and saving system, which would take a lot of time. Instead, we have chosen for random world generation, based on a world seed. The seed makes sure we can repeatedly generate the same world. This means that for our final game, we will have a single map that is the same for every player. Then we'll also add a new-game+ setting where you can play on a fully randomly generated world as well.

Now, we do have some issues with world generation. Or at least, interacting with the 3D world. None of our game logic has been made for 3D worlds, so workers aren't operational yet, and roads and pathfinding are also broken.

Speedrunning gamedev

Then Thomas ended up with COVID, and our development spiked, as he got time off from his main job. Once he recovered a bit, he used these days to put a lot of effort into the game. This is where he finished 3D worlds for example and started working on workstations as well.

Workers also got some attention, we already had them walk around between locations, but they weren't able to carry items around with them yet. This is where Thomas also

Marketplace setting up shop

Now that we had workstations and workers working, we just needed to get them some items. Last Devlog we created the buy and selling logic, now we just needed to tie it all together in a nice UI. This we did for this Devlog, with the base marketplace being fully done now. Now all that is left is creating all the items, although we've already created quite a few of the base items like ores and wood that you can buy.

We started with the base UI, where you can buy the base items like ores, logs, and other special items like leather, string,... These items then get put into the local marketplace buffer system. These can be seen as the crates by the cart. Once the storage is full, buying new items isn't possible anymore, forcing you to pipe out items to standalone storage crates for example.

The UI also has buttons for a selling history, so you can see how you are making your money, as well as create automated orders like buying 10 iron ore every 10 seconds. These features aren't implemented yet though, as we didn't see them as much of a priority for this devlog.

Finished core gameplay loop

So, now we've reached the point where we can get everything working together, creating our first version of the core gameplay loop. What is this gameplay loop? Every game you play has one or more gameplay loops. Think about an MMO for example, leveling up your combat is a gameplay loop, as it consists of you going somewhere, killing something, and getting XP, increasing your level. Another example could be chopping trees, doing a mission in a shooter, or driving between 2 places in a sim game.

For our game, the gameplay loop is mostly a single large one: Buy raw items from the marketplace, use workers to transport them between refinement stations, create more advanced weapons, and sell them, giving you more money to build craft more things.

This is also where the "fun" of our game will be. If the gameplay loop isn't exciting or rewarding, there would be no reason for the player to play the game. We can now finally see if our game is fun or at least has the potential to be so.

Reworked camera controller

Probably the biggest QoL improvement so far. After 3 months of struggling with a hypersensitive, unpredictable, and user-unfriendly camera implementation, Thomas went ahead and redid the camera controller.

The new camera controller is a lot better to use, having smooth scrolling, a zoom function that works on a correct axis, and supports navigation by mouse as well.

As an addon to the reworked controller. In the last devlog, you could already get some fun facts about a worker by selecting them. Now if you select them, the camera will automatically focus and track them as they are walking around the world. You'll also be able to see what item they are currently carrying in their inventory.

Lightning features

Some other small things we got done this Devlog were for example a working autosave implementation, now, if you are playing the game, every 5 minutes, the game gets automatically saved, so you don't forget to lose your progress.

Future plans

Now, what's next for us? By the time our next devlog releases, we have a few things we would like to complete. The first is that our 3D world is fully operational. This means we have a working road system, our workers are able to deal with 3 dimensions, the world looks a bit better and we can get rid of our ugly 2D testing plane. We don't foresee a lot of issues with this one, as at the time of writing we are already working on some of these features, with promising results.

The next large thing is improving the way we assign our workers to a route. The current implementation isn't sufficient as it doesn't allow for specifying what items workers should carry. Also deleting assignments and such isn't available yet either. We've got a whole new implementation worked out for this, we just have to put it into code, make it pretty and make it work. Once this worker assignment is done, I think our gameplay feel will also improve vastly, going from a scrappy proof of concept into an early stage of Minimum Viable Product.

Along the way of those 2 main features, we'll also probably add some more in terms of items, workstations, and 3D models, but those are harder to predict what will and will not be supported, so you'll just have to come back next month to see what we ended up doing.