# What makes a combat system for fighting games?

## Recommended Posts

Posted (edited)

Hi there,

it's been a while since my last post. I was creating a bunch of games but there was always something missing. Something which makes the game (maybe unique)... After a few tries I decided to start a side project for a combat system which should be used for fighting games.

I did a lot of research and programming to finally get something that makes actually fun to play. Well... it is only a prototype and I do not want to share it (yet). Now I decided to share my ideas of the basics of a combat system for fighting games.

Don't get me wrong... This is only my way of doing stuff and I want as many feedback as possible and maybe it will help people with their games.

I will provide a few code snippets. It will be some sort of OOP pseudo code and may have typos.

# Content

1. Introduction

2. Ways of dealing damage

# 1. Introduction

What makes a combat system a combat system?

I guess it could be easy to explain. You need ways of dealing damage and ways of avoiding damage. At least you need something for the player to know how to beat the opponent or the game. As i mentioned before, I will focus on fighting games. As it has ever been there is some sort of health and different ways to reduce health. Most of the times you actually have possibilities to avoid getting damage.

I will focus on these points later on.

# 2. Ways of dealing damage

How do we deal damage by the way?

A common way to do so, is by pressing one or more buttons at one time in order to perform an attack. An attack is an animation with a few phases. In my opinion, an attack consists of at least four phases.

1. Perception

2. Action

3. Sustain

4. Release

Here is an example animation I made for showing all phases with four frames:

Every one of those has its own reason. One tipp for our designers out there is to have at least one image per phase. Now we should take a closer look at the phases itself.

## 2.1. Perception

The perception phase should include everything to the point, the damage is done. Lets say, it is some sort of preparing the actual attack.

Example: Before you would punch something, you would get in position before doing the actual action, right?

Important note: the longer the perception phase is, the more time the opponent has to prepare a counter or think about ways to avoid the attack. Like having light and heavy attacks. The heavy attacks mostly have longer perception phases than the light ones. This means, that the damage dealt is likely greater compared to the light attacks. You would like to avoid getting hit by the heavy ones, right?

## 2.2. Action

The action phase is the actual phase where damage is dealt. Depending on the attack type itself the phase will last longer or shorter. Using my previous example, heavy attacks might have a longer action phase than light attacks. In my opinion, the action phase should be as short as possible.

One great way to get the most out of the attack animation itself is by using smears. They are often used for showing motion. There's ton of reference material for that. I like using decent smears with a small tip at the starting point and a wide end point (where the damage should be dealt). This depends on the artist and the attack.

## 2.3. Sustain

At first sight, the sustain phase may be irrelevant. It is directly after the attack. My way of showing the sustain phase is by using the same image for the action phase just without any motion going on. The sustain phase should be some sort of a stun time. The images during the sustain phase should show no movement - kind of a rigid state.

Why is this phase so important?

It adds a nice feel to the attack animation. Additionally, if you want to include combos to your game, this is the phase, where the next attack should be chained. This means, while the character is in this phase of the attack, the player could press another attack button to do the next attack. The next attack will start at the perception phase.

## 2.4. Release

The release phase is the last phase of the attack. This phase is used to reset the animation to the usual stance (like idle stance).

## 2.5. Dealing damage

Dealing damage should be only possible during the action phase.

How do we know, if we land a hit? I like using hit-boxes and damage-boxes.

### 2.5.1. Hit-boxes

A hit box is an invisible box the character has. It shows it's vulnerable spot. By saying "Hit-box" we do not mean a box itself. It could be any shape (even multiple boxes together - like head, torso, arms, ...).

You should always know the coordinates of your hit-box(es).

Here is an example of a hit-box for my character:

I am using Game Maker Studio, which is automatically creating a collision box for every sprite. If you change the sprite from Idle to Move, you may have a different hit-box. Depending on how you deal with the collisions, you may want to have a static hit-box.

Hit-boxes could look something like this:

class HitBox {
/*
offsetX = the left position of you hit-box relative to the players x coordinate
offsetY = the top position of you hit-box relative to the players y coordinate
width = the width of the hit-box
height = the height of the hit-box
*/
int offsetX, offsetY, width, height;

/*
Having the players coordinates is important.
You will have to update to player coordinates every frame.
*/
int playerX, playerY;

//initialize the hit-box
HitBox(offsetX, offsetY, width, height) {
this.offsetX = offsetX;
this.offsetY = offsetY;
this.width = width;
this.height = height;
}

//Update (will be called every frame)
void update(playerX, playerY) {
//you can also update the player coordinates by using setter methods
this.playerX = playerX;
this.playerY = playerY;
}

//Getter and Setter
...

//Helper methods
int getLeft() {
return playerX + offsetX;
}
int getRight() {
return playerX + offsetX + width;
}
int getTop() {
return playerY + offsetY;
}
int getBottom() {
return playerY + offsetY + height;
}
}

