Shadowdancer Devblog Week 7 – Vertical Slice I.

Last week we began a new project, and start building the game up again for the Vertical Slice. We finished to build the level and adding the gameplay elements to it. We fixed many issues that came up during that. This video would be very long if I would talk about all of these, and to be honest, many of them aren’t that interesting.

I picked a few problems and ideas that actually taught us something new.

Transparency shader - Low FPS

We had the problem when the player hides in the bushes it will cover most of the viewport.

I made a transparency shader that looks much better than the standard shader. I’m not a shader programmer, didn’t learn the syntax. I have some experience with the material editor in Unreal Engine, so I needed a similar solution to make a shader. My choice of tool is Amplify Shader for this task, which is a great tool!

Regardless of all my efforts, the result was devastating: the FPS rate dropped from 100 to 30 on my machine. I should think about it earlier. If you have hundreds of transparent objects on your scene, that nothing near to optimal in deferred rendering.

I could make a script to switch between the opaque and the transparent version of the objects, based on the distance from the player, or otherwise optimize it. However, Dotti had a much simpler solution for the problem: she pushed all the bushes into the ground a little.

This way she solved the cover problem almost entirely. Elegantly simple.

Real-time Global Illumination

When generating the precomputed Global Illumination takes more than a few minutes you are doing something wrong. We never really dive deep into this area. We know something is wrong, but what?

The answer came in the form of an article series from Unity: Introduction to Precomputed Realtime GI. Worth to read all the 9 part of this series, but here is a short list to properly set up your scene for Realtime GI:

  • Set Lightmap Static to true on big objects, like cliffs, large rocks or buildings.
  • Set Lightmap Static to false on small objects.
  • Cover the playable parts of the scene with Light Probes. (specific article from the series)

After we went through these steps, our generation process speeded up and finished under 1 minute!

New Feature: Shadow Objects

Shadow Objects only visible in shadow form. When the character enters the shadow form, she partially travels to the Shadow Plane and can see these objects. Right now we have two ideas about how we can use this feature.

Give the player guidance. The shadowlings used shadow runes to mark their passages in a way that only they can detect. Only those can see these signs who steps into the Plane of Shadow.

These objects are not just visible in shadow form, but they are also touchable. The player can stay on them as long as she can see them. We can make bridges and platforms that disappear if the character steps out of the shadow.

That’s it for this week, hope you enjoyed this article. Next week we continue working on this project and getting closer to the Vertical Slice.

We’ll see you all next time!

Ribbon Compass Script

I made this script for a freelancer project originally, which was a sailing game with pirates and ships. We needed a compass, and we wanted to show the player, how the wind affects his sailing speed.

The basic idea here is to have a horizontal grid layout with Text elements. I call this the ribbon. The script moves this ribbon horizontally based on where the character is facing.

I only want part of the ribbon visible, so I use the mask component.

The problem I encountered is circularity. I wanted to translate from the end of the ribbon to its start seamlessly. The setup below resulted in a failure, the compass ran out of letters.

SE — S — SW — W — NW — N — NE — E —

I figured out I have to make duplicates. I only move the ribbon between the two S letter and let the overflowing part simulate the circularity.

The script

public class RibbonCompass : MonoBehaviour
{
    [SerializeField] Vector3 NorthDirection = new Vector3(0,0,1);
    [SerializeField] Transform Actor;
    [SerializeField] GridLayoutGroup ribbon;
            
    float _angleMultiplier;

    void OnEnable()
    {
        _angleMultiplier = 2 * ribbon.cellSize.x / 45;
    }

    void Update()
    {
        Vector3 actorDirection = Actor.forward;
        float angle = Vector3.SignedAngle(actorDirection, NorthDirection, Vector3.up);

        Vector3 ribbonPosition = ribbon.transform.localPosition;                   
        ribbonPosition.x = angle * _angleMultiplier;
        ribbon.transform.localPosition = ribbonPosition;           
    }       
}

