From web dev to games. Part 1

LevonAsatryan
5 min readMar 21, 2024

--

This is the first part of the journey of 2 web developers, that are very passionate about games, and how we start off our game. We decided to write multiple blog posts as a series of historical documents, representing our journey and maybe helping other people who want to start off their own game.

The journey so far

As any game, ours started with an idea. For now we’re not going to give too much about what the idea is, as we’re not completely sure how it will end up ourselves. We started off with having a couple of calls (as we live in different countries), fine tuning the ideas that we have and how we can implement it into a real game.

Issue number 1:

Anyone that is working in software development will tell you that documenting things is a crucial part of developing anything. Not only it keeps track of every decision, it also serves as a reference for any party involved. We found out pretty quickly that verbal communication is counter productive (surprise, surprise!). We needed some kind of document describing our game and how we envision it.

Time for some research! After digging around in game dev blogs, and some videos on youtube, we found out about this thing called game design document. While the existing examples of these documents can be a bit confusing when you’re starting off, after a bit of time it all makes sense. Not only it helps you to put your ideas into physical form, it also helps find issues and flaws early on in the development process.

Issue no 2, we suck at visuals:

Early on in the development, we thought that the best approach for our game is 2D platformer game with pixel art approach. As I was writing down the game mechanics, which included the character changing weapons, changing the armor and the animations for each of those and how they interact with each other, it became very obvious that this will include a LOT of hand drawn animations. With the team being 2 developers, this was obvious design flaw. Not only we suck at creating pixel art, we are also painfully slow at animating 2D assets that seem fluid.

So what do we do? We ditch 2D pixel art, and transform the game into 3D and update the game design doc to represent the changes. Now being 3D does not mean that we are ditching the ideology of a 2D platformer. We still kept the overall “feel” of the game, but we changed the underlying technology that we use to make it easier for ourselves.

Issue no 3, making the game fun:

Even though we’re pretty proud of the story-line we came up with, it doesn’t mean anything if your players are not having fun while playing your game. It needs to have a balance of challenging, engaging, fun and serious. Finding the perfect balance of all of these is extremely challenging, especially when you’re still in the early development. So we decided to not re-invent a wheel here, and go with something that we know. It is fine to get inspired by other games and pick and choose game mechanics from others.

I’m a very big fan of dark souls games, and also saw my game having a similar mechanics and progression system. It also made a lot of sense in the setting of our game.

So the plan was to try and find out why these games are so engaging. For me it boiled down to these points:

  • The overall vibe of the game. The environment, the artistic style and the MUSIC
  • Simple, but engaging combat mechanics
  • Story line, and how it’s told

We needed to start somewhere, so the first step for us was to get a skeleton of the game mechanics.

After updating the game design doc, it looked something like this:

  • Player should have multiple stats that buff different aspects of the game, like strength, agility, intelligence and luck.
  • Progressing through the game, gives the player experience. After certain thresholds the player is able to level up.
  • Levelling up gives the player upgrade points, which they can use to buff the stats.
  • Weapons should have a type attached to them, which will decide what “type” of damage they do
  • Weapons have a base damage and a scaling part, which is calculated from the player stats. (e.g. strength weapons do more damage based on the strength level of the player)
  • Wearable items change different aspects of the player, like reducing the damage received, buffing stamina or hp, or making certain actions faster or more powerful.

This is the bare minimum of the game mechanics. Very RPG like game design as you might have guessed already. So how do we approach a game like this?

Issue no 4: breaking down the game into solvable problems

There are multiple ways you can approach this part. But most probably most people would start off with the section they’re most comfortable with.

For me it was coding.

So I booted up godot editor and put a bunch of boxes around that represent some of the assets that will be in the game later on. The very basics that I could think about is that I need 4 types of “blocks”:

  1. A cube representing the player
  2. A cube representing the enemy
  3. A cube representing a weapon
  4. A bigger cube that represent the floor

After some time, this was our first scene of the game:

Very basic stuff, very basic movement and very basic attack animation (shown in the video later on in this post). The idea was to get a feel for the engine, understand some basic concepts and come up with a module that can basically calculate damage taken from one character to another.
For simplicity, I chose to start off with the player damaging the enemy, as it did not involve coding the logic of the enemy targeting the player. The player is more “controllable” in a sense.

This took about a day to code and model correctly. Mostly because it involved me learning a new environment, a new technology and a new language all together. Arguably that’s not a great approach, but you’ll be surprised how much you can achieve with proper motivation!

In the end, we were able to come up with the DmgCalculator class, which given an instance of the weapon, the attacker and the receiver will return a number of hit points that should be deducted from the receiver.

In the end we ended up with extremely simplistic game:

Nothing fancy right? It looks bad, it isn’t fun and it’s for sure nothing that I would play. But it definitely gives an idea as to how to progress!

However, it is hard to keep your motivation up, when your game looks like this. So we decided to add some eye candy for ourselves. This deviates from our initial plan, but that’s the beauty of working on your own game!

After a day of my partner working on some assets, our game looked like this:

Now, that’s much better!

This is the end of the part 1 of this journey. We hope that these blog posts will help someone to start their own journey!

We will keep making these posts and update the community on the progress and how we developed the game.

See you soon!

--

--