When using multiple hit-boxes it would be a nice idea to have a list (or array) of boxes.

Now one great thing to implement is a collision function like this:

//check if a point is within the hit-box
boolean isColliding(x, y) {
return x > getLeft() && x < getRight() && y > getTop() && y < getBottom();
}

//check if a box is within the hit-box
boolean isColliding(left, right, top, bottom) {
return (right > getLeft() || left < getRight()) && (bottom > getTop() || top < getBottom());
}

### 2.5.2. Damage-boxes

Damage-boxes are, like hit-boxes, not necessarily a box. They could be any shape, even a single point. I use damage-boxes to know, where damage is done.

Here is an example of a damage-box:

The damage box does look exactly like the hit-box.

The hit-box differs a bit to the actual damage-box. A damage-box can have absolute x and y coordinates, because there is (most of the times) no need to update the position of the damage-box.

If there is a need to update the damage-box, you can do it through the setter methods.

class DamageBox {
/*
x = absolute x coordinate (if you do not want to update the coordinates of the damage-box)
y = absolute y coordinate (if you do not want to update the coordinates of the damage-box)
width = the width of the damage-box
height = the height of the damage-box
*/
int x, y, width, height;

/*
The damage the box will do after colliding
*/
int damage;

//initialize the damage-box
DamageBox(x, y, width, height, damage) {
this.x = x;
this.y = y;
this.width = width;
this.height = height;
this.damage = damage;
}

//Getter and Setter
...

//Helper methods
int getLeft() {
return x;
}
int getRight() {
return x + width;
}
int getTop() {
return y;
}
int getBottom() {
return y + height;
}
}

### 2.5.3. Check for collision

If damage-boxes and hit-boxes collide, we know, the enemy receives damage.

Here is one example of a hit:

Now we want to check, if the damage box collides with a hit-box.

Within the damage-box we can insert an update() method to check every frame for the collision.

