Devlog #1

Hi everyone, welcome to the first BiteMe Devlog, written edition. If you haven't already, you can also go check out the YouTube video. There we talk about our progress throughout the past 7 weeks with some visuals. If you want a longer, slightly more in-depth post, feel free to stay here. I'll walk you through everything we've been up to since the start of our work on Forge Industry.

Normally these devlogs will only cover what we've done in the past month. This one will be slightly longer since we've been working on Forge Industry for a bit more than a month.

Conception

The idea of Forge Industry was born on new years eve, 2021. I hosted a new years party and everyone of the BiteMe team was invited (we are also friends after all). Somewhere along the way we talked about our plans, having scheduled a gamejam that next weekend. But we weren't even sure yet what the topic was going to be. We went through a variety of possible game ideas until we ended on a kind of Factorio like automation game. The exact setting wasn't determined yet, but we now knew the core concept of our game. We'd figure out the rest on the gamejam, right?

Pre-production

Everyone really liked the above idea, but I was especially excited. One free afternoon I sat down and wrote down everything in terms of possible mechanics, core game loops, levels,... into a game design document (stay tuned as we'll talk more in depth about GDDs in an upcoming post). I also added the setting, a blacksmith in a fantasy setting, to move away from traditional (sci-fi) industrial games. The disadvantage of this setting is that expansion and very advanced production types were hard to justify. This was actually an advantage for us though, as this way it organically blocked a lot of feature creep. There's simply no easy way to explain computers, conveyor belts and whatnot in a medieval fantasy setting.

I then shared this document with the rest of the team, and after some constructive feedback and some changes, we ended up with a clear, documented vision of what we wanted the game to look and feel like in the end. This was probably one of the best decisions we did early on. We now could just reference the GDD and not waste much time arguing how we were going to implement certain mechanics again.

Before the actual gamejam started, Thomas already made the project foundation. This were simple things like setting up the folder structure and implementing some boring stuff like:

• Multi-language support for strings using a custom implementation
• A basic grid system onto which buildings could be placed
• A cheat/dev console for executing commands like spawning workers and giving resources
• Basic controls for moving around the game grid

Gamejam

Then the day of the "gamejam" arrived. I say "gamejam" here because we strayed quite a bit away from the traditional concept of a gamejam. Normally in a gamejam you start without much of an idea of what you want to do, and after the gamejam time is over, you don't do that much with your product anymore. Or if you do, you just keep the mechanics, but rewrite the entire codebase into something cleaner. The main point is usually to team up with some friends for a fun challenge.

We gave ourselves 36 hours to work on the game, from Saturday 8 AM until Sunday 8PM. Throughout the gamejam, roles would also be quite easily divided.

I was in charge of 3D models, explaining the mechanics if the GDD wasn't sufficient, and further creating all the main materials, resources and finished products you would be able to craft in the game, as well as all the crafting recipes. Since the gamejam was hosted at my place, I was also in charge of catering (we had lasagna, fresh ramen and takeout pizza for those wondering).

William, our 2D art guy, wanted to really focus on creating 2D art and UI mocks of the game, finally being able to flex his drawing skills a bit. As we neared the end of the gamejam, he also shifted gears and joined part of the programming.

Thomas and Jamie had the task of actually making the game a reality through pair programming. Before the gamejam, Jamie had never touched Unity before, although he is proficient in C#. It was also a 36h opportunity for him to learn Unity with a hands on example. Thomas was our Unity guru, mainly taking a back seat. That the didn't mean he didn't work though. He did the thinking about how to implement the mechanics and explaining the Unity project structure, but with Jamie writing the actual code.

The actual gamejam was a blast. In the beginning everyone was hard at work on their respective tasks. The advantage of everyone being in the same room was that we could very rapidly get feedback on anything we made.

At the end of the gamejam, we were all starting to get quite worn out. We saw we only had a few hours left, with most mechanics barely being implemented. Over lunch, we put our heads together, figuring out a plan for what features we would focus on, and tried to give a last final push. We had already roughly implemented roads, workers and workstations on their own. Now the main challenge was to get all of them working together. This challenge proved to be quite big, and we got very close to this being implemented. Alas, when the clock hit 8, and we tried to go through the flow of assigning a worker, all we got were NullReferenceExceptions...

Some other, smaller things we got done during the gamejam:

• UI for the game including menu for all the possible buildings/roads and hotbar
• Storage of global resources the player needs to construct workstations/roads (gold, stone, wood)
• Creating a global tick system for timekeeping how long recipes take to make.
• Brushes for quickly creating long stretches of roads, as well as automatically rotating the roads (game logic wise).
• Ability to rotate buildings
• 2D icons for the main resources, as well as some icons for roads/buildings

Defeated, but still proud of our achievement, we went back home. Perhaps not with the desired outcome, but still with a lot of experience under our belt.

Aftermath

After the gamejam, we all needed a break though. We may have pushed slightly too hard in the end, not really having any moments to relax that weekend. And with our normal (programming) jobs calling upon us the next day, we weren't looking forward to more programming.  This killed our mood, and also our momentum. Starting to program/work on the game again was a chore, with only the bare minimum being done. The week after the gamejam, Thomas fixed those Exceptions and got the worker assigned working relatively easily. The week after that, William fixed the road orientations, and I had to redo/create some more road models, but there were still some annoying bugs.

Resurrection

After a few weeks of very minimal input, something needed to change. Through Thomas his great management, some downtime from my work, and joint motivation/annoying of William, we were able to pick up the pace again. With fresh energy, we started working more on the game now, as well as BiteMe Games in general. Whilst most of the mechanics weren't fully implemented yet, we now knew the flow of pretty much everything. Soon after this, we were able to implement workstation recipes (although the UI for this is still pretty bad). We also finally tackled the pestering road issues, finally having those working.

Thomas and Jamie also created a CI/CD pipeline for our game. Whilst this may not seem like an important thing for a game, it is actually a good practice to do for any coding project. This pipeline automatically creates builds of all our commits, so we always have a working build of our game, as well as enforcing our unit tests. As part of our game, especially one that has as much of a mechanics focus as Forge Industry, unit tests prove to be a worthy tool to check that the changes we push don't accidentally break the game. This was all done using Gitlab's CI/CD as we are using Gitlab for version control with LFS (Large Files Storage) anyway.

Vacation

Then, the 2nd week of February, half the team dropped out. Thomas took a long-overdue vacation for a snowboarding trip with his dad. Marnix also took a week off the main Forge Industry project in order to focus on writing this exact blog post, as well as a bunch of other content surrounding our online content, as well as a super secret project (stay tuned for that one as well).

This left only Jamie and William to work. William finalized the roads implementation, making it all pretty. Jamie worked on changing some things regarding the game's grid, allowing for the grid being spawned together with items on the grid. This is required for the start of the game (since you always start with a marketplace and a forge), as well as for loading saved game states.

Since this grid was the base of our game, it was also quite a complex undertaking to refactor this into something that we use as a base for the rest of our game. Every step of the refactor process only seemed to create more bugs and issues. This led to the game simply not even compiling. It was clear that this grid needed more than 1 person to work on it.

Present

Once Thomas and I returned from our vacations and the whole gang was back together, progress was being made again. Especially that we had a tangible "deadline", this devlog, we wanted to show as much of as possible for our first update.

This started with the team activity of getting the grid refactored. This was also getting critical as there were a lot of dependencies on this one task, like loading/saving the game, generating a new game. Also if we created a lot of new buildings which implementation would have to be changed in terms of the grid, this would also lead to doing the same work twice. After a few evenings of multiple sets of eyes looking at the issue, as well as trying to prevent future issues, the gridbuilder was refactored.

In the meantime, we also updated our backlog of issues, so this means we had plenty of stuff to do now. Thomas started by working on loading and saving games now that the gridbuilder was done. Marnix also created a first version of 3D models for paved roads, which William then implemented. We wanted these multiple kinds of roads so we could use it to work on certain mechanics later. In the game, we will be limiting the amount of foot traffic each road can take from workers, thus requiring the player to really plan out their road layouts.

One issue that became clear in regards to the 3D models is that the scale of buildings and roads in-game was wrong. We were going for a relatively low-poly look for our 3D models, which we seemed to have done looking at the models standalone. However we had forgotten our game will have tens if not hundreds of these tiny buildings, making the scale in-game seem completely off.
This means we need to redo most if not all 3D models. This is the same with paved roads, one of the latest additions model wise. The level of detail seemed low-poly when taking up most of my 34" monitor. However, when given only a few pixels in the actual game, it seemed off, with too much detail and broken sizes.

With the gridbuilder refactored, Thomas finished loading and saving the games, writing away the current grid data to an actual save file, which can then be used to load a game back up. We immediately created our different save structures, named, auto and quick while we were at it.

With saving and loading implemented, the Devlog was looming over our shoulders. We finally implemented some graphical features that would make the game feel more like a game. Mainly, a main menu with mocks made by Marnix, followed by an implementation from Thomas. This is also a prime example of how managing expectations can prevent some disappointment upon seeing the final product. (Don't worry we are still planning on making the Unity version more pretty)

Some other quick features were UI sounds, settings and basic localization implementation. This latter was currently done in English, French and Dutch (the three languages we are fluent in). Full on localization is something we are putting aside for the final months leading up to release. These small features, as well as importing whatever icons we already had available, also meant the game went from downright hideous to somewhat resembling the concept of a game, which was our goal since we are sharing our progress online and don't want to scare everyone away.

Of course, whilst I'm writing this Devlog (currently Sunday 20th of February), the rest of the team is still hard at work to keep adding features. Adding these to this article would be too inefficient and time consuming though, so you'll have to come back next month for a better look at those.

Future

Now that we've gotten you up to speed for this devlog, what are some things we are looking forward to finishing over the next month? Probably having implemented all of the core mechanics (such as buying/selling items and the full flow to craft a single item) are the ones that come to mind. Apart from that some more work on the 2D and 3D department would be nice as well. Moving away from our current, ugly whitebox workstations would also do wonders in term of the look and feel.

As with the way development is, none of these are guaranteed though, so be sure to bookmark next month, the 25th of March, for our next release of the Devlog!