The script is pretty simple. We need three variable for the inspector: 

  • The direction of the north: as default, I set it to Vector3.forward.
  • The actor transform. We’ll compare it’s forward direction to the north direction.
  • The ribbon. This will be a GridLayoutGroup.

We also need a private variable to store the angle multiplier. I’ll explain it later but first, let’s see what this script does.

  1. Calculates the angle between the actors forward and the north direction.
  2. Then sets the ribbon position in a way to show the right letter.

I’m using text game objects for the letters and for the separators (—). Each of these cells has the same width value, defined in the GridLayoutGroup.

Between North and North West there is 45 degrees difference in angle. If I’m staying in the center of the N letter, I have to move 2 cells:

  • I move the ribbon half cell to arrive at the start of the separator.
  • One full cell (the separator).
  • Half cell again to reach the center of the NW cell.

That’s being said, every 45° needs to move the ribbon with 2 cell width. Instead of calculating each time in the update function, I precalculate this and store it on the _angleMultiplier variable.

How to use the component

The component you can download from the Gumroad (for free) has a slightly better inspector, and also contains the color changing feature.

  • North Direction: this is a world direction. As default it is the Vector.forward (0,0,1) direction
  • Actor: This is the transform which forward will be used to determine the facing of the player.
  • Marker UI Image that will change the color based on the direction
  • Ribbon: The Grid Layout Group that contains your cells.
  • Special direction: The script will change the marker color from the default to the special when the Actor faces to this direction.
  • Color Blend: With this curve, you have more control how the two color should blend into each other.

Shadowdancer Devblog
Week 6 – Throwing out the project

Last week we finished the playable prototype, and during the weekend we gave it to our friends to test it. Now it’s time to throw everything out and start to build it up once again. No. I’m not joking, and I’ll explain it in a moment, but first, let’s talk about what we learned from the playtesting.

Playtest result of the prototype

One of our testers took her time and captured how she is playing our game. Watching this gameplay was fun, and very informative at the same time.

If you are working weeks on a game, you become less aware of the gameplay problems. You don’t make mistakes, because you know how it works. This video pointed out some issues that we couldn’t figure out. These were gameplay and level design problems that I explain later in this article.

We discovered two obvious problems just by talking with our testers:

  • In the default Quality Settings, the lower ones disable shadows in the game. While we knew about this, we didn’t realize this will be a problem, until one of our testers started to play without shadows… well, that totally ruined the gameplay for her. We have to make our quality tiers, to get rid of this problem.
  • Two of our testers went off-road. Leaving the nicely detailed level behind for a flat nothingness. We need invisible barriers to keep our testers focuses.

First Milestone: The Vertical Slice

With finishing the playable prototype, we closed down the prototype phase of the development. This also means we have to throw out our current work and start it again from scratch. A hard but necessary step since the prototype is some kind of sketch, where we drop in everything that seemed to be fit.

We spent most of our week to set up a new project, importing the assets we want to use, rebuilding the scene and writing the codes we’ll need for the game.

We made some changes on the level layout since the one in the prototype didn’t guide the player well enough. They didn’t find the shadow gate, because the level leads them right into the camp.

Three Levels of Communication

During the prototyping, I combined the 3D Game Kit event system, with my own game architecture that is based on scriptable objects. This architecture follows the idea of Ryan Hipple, he is a principal engineer at Schell Games. He made a Unite Talk about the architecture they are using.

It’s quite genius, and I was inspired to make my own version. I used this for plenty of projects since then, and it was very convenient and quick to work with. I’ll publish it in the Unity Asset Store soon, but that’s a different story.

Since we were satisfied with the workflow in the prototype, I started to build up better this combination. The core principle of this is compartmentalization: separating the parts of the system to prevent malfunctions from spreading between or among them.

You might be thinking, this is the core principle of the object-oriented programming too. You are right, but since we are using component-based architecture, where a single component contains a small code, OOP wouldn’t be appropriate here in my terms. I like to call it Three Layers of Communication.

1st Layer: Prefab

