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.

Don't fear though, everyone goes through this, including us. In order to help you, we've listed some of our most common struggles, all of which one (or all) of us has personally gone through. We'll provide you with some solid tips as well as how you can limit the negative impact these events may have on your gamedev journey.

Programming Roadblocks

So you've started working on your game, and have begun working on your (first) game mechanic. You had an entire idea of how you would implement it, but now suddenly you've hit a wall. No matter how much you try, you somehow can't get the code to do what you wanted. Maybe it's because this is the first time you are using this programming language, or maybe you just are pushing the limits of what the language is designed for.

Regardless, the fact is, you're stuck. You've been trying to get this one thing working for the past week, and you still don't have much to show for it.

Firstly, don't sweat it. Everyone who ever worked with a programming language has gone through this exact issue, not limited to game developers. The first thing you should do is take a break. Just staring blindly at your IDE will most likely not help, and only be counterproductive even. If you can't figure it out after 10 minutes, 2 hours won't help either. Then after your break, try one of the following solutions.

Rubber Duck Debugging

This is a common concept in programming. You'll find rubber ducks on the desks of software engineers all over the world, for one simple reason. We talk to the ducks.

No, not because we have lost all our sanity. Instead, we just vent/rant/explain to the duck what our problem is. By vocalizing your issues and describing what you've done so far, you usually have to think from a new angle. This is because now you are explaining it to something/someone else. Usually halfway through your rant, you'll have Eureka! moment and get a possible solution to your problem.

I know this sounds very weird, but don't knock it if you try it. If you want an even better version of this, try talking to a real person instead of a rubber duck. This way they can ask you questions you hadn't thought about, or suggest possible fixes.

Splitting up the issue

No ducks and no people in your life to talk to? Sometimes the reason you're stuck might be because you are working on too much at the same time. Instead of just having one big issue "3D world generation", split it up into as many individual pieces you can. Then start working on these issues one by one. These smaller issues will go much easier and quicker, leaving you only with gluing them all together for the final product. This step goes much easier usually as well.

Life gets busy

Sometimes, you know what to do though, and how to reach it, but you just can't seem to find the time for it. Because life is simply full of surprises, you never know what may happen that suddenly demands your attention more than your gamedev (side) project.

This can often be very frustrating, as the longer you take a break from working on your game, the harder it can get to get back into it as well.

This is where habits can come in. Ideally, you can create a habit of working on your game in advance. Figure out a time where you can work uninterruptedly on your game, every single day. This doesn't need to be for hours on end, just 30min would already be good. Creating a new habit in the middle of a busy life can be much harder, but with some decent planning and a good work ethic, you can still get it done!

Loss of motivation

A game usually isn't built in just a few weeks. It's often a months- or even a years-long endeavor. During this process, it's usually impossible to have the same high amount of motivation the entire time. There will be times when you will have doubts. Wondering if you aren't just wasting your time, countless "what-if" scenarios running through your head. What if nobody buys the game, or it never gets finished, or it's just not fun.

You may consider calling it quits during these periods, using your free time to chase something new. We may be biased here, but we would want you to stick through and finish that gamedev dream of you, no matter what struggles you encounter along the way.

Take a short break (no more than a few days) and maybe try to reach out to a friend or something. Talk about your game to him, get him to hype you up. Maybe he'll even join the development process? Regardless, ask him if you can use him as an accountability partner.

This would mean that you schedule a call/meetup once every one or two weeks, where you talk about the progress you have made so far. You don't want to disappoint him, so you'll usually always have something you have worked on for the game to present to him.

With assets, we mean more than just 2D or 3D resources though. When using an editor like Unity, or any other for that matter, you will always find it lacking something you need. This is where Engine assets come in.

They are pre-made implementations for a variety of things you may need for your game, like an inventory system, or an input system. You could spend a lot of time making your own custom implementation for these, or you could grab an asset from the Unity asset store that does the heavy lifting for you.

We have personally used all the assets mentioned here, with a lot of them being a key component of our upcoming game Forge Industry. This game is currently in development so you can check out our Devlogs to see how we utilize these assets in our own game.

Rewired

No matter what kind of game you'll be making, you will need to capture player input somehow.

Rewired is an easy-to-use and advanced input system for unity. It supports almost all platforms. It handles controller switching gracefully and supports multiple players and inputs. Rewired works Action-based. This means u don't have a hard binding on an input button, but on the action. This means that you can easily change controller bindings, or let players change controller bindings themselves. Rewired is used in almost any project we start here at BiteMe games, and we give it a full endorsement.