void update() {
//get all actors you want to damage
actors = ...; //use a variable or have a global method (it is up to you, to get the actors)
//iterate through all actors
foreach(actor in actors) {
//lets assume, they only have one hit-box
hitBox = actor.getHitBox();
//check for collision
if(hitBox.isColliding(getLeft(), getRight(), getTop(), getBottom()) {
//do damage to actor
actor.life -= damage;
}
}
}

To get all actors, you could make a variable which holds every actor or you can use a method you can call everywhere which returns all actors. (Depends on how your game is set up and on the engine / language you use).

The damage box will be created as soon as the action phase starts. Of course you will have to destroy the damage-box after the action phase, to not endlessly deal damage.

## 2.6. Impacts

Now that we know, when to deal the damage, we should take a few considerations about how to show it. There are a few basic elements for us to use to make the impact feel like an impact.

### 2.6.1. Shake the screen

I guess, I am one of the biggest fans of shaking the screen. Every time there is some sort of impact (jumping, getting hit, missiles hit ground, ...) I use to shake the screen a little bit. In my opinion, this makes a difference to the gameplay. As usual, this may vary depending on the type of attack or even the type of game.

### 2.6.2. Stop the game

This may sound weird, but one great method for impacts is to stop the game for a few frames. The player doesn't actually know it because of the short time, but it makes a difference. Just give it a try.

### 2.6.3. Stun animation

Of course, if we got hit by a fist, we will not stand in our idle state, right? Stun animations are a great way to show the player, that we landed a hit.

There is only one problem. Lets say, the player is a small and fast guy. Our enemy is some sort of a big and heavy guy. Will the first punch itch our enemy? I guess not. But maybe the 10th one will.

I like to use some damage build up system. It describes, how many damage a character can get before getting stunned. The damage will build up by every time the character will get hit. After time, the built up damage reduces, which means, after a long time without getting hit, the built up shall be 0 again.

### 2.6.4. Effects

Most games use impact animations to show the player, that he actually hit the enemy. This could be blood, sparkles, whatever may look good. Most engines offer particle systems, which makes the implementation very easy. You could use sprites as well.

## 2.7. Conclusion

By using the four phases, you can create animations ideal for a fighting game. You can prepare to avoid getting hit, you do damage, you can chain attacks and you have a smooth transition to the usual stance.

Keep in mind, the character can get hit at phases 1, 3 and 4. This may lead to cancel the attack and go into a stun phase (which i will cover later).

A simple way to check for damage is by using hit-boxes and damage-boxes.

# 3. Ways of avoiding damage

Now we are able to deal damage. There is still something missing. Something that makes the game more interesting... Somehow we want to avoid taking damage, right?

There are endless ways of avoiding damage and I will now cover the most important ones.

## 3.1. Blocking

Blocking is one of the most used ways to avoid damage (at least partially). As the enemy starts to attack (perception phase) we know, which attack he is going to use. Now we should use some sort of block to reduce the damage taken.

Blocking depends on the direction the player is looking. Take a look at this example:

If the enemy does an attack from the right side, we should not get damage. On the other side, if the enemy hits the character in the back, we should get damage.

A simple way to check for damage is by comparing the x coordinates.

Now you should think about how long the character is able to block. Should he be able to block infinitely? You can add some sort of block damage build up - amount of damage within a specific time the character can block (like the damage build up). If the damage was to high, the character gets into a stunning phase or something like that.

## 3.2. Dodging

Every Dark Souls player should be familiar with the term dodging. Now what is dodging?

Dodging is some sort of mechanism to quickly get away from the current location in order to avoid a collision with the damage box (like rolling, teleportation, ...) Sometimes the character is also invulnerable while dodging. I also prefer making the character shortly invulnerable, especially when creating a 2D game, because of the limited moving directions.

## 3.3. Shields

Shields may be another good way to avoid taking damage. Just to make it clear. I do not mean a physical shield like Link has in the Legend of Zelda (this would be some sort of blocking). I mean some sort of shield you do have in shooters. Some may refill within a specific time, others may not. They could be always there or the player has to press a button to use them. This depends on your preferences. While a shield is active, the character should not get any damage.

Keep in mind. You do not want to make the character unbeatable. By using shields which are always active (maybe even with fast regeneration), high maximum damage build up / block damage build up you may end up with an almost invulnerable character.

## 3.4. Jump / duck

These alternatives are - in my opinion - a form of dodging. The difference between dodging and jumping / ducking is, that you do not move your position quickly. In case of ducking, you just set another hit-box (a smaller one of course). While during a jump, you are moving slowly (depends on your game).

The biggest difference in my opinion is, jumping or ducking should have no invulnerable frames.

I hope you enjoyed reading and maybe it is useful to you. Later on, I want to update the post more and more (maybe with your help).

If you have any questions or feedback for me, feel free to answer this topic.

Until next time,

Lukas

Edited by LukasIrzl

##### Share on other sites

This looks like it should maybe either be a blog post or an article.

##### Share on other sites

I thought about creating an article. Before doing so, I wanted to know your opinions and maybe put in a few of your suggestions.

##### Share on other sites
Posted (edited)

That sounds like a reasonable explanation of the collision and animation aspects, but you left out one very important point: fighting games are pretty much always built around a circular rock-paper-scissors aspect so that every attack has a counter and it is a mind game to anticipate what your opponent will do next.  The usual set is punch-block-throw (block stops a punch, throw ignores blocks, punch beats a throw), but you could presumably do other things, adding in more than three options, or having a different three actions.

David Sirlin (http://www.sirlin.net/) has a bunch of writing about the design of fighting game systems and balance.  You have probably seen his work, but if not, you should definitely check it out. Edit: He even implemented the punch-block-throw cycle as a turn-based card game called Yomi where both players select a move from their hands and lay it face down, then reveal them simultaneously.  It has combos, more and less powerful moves, the whole deal.  It's interesting to see that you can have the mind game without the reaction time parts.  IIRC you can try it for free with limited character choices both as printable PDF cards and in the online version.

Edit: Also (and this is minor) I think the tone of your piece could use a little work. It's not bad, but it feels a little amateurish with the vibe of "I experimented and thought things up and here are my ideas" when everything in it is pretty standard fighting-game mechanics. I couldn't find it in a quick search, but there's an article on the internet somewhere that covers almost exactly this same ground, using debug screenshots from one of the Street Fighter games (I think?) as examples. So some acknowledgement that you've done your homework and aren't just reinventing the wheel would make it feel more solid.

And the anticipation/windup frames add a delay between the button press and the actual action, so in games with network play it also serves the purpose of helping deal with network delay and reducing the chance that the game has to be like "Well...we showed you kicking him, but actually he punched you in the face three frames ago, we just didn't know it yet, so...sorry!".

Edited by JoshGrams
Added several more thoughts. Maybe should have been another post, but I'm assuming double-posting is bad?

##### Share on other sites

Thank you.

You are absolutely right. I did spend a little to few time for this aspect. In my opinion it is very important to think of counter attacks and assume what the opponent is going to do. The "mind game" as you called it. I will definitely spend a "chapter" on it.

Actually, I have never seen his work but I will check it out for sure. Maybe I will get ideas from him to implement and to write about.

Up to this point, I truly covered only the standard fighting-game mechanics and my thoughts about them. Later, I want to cover more aspects like gameplay, rock-paper-scissors aspect (which is in my opinion some sort of gameplay), and more which comes to my mind.

I will try to rework the tone of my piece.

In my opinion this thread should help me completing my combat system and help others with theirs. That's why I want to keep it as general as possible. (I hope it works ;))

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
627708
• Total Posts
2978730
• ### Similar Content

• Looking to design a learning game that teaches formal, critical thinking. The demographic would be those who have never taken a critical thinking course or a logic course. But I just don't know what to use to create it. I'm a novice in programming but have the motivation to put in the time to learn.
Starting the user out slow, focusing on argument form and the nature of arguments, how to identify the issue being discussed, identifying and evaluating value and descriptive assumptions, moving on to fallacies, types of evidence and their relative strengths/weaknesses, etc. Maybe adding sections on types of logic (syllogistic, propositional, predicate, modal.
More of a focus on text-based learning and interaction, but with images, animations, maybe video (I don't know).
Think of it as a modern and more interactive version of Logicola (it's ok if you don't know what that is).
So it isn't graphics heavy, definitely not 3D or even 2D platform sort of game. Maybe something similar to the JackBox games on Steam, but not entirely sure at this point.
Thoughts? What are some good possibilities to use for such a project? I'd like to be able to market it, perhaps on Steam, maybe even to education institutions.

• Over the past few years I have had a growing feeling that videogame storytelling is not what it could be. And the core issue is not in the writing, themes, characters or anything like that; instead, the main problem is with the overall delivery. There is always something that hinders me from truly feeling like I am playing a story. After pondering this on and off for quite some time I have come up with a list of five elements that I think are crucial to get the best kind of interactive narrative.
The following is my personal view on the subject, and is much more of a manifesto than an attempt at a rigorous scientific theory. That said, I do not think these are just some flimsy rules or the summary of a niche aesthetic. I truly believe that this is the best foundational framework to progress videogame storytelling and a summary of what most people would like out of an interactive narrative.
Also, it's important to note that all of the elements below are needed. Drop one and the narrative experience will suffer.
With that out of the way, here goes:
1) Focus on Storytelling
This is a really simple point: the game must be, from the ground up, designed to tell a story. It must not be a game about puzzles, stacking gems or shooting moving targets. The game can contain all of these features, but they cannot be the core focus of the experience. The reason for the game to exist must be the wish to immerse the player inside a narrative; no other feature must take precedence over this.
The reason for this is pretty self-evident. A game that intends to deliver the best possible storytelling must of course focus on this. Several of the problems outlined below directly stem from this element not being taken seriously enough.
A key aspect to this element is that the story must be somewhat tangible. It must contain characters and settings that can be identified with and there must be some sort of drama. The game's narrative cannot be extremely abstract, too simplistic or lack any interesting, story-related, happenings.
2) Most of the time is spent playing
Videogames are an interactive medium and therefore the bulk of the experience must involve some form of interaction. The core of the game should not be about reading or watching cutscenes, it should be about playing. This does not mean that there needs to be continual interaction; there is still room for downtime and it might even be crucial to not be playing constantly.
The above sounds pretty basic, almost a fundamental part of game design, but it is not that obvious. A common "wisdom" in game design is that choice is king, which Sid Meier's quote "a game is a series of interesting choices" neatly encapsulates. However, I do not think this holds true at all for interactive storytelling. If choices were all that mattered, choose your own adventure books should be the ultimate interaction fiction - they are not. Most celebrated and narrative-focused videogames do not even have any story-related choices at all (The Last of Us is a recent example). Given this, is interaction really that important?
It sure is, but not for making choices. My view is that the main point of interaction in storytelling is to create a sense of presence, the feeling of being inside the game's world. In order to achieve this, there needs to be a steady flow of active play. If the player remains inactive for longer periods, they will distance themselves from the experience. This is especially true during sections when players feel they ought to be in control. The game must always strive to maintain and strengthen the experience of "being there".
3) Interactions must make narrative sense
In order to claim that the player is immersed in a narrative, their actions must be somehow connected to the important happenings. The gameplay must not be of irrelevant, or even marginal, value to the story. There are two major reasons for this.
First, players must feel as though they are an active part of the story and not just an observer. If none of the important story moments include agency from the player, they become passive participants. If the gameplay is all about matching gems then it does not matter if players spend 99% of their time interacting; they are not part of any important happenings and their actions are thus irrelevant. Gameplay must be foundational to the narrative, not just a side activity while waiting for the next cutscene.
Second, players must be able to understand their role from their actions. If the player is supposed to be a detective, then this must be evident from the gameplay. A game that requires cutscenes or similar to explain the player's part has failed to tell its story properly.
4) No repetitive actions
The core engagement from many games come from mastering a system. The longer time players spend with the game, the better they become at it. In order for this process to work, the player's actions must be repeated over and over. But repetition is not something we want in a well-formed story. Instead, we want activities to only last as long as the pacing requires. The players are not playing to become good at some mechanics, they are playing to be part of an engrossing story. When an activity has played out its role, a game that wants to do proper storytelling must move on.
Another problem with repetition is that it breaks down the player's imagination. Other media rely on the audience's mind to fill out the blanks for a lot of the story's occurrences. Movies and novels are vague enough to support these kinds of personal interpretations. But if the same actions are repeated over and over, the room for imagination becomes a lot slimmer. Players lose much of the ability to fill gaps and instead get a mechanical view of the narrative.
This does not mean that the core mechanics must constantly change, it just means that there must be variation on how they are used. Both Limbo and Braid are great examples of this. The basic gameplay can be learned in a minute, but the games still provide constant variation throughout the experience.
5) No major progression blocks
In order to keep players inside a narrative, their focus must constantly be on the story happenings. This does not rule out challenges, but it needs to be made sure that an obstacle never consumes all focus. It must be remembered that the players are playing in order to experience a story. If they get stuck at some point, focus fades away from the story, and is instead put on simply progressing. In turn, this leads to the unraveling of the game's underlying mechanics and for players to try and optimize systems. Both of these are problems that can seriously degrade the narrative experience.
There are three common culprits for this: complex or obscure puzzles, mastery-demanding sections and maze-like environments. All of these are common in games and make it really easy for players to get stuck. Either by not being sure what to do next, or by not having the skills required to continue. Puzzles, mazes and skill-based challenges are not banned, but it is imperative to make sure that they do not hamper the experience. If some section is pulling players away from the story, it needs to go.
Games that do this
These five elements all sound pretty obvious. When writing the above I often felt I was pointing out things that were already widespread knowledge. But despite this, very few games incorporate all of the above. This is quite astonishing when you think about it. The elements by themselves are quite common, but the combination of all is incredibly rare.
The best case for games of pure storytelling seems to be visual novels. But these all fail at element 2; they simply are not very interactive in nature and the player is mostly just a reader. They often also fail at element 3 as they do not give the player much actions related to the story (most are simply played out in a passive manner).
Action games like Last of Us and Bioshock infinite all fail on elements 4 and 5 (repetition and progression blocks). For larger portions of the game they often do not meet the requirements of element 3 (story related actions) either. It is also frequently the case that much of the story content is delivered in long cutscenes, which means that some do not even manage to fulfill element 2 (that most of the game is played). RPGs do not fare much better as they often contain very repetitive elements. They often also have way too much downtime because of lengthy cutscenes and dialogue.
Games like Heavy Rain and The Walking Dead come close to feeling like an interactive narrative, but fall flat at element 2. These games are basically just films with interactions slapped on to them. While interaction plays an integral part in the experience it cannot be said to be a driving force. Also, apart from a few instances the gameplay is all about reacting, it does not have have the sort of deliberate planning that other games do. This removes a lot of the engagement that otherwise comes naturally from videogames.
So what games do fulfill all of these elements? As the requirements of each element are not super specific, fulfillment depends on how one chooses to evaluate. The one that I find that comes closest is Thirty Flights of Loving, but it is slightly problematic because the narrative is so strange and fragmentary. Still, it is by far the game that comes closest to incorporating all elements. Another close one is To The Moon, but it relies way too much on dialog and cutscenes to meet the requirements. Gone Home is also pretty close to fulfilling the elements. However, your actions have little relevance to the core narrative and much of the game is spent reading rather than playing.
Whether one chooses to see these games as fulfilling the requirements or not, I think they show the path forward. If we want to improve interactive storytelling, these are the sort of places to draw inspiration from. Also, I think it is quite telling that all of these games have gotten both critical and (as far as I know) commercial success. There is clearly a demand and appreciation for these sort of experiences.
Final Thoughts
It should be obvious, but I might as well say it: these elements say nothing of the quality of a game. One that meets none of the requirements can still be excellent, but it cannot claim to have fully playable, interactive storytelling as its main concern. Likewise, a game that fulfills all can still be crap. These elements just outline the foundation of a certain kind of experience. An experience that I think is almost non-existent in videogames today.
I hope that these five simple rules will be helpful for people to evaluate and structure their projects. The sort of videogames that can come out of this thinking is an open question as there is very little done so far. But the games that are close to having all these elements hint at a very wide range of experiences indeed. I have no doubts that this path will be very fruitful to explore.
Notes
Another important aspects of interaction that I left out is the ability to plan. I mention it a bit when discussing Walking Dead and Heavy Rain, but it is a worth digging into a little bit deeper. What we want from good gameplay interaction is not just that the player presses a lot of buttons. We want these actions to have some meaning for the future state of the game. When making an input players should be simulating in their minds how they see it turning out. Even if it just happens on a very short time span (eg "need to turn now to get a shot at the incoming asteroid") it makes all the difference as now the player has adapted the input in way that never happens in a purely reactionary game. The question of what is deemed repetitive is quite interesting to discuss. For instance, a game like Dear Esther only has the player walking or looking, which does not offer much variety. But since the scenery is constantly changing, few would call the game repetitive. Some games can also offer really complex and varied range of actions, but if the player is tasked to perform these constantly in similar situations, they quickly get repetitive. I think is fair to say that repetition is mostly an asset problem. Making a non-repetitive game using limited asset counts is probably not possible. This also means that a proper storytelling game is bound to be asset heavy. Here are some other games that I feel are close to fulfilling all elements: The Path, Journey, Everyday the Same Dream, Dinner Date, Imortall and Kentucky Route Zero. Whether they succeed or not is a bit up to interpretation, as all are a bit borderline. Still all of these are well worth one's attention. This also concludes the list of all games I can think of that have, or at least are close to having, all five of these elements. Links
http://frictionalgames.blogspot.se/2012/08/the-self-presence-and-storytelling.html Here is some more information on how repetition and challenge destroy the imaginative parts of games and make them seem more mechanical.
http://blog.ihobo.com/2013/08/the-interactivity-of-non-interactive-media.html This is a nice overview on how many storytelling games give the player no meaningful choices at all.
http://frictionalgames.blogspot.se/2013/07/thoughts-on-last-of-us.html The Last of Us is the big storytelling game of 2013. Here is a collection of thoughts on what can be learned from it.
http://en.wikipedia.org/wiki/Visual_novel Visual Novels are not to be confused with Interactive Fiction, which is another name for text adventure games.
Thirty Flights of Loving This game is played from start to finish and has a very interesting usages of scenes and cuts.
To The Moon This is basically an rpg but with all of the fighting taken out. It is interesting how much emotion that can be gotten from simple pixel graphics.
Gone Home This game is actually a bit similar to To The Moon in that it takes an established genre and cuts away anything not to do with telling a story. A narrative emerge by simply exploring an environment.

This article was originally published on the Frictional Games blog and is republished with kind permission from the original author Thomas Grip.
• By Tootooni
Good day dear people

I'm completely new here and very nervous to be honest. I started with 3D-Design at my traineeship and can slowly start with my ideas for a survival/rpg game in 3d But since I only used RPG Makers until now I wonder how is the best way to start with a game, and what I would need for that.

Have a wonderful day! ^.^)/)

Tootooni

• Some concept art of our UI for "Something Ate My Alien". This is what the aliens look like under their suits....
See more over here: http://www.somethingatemyalien.com/

• i there !

I'm starting a new original creation for Uko Creative ! It's a fantasy trailer inspired by the first volume of the sword of the truth (make on UE4) . I wanted to share my progress with you

Here the first picture of a castle scene. The castle is not finished !

Don't hesitate to tell me what you think of the picture

• 21
• 14
• 12
• 22
• 35