Most of our prefab functions are made with simple components that utilize UnityEvents. Our rule of thumb is that we are only using UnityEvents within the prefabs. We have the Burning Crate prefab, where UnityEvent turns on the particle, the interest target for the AI, and the audio.

2nd Layer: Scene

Every communication between prefabs on the scene works with Game Command System from the 3D Game Kit. This a great system, it’s easy to see which game object calls whom, due to the gizmos.

Currently, it supports only one to one connection type. Where we needed many to one connection, we made child objects for the prefab each with a single Game Command Sender, and call each of them with a UnityEvent.

Important: we only allow this type of communication between game objects that are connected to the scene.

3rd Layer: Game or Global

We are using scriptable object events and listener components, similar to the ones that are presented in the video above. I use Game Communication and Global Communication as synonyms.

Understanding the difference between scene communication and global communication might be difficult sometimes. Our rule of thumb is this: global is when the result of the event should be the same regardless the scene is currently loaded, otherwise it’s scene communication.

Scene Communication Example: a trigger activates the burning crates. Both of them could be used differently in other scenes, so they are communicating on the scene layer instead of global.

Advanced dialogues

For narrative dialogues, we have multiple actors on this scene: the character, the guards and the obelisks. We want to show an avatar image and the name of the actor with the text.

The first question you could ask here: why wouldn’t we use the Dialogue System I made for the Asset Store? It’s hard to admit, but it lacks an important feature that required for this project.

We could use the Runemark Dialogue System for this project, and it would work fine. The asset is made with conversations in my mind, and not with a narrative. For every box of text, we should make a new dialogue graph, which is not an optimal workflow.

I’m working on an update of the Asset to support narratives much better, once it’s done, we will put that into Shadowdancer too. Until that time, we will use this solution, because it was faster to make.

In-Game Pause Menu

It would be useful for the test to have the possibility to restart the level or load the last checkpoint when the player is got stuck somewhere. Now we have a pause menu with these options!

That’s it for this week, hope you enjoyed this article. Next week we continue working on this project and getting closer to the Vertical Slice.

We’ll see you all next time!

Shadowdancer Devblog Week 5 – Playable Prototype II.

Last week we started to work on the playable prototype. We made the first two sections of our level and developed an AI sensory system. If you missed it, I recommend to check it out. I linked two articles from Travis Hoffstetter and from Tom Leonard. Travis is a game designer at EA, while Tom is the lead programmer of Thief: The Dark Project.

Let’s see what we got done this week.

Level Building

We finished the second half of the level: the mountain path which has platformer and the puzzle room.

Building a level means two tasks: placing down the visual elements (like environment meshes, particles, sounds) and implementing the gameplay. The second half needs programmer knowledge.

Fortunately, the 3D Game Kit has very well made component based gameplay toolset, which is easy to use, even for those who don’t know how to write code. After I explained to her the basics, Dotti was able to implement most of the gameplay elements without my active help.

She made all the pop-up dialogues, triggers, burning crates, collapsing rocks, and the puzzle room by herself. This really speeds up the development, because I could focus on other parts of the game which requires heavy coding.

Player Character

Jumping is too strong in the current form. This is clear since the last playtest. After some trial, I made two changes.

The player character has two stances, stealth and normal. The player can’t switch between them, this is handled automatically. In the first two sections of our prototype level, the stealth stance will be active, while on the other two the normal.

In stealth stance, the player can move slower and not able to jump. I use different animation in stealth and in the normal mode to distinguish these two state.

Once I did this, I tested the game, and immediately have the oooh moment. I forgot that the first parts of the level also need the player to go higher ground. This could be a failure for me, but it wasn’t.

We removed the deep connection between the player and the shadow when we decided how the stealth should work (check Week 3). Stealth mechanics work very well, so we need something in place of it to represent this connection.

In the time we wrote the concept document, I had an idea of shadow dash, but we cut it out from the concept document for some reason. Now it was the time to grab that feature and put it into the game. Well, at least make a prototype and convince Dotti about it. (spoiler: I succeed)