LeanTwean

A lot of games use something called tweening. Tweening is short for "inbetweening" where a certain action gets interpolated over a set period. A few examples of this are changing the alpha of items, smoothly moving a GameObject, etc.

<GIF of something that uses tweening>

LeanTween is our tweening library of choice, it has a lot of base functions and has very little overhead, making it very lightweight. Using LeanTween can often be narrowed down to just a few lines of code, making it very easy to use. If you haven't already, be sure to check it out! It is even free!

A* Pathfinding

A lot of games use some sort of pathfinding. A very commonly used and powerful algorithm for this is A*.

<short A* explanation on how it works in a few sentences (ask William)>

<GIF how astar works (ask William, from our internship)>

This A* asset is great to get started. It has a free version with a lot of features in it already. This can help give you a feel for what it does and how it works. For more advanced use cases that require features like Local avoidance(NPCs take into account other NPCs their position, to make sure they don’t collide) or layered grid graphs (for levels that can have multiple layers)

Bolt

Maybe you may not really have a lot of confidence yet in your programming skills, or you saw the Unreal Engine and like how you can use blocks to create your own game, with little to no actual code required. Unity doesn't have that support natively, however, Bolt is a great asset that brings that ease of coding into the Unity engine. As a free asset, there's no reason not to experiment around with it. Be warned though, some more complex interactions may require add-on assets, which can have a small cost associated with them ($5-20).

Mesh Baker

This asset will probably only come into play once you are in the later stages of your game, where you are running into performance issues. Here you want to optimize the way props (3D models) and scenes are handled in your game.

As the name says, it bakes your model's meshes into a new, optimal model. For example, let's say you have a wall model, you don't need to have any meshes on the inside of the wall, as there is no way for the player to ever see it. Without the optimization, the inside of the wall will still be loaded, taxing the player's system and lowering performance.

As a quick recap, we're working on the automation game Forge Industry. Last month we started working on the game in our spare time and created a basic game that had some of the core mechanics, but no real playability yet. This is about to change though. For a full update, you should head over to our previous devlog.

UI improvements