Shadow dash is the new ‘jump’ in stealth mode. She moves forward with high speed until she reaches her destination, or a wall blocks her way. The idea came from Witcher 3 by the way, I really love Ciri’s dash ability, and I’m sure I’m not alone with this.

I want to allow the player to use this ability only from a shadow, and rewarding her when she arrives into a shadowy area. To achieve this, I implemented the Shadow Form. I only allow shadow dash, when the player is in this form.

When the player stays in the shadow long enough, her skin and hair changes its color and enters the shadow form. If she steps out of the shadow, her connection to the shadows weakens, and her skin and hair return to the original color.

During the shadow dash, the player moves to the shadow plane, because of this the light don’t weaken her connection. That being said, she can continuously dash as long as she arrives at a shadowy place.

Welcome screen and the game end scene

Even if this is just a prototype, I couldn’t let the game floating in the space, I wanted to give it a frame. I made a simple main menu and an ending scene.

We were curious, how much time does it take to our testers to go through the level, so I made a simple stopper scriptable object, to measure the playtime. I needed 5 minutes to finish the game.

The Light Entity

Since Dotti couldn’t resist the calling of Blender too long, she made a new model, this time the third participant of the level: the Light Entity.

While writing a good story is way out of our scope, we think about the story, that will be told in some day. The game is about the invasion of an evil army (perhaps demons), the world’s civilization is terrorized by this army, and only angels could defeat them.

However, angels disappeared a long time ago. Legends told, the natives of these lands were the shadowlings: small humanoids who had a strong connection with the shadow plane. Angels being light-based creatures were natural enemies of them. The shadowlings managed to imprison all the angels into mystical seals. Nobody knows if this is true, or just a fairytale.

The player is a member of the shadowling race, she knows the history of her kind and the seal’s location. Understanding the danger of the evil army decides she will break all the seals and put an end to the invasion.

The story is just an idea that came up during the development, it might change over time, but right now it’s very inspiring to work based on this.

That’s it for this week, hope you enjoyed this article. Next week we close our prototype phase and start working on the Vertical Slice. 

We’ll see you all next time!

Shadowdancer Devblog Week 4 – Playable Prototype I.

Last week we started to work on our playable prototype, that will form a base for our final game. Games are all about what players do, so the most important step is to define the core game activity. This phase requires quick work, we don’t have time to make elaborate code or fine art at this point.

Let’s see what we got done this week.

Level Design

We want to make a level for the first prototype, that represents all the elements we’ll have in our game. We are sure the game involves stealth, platformer elements, and puzzles.

Stealth will be the main activity, but on its own, it will be monotonous and tiring. Remember, the game won’t involve any combat. We need activities to give the player a break.

Later we can combine these activities together, but right now we sliced the level into four different parts, each designed with one activity in mind. After minutes of staring at the white paper on the desk we realized something important:

We don’t know how to design a level for a stealth game!

We put away the damn white paper to find information about stealth level design. We found an article surprisingly quickly.  The Anatomy of a Stealth Encounter is a very detailed post on Gamasutra from Travis Hoffstetter (game designer at EA, previously at Crystal Dynamics, worked on The Rise of the Tomb Raider).

I won’t talk about the different types of encounters and the ways you can encourage players to hide. If you are interested, I really recommend you to read the article. It helped us a lot to design our levels.

After we had a clue about how, we grabbed the white paper once again, and start to draw the level layout. The first half of this level will be stealth-oriented: at the start, we use the Outpost encounter type from the article. The second part should use the Limited approach type.

According to the story, the player character wants to find a hidden temple, where she can break a seal that will end the invasion of the evil army.  In the first part, she will find the gate that leads to the hidden passage. In the next section, she has to steal the key from the captain to use this gate. The third part will be the passage, that is not used for ages. This will be the platformer part. In the last part, she will break the seal by solving a puzzle.

AI - Round 2: Sensors

Last weeks approach to make more clever AI with multiple states of awareness, resulted in an unnoticeable feature. During the gameplay, the behavior of the enemies wasn’t believable. Although my goal is not to make a totally realistic AI, I still want them to look like thinking creatures.

I made another investigation this week. How does the AI work in big games? Thief is one of the most popular stealth game in video game history. Fortunately, Gamasutra is one hell of a place where you can find anything!

Building an AI Sensory System: Examining The Design of Thief: The Dark Project is an article from Tom Leonard (lead programmer of Thief: The Dark Project). I won’t explain the article either, read it! Very exciting!

I said before, currently, we don’t have time to make complex codes. Perhaps I should listen to my own advice and wait for later phases of the development, to jump into this feature. Well, I didn’t. After reading it, and truly understanding it, I started to make my own sensory system. I knew this will consume most of my work hours for this week, and I was totally right.

I’m pretty happy with this system. I set up three sensors: direct vision, peripherical vision, and hearing. I have to tweak the parameters and make the AI able to understand this information better later in the development. Because in the current state, the enemy is too strong. They caught me three times out of five.

Smaller bits

Bushes: Since I used to try to hide in the bushes during my playtest and was disappointed when the enemy saw me there. I made the bush totally cover the character. Enemies can’t detect the player with visual sensors, but they still can hear her.

Dotti made the first version for the enemy. A large male, death-knight with armor:

That’s it for this week, hope you enjoyed this article. Next week we will continue building the level, and at the end of the week, we will have the first playable prototype. 

We’ll see you all next time!

Shadowdancer DevBlog Week 3 – Prototyping II.

Last week we made a bunch of prototypes to test our ideas. A great prototype is an attempt to answer a specific question. This week we processed the answers into the base of our game.

Project Management

Prototyping is a chaotic phase where you throw in ideas and make quick, and temporary solutions to see if it’s working or not. Managing the project in this state is very hard.

We didn’t exit this phase just yet, but we figured out we need to outline our weekly to-do to keep us on track. For this, we created a Trello table and cards for our tasks. We have to handle these task flexible enough, to give us guidance and freedom at the same time.

Why Trello?  We tried many different project management tools. We used Hack&Plan a lot during the creation of the Dark Fantasy Kit. However, we felt, it’s too heavy for this project, with all the features it provides. Trello, on the other hand, is a lightweight solution. I’ll talk about it more in the next weeks.

AI Improvement

One of the most important results of the last week prototypes was that this game requires more complex AI that the one you can find in the 3D Game Kit. This week I started to experiment with different solutions.

Generally, stealth games utilize three levels of Alertness. I call them Idle, Investigate and Attack. Using the chomper behavior as a base, I started to build up these states.

  • Idle: the enemy is staying still or walks on a patrol route. Last week I made a simple patrol script to set up waypoints.
  • Investigate: The enemy knows the player is here, but don’t know the exact position. He should go to the last point he detected the player, and start searching.
  • Attack: the player location is clear to the enemy, he can charge and attack her.

3D Game Kit has an exciting solution for AI state machine: they connected the AI states with the animator states. I really like this setup.

The result of this week: AI is still pretty bad and very easy to overcome. You can easily avoid attacks by simply running sideways, and the enemy lost sight and returns to the idle state when you run behind them.

However, I definitely made steps towards better understanding this problem. Next week I’ll work on sense and memory system.

Stealth

After iterations, I’m sure invisibility in shadow is a too strong ability. It also takes lots of effort from the AI side. I doubt I will have enough time to design and create an AI that can handle this.

I removed the invisibility and implemented a new stealth mechanic. When the player is in shadow, she is not entirely invisible, but the enemy should be much closer to detect her. I added a circle effect to represent this distance.

We think this is much better than invisibility. The shadow still gives protection, but only from distant enemies.

Circle effect for debuging detection distance

First level

We need a level that shows every main feature we want in this game. Sandbox level is not the way to go, we have to guide the player. We also want to represent the advantage of being a small and insignificant creature.

To achieve this, we’ll give the player different ways to pass by the enemy. We want to use the 3D space as much as possible, and make the player able to sneak below, above or behind the guards.