One of the first things that were done was the UI. Marnix started by creating a bunch of extra mocks of the menus. These outlined the key actions the user should be able to do in every UI element. Thomas then implemented the basic UI into the game scenes functionally (but it wasn't pretty). Marnix then took over again in order to add some styling and make it look more pretty.

This led to the implementation of a pause menu as well as an actually usable save menu (Thomas had written the code for this in the previous devlog). Just from first impressions, our game looked much better now. This also made it feel much more like we made a lot of progress on our game though, as it now started to take shape as an actual game, which was pretty rewarding.

It's important to note that this UI still is nowhere near what we actually want for our end game. Instead, we are using this UI as a stepping stone between having no UI (apart from the in-engine start button) or a fully finished UI We applied the 80/20 rule for the UI. We spent 20% of the total time required on the UI and already got 80% worth of value. Once our game is nearer to completion, we will give it another overhaul. Then we can also assign William on creating custom sprites for everything as well instead of just using plain, colored borders.

Game saving

Thomas spent the first part of the sprint working on the game's save system. This was something we wanted to have finished early in the game. It would also make our life easier down the line. Instead of creating a new test game every time we want to do something, we could share a previously made save. This savefile would then feature a full in-depth setup so we can really test the scalability of our game.

There were 2 main challenges regarding the game save system. First of all was how we wanted to structure our saves, and how the user would interact with our saving. Marnix and William had some conflicting visions about this implementation in the beginning, although they got resolved in the end.

We ended up going for a 2-tiered approach in our save structure. The highest level was what we reserved to as a "profile". This can be seen as a single world the player creates. Then, each profile stored 3 kinds of actual saves. Quicksaves, autosaves, and named saves. These were all stored under a single profile, and if the player just presses "continue", whatever save is the most recent will be loaded.

As the name suggests, quicksaves are bound to a key and will immediately save the game in its current state. There can only be a single quicksave, and making a new one will overwrite the old one. Autosaves are saved periodically and are queued, after x saves, the oldest one will be replaced, with the latest save taking its place. Named saves are saves where the user actually presses the "Save Game" button. Here they can give a meaningful name to their save as well. This is especially useful if they are about to do something to which they want to easily roll back to later on in the game.

The second issue was finding a way to generically serialize (turn a game object into a file) our save data. This was especially tricky because not every game feature was implemented fully yet back then. Workers for example didn't do much except existing, with no inventory data yet for example.

We don't want to fully rewrite our save system though every time we change one of the mechanics. This is why Thomas spent quite some time figuring out how exactly to serialize. In the end, we ended up with a relatively basic but effective serialization implementation. After all, this is something that has been done plenty of times for all kinds of projects, so research was also not too bad.

Item refactors

One of the big blockers we had was the item refactoring. We couldn't work further on our crafting mechanism until we remade the way we implemented items. This is where Thomas and William put their heads together and came up with a more scalable system that combined a material with an item type, instead of having each combination be a unique entry.

Unity Playmode Testing

One of the biggest setbacks or delays we encountered was implementing our testing strategy. We had given Jamie the simple task of deleting roads or buildings. The actual coding and implementation of this feature weren't that big of an issue. After only a few hours this was implemented and all seemed to work.

However, we had just implemented a DevOps pipeline (we'll release more information about that in an upcoming video) and wanted to really get our testing strategy working. William had already implemented some Unit Tests for things like road orientation or dynamic world events. These are easy logic tests though and don't require any in-game interaction. Deleting an in-game object was harder though, as we had to simulate the actual game.

This is where Playmode testing comes in, you create a scene and mock your inputs fully code-wise, without anyone actually moving their mouse or pressing buttons. There were quite a few issues with this implementation though, such as implementing assembly definitions, or support for overriding the input library we were using, Rewired. This ended up with Jamie having to research this for weeks on end and try to get something working.

So why didn't we just drop the testing part if it took so much time? We actually could, however, everyone in the team agreed that getting these tests working would help a lot down the line to prevent pushing broken branches and limiting bugs that could appear.

Dynamic World Events

William also started working on one of the features that should make our gameplay more engaging: Dynamic world events. This will cause different kinds of scenarios in the world in which you are blacksmithing. Perhaps a war breaks between the elves and barbarians, increasing demand and the selling price for bows. Or a new king is crowned, and he requires an order of 10 decorative golden swords. Or maybe there are some events that don't even influence the actual game. Instead, they just add to the feeling that you're not just a machine automating everything.

Smaller features

We also did a bunch of other small features, which aren't exciting enough to get their own full explanation, so we've listed them here:

• There were a bunch of issues still with roads last Devlog, those have all been resolved now and they connect nicely.
• Apart from making the UI look nicer, we've also added some UI sound effects to liven up the experience.
• Now that we have a UI, we already got a first proof of concept working in regards to our multilanguage support. Current languages are English, Dutch and French as those are the languages we know best.
• Workers can now be interacted with, displaying a panel with some fun facts about them. Later on this panel will also be used for displaying its inventory and current route.

World generation

Thomas also spent the last week working on dynamic world generation. Currently, our game is just on a flat 2D plane. However, that's not really what we want to go for in our final game. We would want some level of mountains, as well as rivers going through our terrain. The plan isn't to have everything purely randomly generated. For our main 4 worlds, we want to have a static world that's the same for everyone. The random worlds can be seen more as the NewGame+ of our game if you want to spice up the game a bit.

This feature isn't completed yet, so it doesn't really count as a finished feature. Since Thomas did spend a lot time on this feature already though it does deserve a mention as part of this Devlog.

What's next for us?

In this sprint, we focused on a lot of surrounding features, instead of the core gameplay look. We now have UI and dynamic world events for example, but we still can't really buy, sell, or craft items. I think this is not ideal as we still have no idea if our game can actually be fun. That's why for this next sprint, we really need to focus on this. The mean features we'd want to see finished is:

• Having a fully functional marketplace where we can both buy and sell items
• Workers carrying items between workstations. The code for this should all be there but we haven't been able to test this
• Have a first workstation, probably the Refinement Station, fully working

These are just the features for the core gameplay though. Some other things that we are also aiming to do are:

• Getting a first working version of 3D world generation
• Moving away from the whitebox stage for our main workstations

Of course, we'll have to see how much of this we can reach. Although, I have faith in getting the item workflow working now at least. Be sure to check back next month, April 29th, for our next Devlog and to see how much we've actually made happen!

However, books should not be disregarded, as they can go deep into a specific topic. I am quite an avid reader. Hence it was inevitable for me not to get into the rabbit hole that is books surrounding game development. By now, I have read quite a few game development-specific books, and think it could be a great thing to share with all of you.

That's why I have compiled a list of my top books for game development. I've only listed books I have read personally, but at the end, I'll also include what's on my "To Read" shelf. Also, if you haven't yet, be sure to check out the accompanying YouTube video regarding my top book picks! All links mentioned are affiliate links, so if you end up getting one of the books for yourself you'll be supporting us as well.

Blood Sweat and Pixels

Jason Schreier, 304 pages, Amazon.com

I think this book is amazing to introduce someone to the world of game development. It tells the story behind how many of the large games we know today were made. It's not just successes though, it also covers how almost every game in the book almost didn't come to fruition due to a variety of issues. Changing visions, funding being pulled, accelerated deadlines, all of these things are common in the game development world.

Video Game Storytelling

Evan Skolnick, 208 pages, Amazon.com

Back when videogames just started, the need for a (good) story wasn't there yet. Over the past 20 years, a story has become a requirement for pretty much every genre of video games. That's why I think this is such a valuable book as well. Evan Skolnick is a distinguished game writer, having worked on various games such as Star Wars 1313 and Cuphead. He covers how you can create your own storyline for a videogame, without previous knowledge of writing for any media.

The book is split up into two distinct parts. The first part gives you a high-level overview of how you can write an enticing story for your own video game. It dissects the most important parts of writing like how to apply the hero's journey to your game, and how to divide your game into these arcs. It also covers topics like how to write your characters and locations, making it all feel like a cohesive story.

The second part of the book then dissects the roles everyone has in a game development company. He goes over all the different roles, from the creative director to the sound designer, to the project manager, the developers, and everything in between. Whilst it may not be obvious, without all of these roles contributing their parts, the story would never feel as good. A creative designer may create the best story ever, but if the underlying score doesn't align with the mood he wanted to portray, the player will be disconnected from the world.

The Lean Startup

Eric Ries, 336 pages, Amazon.com

This one is not exactly game development related, but more software engineering/business in general, so it still counts in my opinion.

The term lean has been around since mid-2000 when Toyota implemented it in their car factories. Lean also laid the foundation for Agile, which is the main working methodology used in software companies all around the world.

The book is more of a business book, which shouldn't deter you because a game studio is still a company after all, and draws a lot of comparisons to traditional tech startups. The book gives a lot of actionable advice and information as to how you can build out your startup, innovate and get funding.

Masters of Doom

David Kushner, 368 pages, Amazon.com

Personally, Id Software has been the game development studio I always looked up to. In Masters of Doom, David Kushner creates a biography of the company, the key members, and the downfall of the original Id Software with John Carmack and John Romero.

I read this book more for the entertainment factor, as compared to the rest of the list, there's not that the book wants to learn you. The technological issues back then aren't relevant anymore, and the gaming landscape has changed so much since then (partly due to the success of games like Doom) that the management principles are hard to apply as well.

Which books are next for me?

Above are just some of the books I've read, but I'm not planning on stopping just yet. I will be changing things up with some non-gamedev related books first, but I still have a whole catalog of books I'm planning to read:

The art of game design

Jesse Schell, 654 pages, Amazon.com

This book is the most talked-about by /r/gamedev, even though it's not even a videogame book. It covers the main concepts of games in general and the theory around what makes games fun to play.

Gamedev: 10 steps to making your first game successful

Wlad Marhulets, 175 pages, Amazon.com

I don't even remember where I first encountered this book, but something about the premise intrigued me. As I'm personally more busy with the high-level of BiteMe Games then the rest of the team, books regarding the management and expansion always intrigue me as well. The fact that it has great reviews is a good sign as well.

Looking at traditional software development, a cool app or website can realistically be made in a single day. Unfortunately, the same can't be said about game development. Due to the increased complexity and wide variety of tools available, it can all be very overwhelming. What game engine will I use? What programming language? Will my game be 2D or 3D? How do I know if my game is going to be fun?

That's why we'll be giving you some tips and ideas on how to begin (and finish) working on your very own game.

Before making your own game

The first piece of advice is to not start with your own original game concept as your first game. This is especially the case if you have had only limited interaction with programming languages or other tools surrounding game design like 3D or 2D art or level design.

Instead, we recommend you to just follow one of various start-to-finish YouTube tutorials. Here you will follow along in making simple games like Minesweeper, Flappy Bird or Donkey Kong in Unity.  These will guide you through the entire process required for a game, using premade assets so you don't need to worry about making your game look good. They also hold your hand throughout the entire process, as the Unity (or any other Engine) can be quite daunting.

What game engine?

Now that we have had our first experience under the belt, we can start thinking about our own game. And more specifically, its engine. We may have a slight bias here for Unity, but there are plenty of engines that can work. If you want to stick to something simple and mostly for fun, Gamemaker Studio is a great way to quickly create a nice 2D game.

If you want your game to be really pretty, with high-poly graphics, Unreal Engine is another very good option. What Unreal also offers is a relatively easy to use, drag-and-drop based alternative to coding. However, if you want to create more complex mechanics, you will need to use C++. This is not the most developer friendly unless you already have a solid grasp of coding.

That's where we think Unity offers a great middle ground, it's a very extensive engine, yet it is based on more easy to understand concepts. There is no native drag-and-drop coding (there is an asset for that), but it uses the much more developer friendly C# instead of C++.

An honorable mention also goes out to Godot. Although since it uses Go as a programming language, you will not find as much documentation for it due to a much smaller adoption rate.

The look and feel: Assets

Programming a game in an engine may be one of the core parts of gamedev, but you won't have much of a game without the use of various assets. These are things like 2D art, 3D models, background music, sound effects,

Whilst you could use only premade assets, this isn't great if you are planning on selling your game, as it will quickly be dismissed as an asset flip. Instead, you will have to create at least some custom assets such as 2D and 3D models. Sound effects and music can more easily be used from assets without being recognized as assets.

For creating your own assets, you don't need fancy and expensive software though. We've compiled a small list of which software you can use for creating your assets:

• 2D Art: Krita and GIMP
• 3D Models: Blender
• Music: Waveform Free/Garageband

Ready player two?

Many aspiring gamedevs read the stories of Stardew valley or Undertale andwant to become solo indie game developers as well. However, these indie games are exceptions. If you have the option, try to bring one (or multiple) friends or partners onto the project. Creating a solo game is like playing on New Game+. Bringing someone along on your journey will help with speeding up development, hold you accountable, give instant feedback, help you share your vision and so much more. It will also make the gamedev journey more fun, as you have someone to talk and relate to your struggles as well.

Our other gamedev tips

So now that we have gotten you through the how's of gamedev, let us also share some smaller tips that we recommend everyone to stick to:

• Consistency is key. Regardless of how busy your life is, spend at least 5 minutes a day on your project, this often leads to longer working sessions, but is super beneficial if getting started is an issue for you. It will also prevent you from skipping too many days and losing interest
• Use version control. Unity Teams, GitHub and GitLab are some great tools to use for this. This creates "checkpoints" of where you were in your development journey, and can help if you want to go back in time a bit, as well as track your exact changes.
• Ask feedback! A friend or family member might have something useful to say. See how they interact with your game, and tweak it accordingly. Short feedback loops are really important for almost any project.

Here be dragons

No matter how many tips and advice we give though, it is important to know that there (just like most things in life) isn't a quick cheat to quickly create huge games and bypass the not-fun gamedev parts. You will struggle at times, or feel uncertain if you'll ever finish your game and doubting yourself.

This is where you can separate yourself from the rest of people who want to create games, but end up failing. This is where you just have to push through, keep working towards your goal, no matter how fast or slow your progression may be. And then in the end, you will see the results. With enough motivation and discipline, you will be able to learn that coding language, finish that game or master 3D modelling, and reach that goal of yours!

Game Design Documents (from here on referred to as GDD) have been around in the gaming industry for a very long time. They served as the foundation of a game's idea, being created as one of the first parts of pre-production. They outline the vision, story, art style, technologies, sound design, and much more in regards to the envisioned game. Usually, a single individual or small group makes this. This GDD is then used to share the vision with the rest of the team or to pitch it to publishers. All of this without having an actual prototype. It also serves to get new members of the team, who weren't around since the conception of the game, a quick start on what they will work on, and to align their vision.

Almost all of the influential games that were created had some sort of GDD. Some were short, few-page descriptions of the game, like the original Diablo or Grand Theft Auto GDDs. Some were very extensive books almost, outlining the entire game and lore, like Tom Hall's (Id Software) Doom Bible.

Their loss of relevance

Over the years, however, the way we develop games and software has changed in multiple ways as well. AAA development teams started spanning multiple studios geographically, with 100s of people working on the same project. Software engineering changed as well, moving away from a waterfall (create the design first, then write all the code, then all the tests, then deploy, without any changes along the way) approach to an Agile/SCRUM-based approach.

If we look back at the above GDDs, Id Software started with only a few key developers along the way. All of them working together in the same physical space and having direct lines of contact with each other. GTA's GDD even lists who was working on the project, a mere 10 people. If we compare that to the 2500 that Rockstar has now, putting all members of that team into a single room is simply impossible.

Whilst game design documents do still exist in these big companies, they have evolved to something that is not as easy to make or digest anymore. Whole teams of concepts artists and writers now work together on the GDD. They only deliver information to the developers in the form of feature request or bug tickets. Marketing departments create their own case studies in advance to a game being greenlit to start development even.

On the other side of the spectrum, the popularity of solo-developing games has also increased, with easy to use engines like Unity allowing solo-devs to create a game in just a few weeks or months. When working alone, one of the key reasons of a GDD, communicating your vision with the team, drops off. You can store all the information you need in your brain, and just want to work on developing the game, not writing boring documents nobody will read.

It has solid advantages

Because of these changes, in both team sizes, and development approach, should you still use GDDs?

This is also why you'll often hear the advice "don't bother with GDDs anymore, they are a waste of time", and "they block you from making changes along the way". Both are valid reasons, but there are often still cases where a GDD comes in very helpful.

There are a few main reasons why you should still use game design documents (even as a solo developer):

1. It let's you organize your thoughts. Instead of a bunch of thoughts floating around your brain, you now solidify your idea into a structured document. Trust me, everyone forgets something, especially if you are still early in your game. You will still rapidly change your ideas for mechanics or story. This makes our little balls of grey matter very confused. Instead, by at least writing down some core aspects of each mechanic, you can still reference them, and write down changes as well.
2. You can still share your vision for feedback. Let's say you have the greatest game idea ever. A Battle Royale where everyone plays as goats, fighting for resources like grass and shrubs. You may be certain that this game is going to be the next Minecraft or Undertale, when in reality you will probably not reach the 100 starting player capacity. Having someone you trust and who's feedback you value go through your GDD can be a very sobering thing. Suddenly you can realize what parts of your plan aren't great, what mechanics you could change, which ideas are good, and which ones are just plain bad (I don't think anyone is asking for a goat simulator reboot).
3. Starts your marketing early. Think about it, your game design document will contain an elevator pitch, short description of the game, longer description, the mechanics/setting that makes it a unique game, target demographic, concept art,...  This will make your job of marketing the game and generating interest much easier, as you already have the base resources required now. Whoever does your marketing, will thank you.
4. It helps with your funding. When trying to achieve funding for your game, nearly every publisher or other kind of grant institution will ask for either a business plan, Game Design documents or both. If you're able to just send them your GDD, where you have thought out aspects like marketing, expected sell price, audience, platforms,... you'll give off a better impression. Moreover, by thinking about these things from the start, you can implement them into the core of your game as well instead of hastily tacking them on at the end. It's also easier to create a business plan at the start of your project compared to retroactively adapting the current state of your game into a business plan.
   

What about indies

For our upcoming game, Forge Industry, I wrote a game design document, and it has definitely helped the development process. If you have a somewhat clear vision, writing one doesn't take more than a few hours. I then shared it with the team where they tore the GDD apart for another few hours. At the end of this, we all had discussed the idea, with the rest of the team finding some flaws in my design, which we tweaked. Now we had a very focused, 15 page document all of us stood behind. Whenever we weren't sure anymore how the mechanics would function we can just reference it.

I'm not telling you that this is the best solution for every developer though. If you are a solo developer, you should shorten your GDDs to something more simple. It's important to still use the GDD as a document to write down your core game focus, but describing mechanics in depth isn't required as you don't have to share your inner workings with anyone from day one.

A popular alternative that has popped up for solo developers is the One Page Game Design Document. This keeps the same main themes as a regular game design, but shorten it to a single (or 2 at most) pages.

Conclusion (and download)

In short, GDDs are still a valuable tool, and should be used in nearly any use case. Even if you are a solo indie developer, it can always still be a fun thing to create a GDD!

I've created my own version of a GDD template, which I've used for creating multiple GDDs myself. You can download the template for free here. I wish you the best of luck on your game design journey.

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!