Not every enemy should patrol. This seems obvious, but I didn’t think about it until now. It’s very chaotic if every enemy is moving. The player isn’t able to observe them and makes it hard for her to identify the safe path.

Once we discussed these thoughts, we designed the level on paper, and Dotti started to build it in Unity, using our POLYEnvironment packages. She focused on shapes primarily, defining the color palette of this level will come later.

The lesson we learned: We greatly underestimated the amount of time the scene building needs. We thought it can be done in this week. We were wrong. We designed five sections, but only the first one is done today. Big mistake, but pre-production is about making mistakes without costing too much.

Modeling the protagonist

The first version of our hero is born at the end of the week. The colors are temporary.

That’s it for this week, hope you enjoyed this article. Next week we will continue building the level, and creating a better AI. 

We’ll see you all next week!

Shadowdancer DevBlog Week 2 – Prototyping

Last week we made the concept document and defined the scope of our game, the Shadowdancer. This week task was to prototype the key elements quickly.

We made two non-digital and several digital prototypes this week. You might ask if this will be a video game, why are we doing any non-digital prototype?

The non-digital prototype is very cheap and fast to make and still can provide necessary information about the element we are testing. Most of the real-time games can be represented in a turn-based system.

In this article, I’ll show you the prototypes we made and the results and answers we got from them.

1st Prototype (non-digital)

In this version, we wanted to simulate the game in a non-digital way. We used our terrains and miniatures for Dungeon & Dragons Tabletop RPG, and a desktop lamp to create shadow areas. We measured the time in rounds.

Question 1: When to become invisible and for how long?

We tested several ideas in house, by playing with this setup.  We used two different types of enemy: a seeker and a sniper. The result of this test was:

  • When the player instantly become invisible when he steps into the shadows, wasn’t much fun.
  • We need to add some constricts of how and when to become invisible.
  • The game strongly depends on the level design.

2nd Prototype (art)

With these concept drawings, we wanted to explore the core visual features of the main character and the enemies. We started with the main character.

What are the core visual features of the main character?

We had two keywords: female and sneaky.

After this prototype, we ended up with a female character who resembles a halfling: small as a human child, but with a grown-up woman look. She won’t need any weapons since the game doesn’t involve any fighting feature, but she will need pockets and pouches to store the valuables she collects.

She should be joyful and cute and moderately sexy to represent the halfling-ish style. We need to show the player her connection to the shadows, this will be done through her color changing tattoos.

What are the core visual features for the enemy characters?

We had a starting point after we created the player character concept: we want our enemies to be big and dangerous looking, but not too horrible.

Seeker type enemy (melee): similar to a death knight or armored Nazgul, with a large 4-bladed two-handed mace and distinctive helmet.

Sniper type enemy (ranged): a wraith-like spirit with spiked shoulder guards, burning eyes, and a ghostly bottom part.

3rd Bunch of small Prototypes (digital)

Now it was the time to start testing our ideas in the 3D space. I made several small prototypes to learn about the requirements and solutions. At this point, I worked quick and dirty.

  • Shadow Detection: This is the most essential feature of the game, so I started with this. Fortunately, I found an asset in the Asset Store very quickly.
  • 3D Game Kit setup: We decided to use the 3D Game Kit asset for giving a frame of this project. We used it in the past, and it was surprisingly quick to work with. Setting up the game kit contained to make the enemy and the player retargetable to make it easier for us to swap out the characters.

4th Prototype (Playable Prototype)

We use basic shapes, mostly cubes for the environment. For the characters, we downloaded the Xbot and Ybot from Mixamo. Character animations are from the 3D Game Kit and from Mixamo. For the enemies we use the Longsword Animset Pro from Kubold. We added background music and sound effects (enemy quotes) too.

We really don’t want to spend a lot of time on this part. The goal was to make something that resembles the game that we have in our minds. Later this will help us to keep on the same page.

We also wanted to answer several questions with this prototype.

  • Is the gameplay fun?
  • How difficult is the test level?
  • How do the invisibility mechanics feel?
  • How does the size difference feel between the main character and the enemies?

We gave this version to some of our friends and got a bunch of useful feedback.

  • The gameplay is fun, the goals are easy to understand, and the controls are OK.
  • The enemies are threatening because the protagonist can’t defend herself.
  • Jump is too powerful, we need to refactor this action.
  • The player can run off the enemies. This was intended, but we need more dangerous sniper enemies from which the player can’t run away.
  • The level should be more tunnel-like, to match our scope. The test level was sandbox-ish, it gave the player too many options.
  • The character models and enemy sounds made the players think this will be a sci-fi game. That is wrong, we have to get rid of this problem before the next playtest.
  • Improvement on AI. We need three states of alertness: no alert, alert and high alert. After spotting the player, they stay alert and search for a while.

The playtest also led to some extra questions:

  • How much control should the player have on the character movement modes? Run-walk toggling and invisible should be automatic, or controlled by the player?
  • How could the player use his creativity to reduce the time to wait for enemies to go away? For example, throwing stones to distract enemies.

That’s it for this week, hope you enjoyed this article. Next week we will focus on these feedbacks and questions. 

We’ll see you all next week!

5 genres and features you should avoid in your first game

As a first game, choose an idea that you can finish in a short time, within two months. During the development, you will learn a lot. If you want to learn the full process, you have to go through every aspect of the creation. In other words: you have to finish your game.

You might have big dreams, and you want to make the next big title. That’s totally ok. However, if you are serious about this dream, you give yourself time and opportunity to learn. Starting with a goal you actually can reach right now!

There are some genres and features you should avoid if you want to learn and improve, and ultimately finish your game. Some of these have technical difficulties, others are heavy in art resources. Let’s see which are these difficult genres and features.

Blender

5. 3D models that you make yourself

If you want to make and finish your first game within a few months, you really don’t have time to make all of your 3D models by yourself. This is absolutely true in case of realistic models. Even low-poly models can take half an hour or more to create. That’s a lot of time for this timescale.

Instead, you can browse through the Asset Store (or other sources) and find the model pack that you like. If you are making a stylized game, for example, take a look at our POLYEnvironment packages, it’s affordable and contains enough prefab to make a few levels with them.

Divinity Original Sin 2

4. Role-playing games

This game requires several skills to make. Each of them requires a massive amount of time. Because of this, it’s hard to finish within a few months.

First, you need a rule system that contains the rules for any or all of the followings: races, classes, stats, leveling progresses, monsters, abilities…etc. You have to plan it carefully.

Second, you will develop a story and dialogues. Ideally, you give multiple choices to the player. You might already see the complexity of this part, you need a strong storytelling skill and lots of time.

Third, you will actually develop the game, and if it’s your first game, you should focus on this part, but without the other two, you can’t make an RPG game.

Startcraft 2

3. Strategy Games (except tower defense)

Like in case of role-playing games strategy games are complex projects too. The design phase of this genre is quite time-consuming.  Even if you already have a good idea on paper, it might won’t work as a game, and you have to tweak a lot during the development to keep the balance and the fun.

2. Advanced AI

You can have AI in your games, but it should be dumb. Anything besides AI patrolling and using the navmesh would be overkill for your first game. Good AI takes weeks to make, and that’s a lot of time compared to the total 2 months timescale.

1. Network Multiplayer

The big scope buster. Today’s everyone wants to make a multiplayer game. Playing with friends together is very rewarding, and implementing features that allow your players to connect with each other doesn’t really seems to be a big deal. Well, it is.

As a freelancer, I worked on several networking projects. I also started an MMORPG server for fun (I didn’t finish it, and I’ll never do for sure). As a software engineer, I really like to think about the different features of multiplayer games. However, I know from my experiences how much effort it needs to develop.

Honorable Mentions

This was the five difficult genres and features you shouldn’t make as your first game, but there are others that you might want to avoid. These ‘honorable’ mentions are:

  • Procedural content
  • Isometric or 2.5d perspective view.
  • Virtual Reality
  • Adventure games (because of storytelling)
  • Puzzle games (because planning a puzzle)