Creating your first game

Game Engine Game Engine Support and Discussion
1

Hi everyone,
I recently saw a post that asked the infamous “How do I create a ‘game’?” question that clutters this forum not infrequently. Something caught me, before I replied with the go-to answer that essentially demands the user to clarify their goals and start smaller. There is a reason that people ask this question so often, and perhaps we can give better advice.

There are different categories of beginner’s post that we see, some of which are outlined below:

  • I would like to copy an existing game. But better.
  • I would like to produce a (massive) multiplayer game, with a single man team.
  • Are there any tutorials on how to make a game?
  • I have an idea (four lines later) I need team members, please join.

Some of these examples are a little overstated, but they demonstrate some different attitudes that we see from new (and existing) forum members. A few points need to be clarified to give context to the stance of the members of this forum;

  • We are all here for mutual benefit. Otherwise, there is no reason, no necessity to be a member.
  • We are here on a voluntary basis. We are not obligated to help anyone, but we will nearly always, because of the aforementioned clause. (And because it benefits us in the long run).
  • The older members of this forum, whether they have shipped a game, finished a game, or even started a game, have quite a lot of authority in the realm of the anticipated success of a project. “They’ve seen it all”.

I am by no measure the best developer here, but I believe that I have been here for a substantial period of time, during which I have experienced many failures and successes, of myself and other teams.

So, this thread will be split into three different categories:

  • Where to start.
  • How to encourage people to work with you.
  • Points to consider

Where to start?
If you’ve never created a game before, then it helps to think about what a game is. Most people’s definition of a game is an interactive experience. This necessitates a few areas of game design and development already:

  • Facilitating an interaction
  • Communicating the result of an interaction.

These two aspects of development are intentionally vague. Games can be conceived with entirely different storylines, interactive interfaces and purposes. But these traits are still ever present.

It is important to remember that the above points are dependant upon the concept of the game. For most developers, that is the place to start. Some starting points for game concepts are:

  • What is the purpose of playing the game? What experience will the game bring to the player’s life that doesn’t already exist in one form or another. For FPS games, it is often the feeling of immense importance and dominance. This aspect of the game will help infer a genre.
  • In what way will the player interact with the game? Usually the interaction mechanics stem from the concept, but some games (such as Portal) are shaped around the interaction mechanics more so that the reverse.

When people start creating interactive experiences, it is not uncommon for them to become so ensnared by the interesting experience of creating a game, that they forget the most important person of all; the player. Underlying programming and technology is interesting for the developer, but only the consequences of its implementation will interest the player.

So, where do you start? Well, it is conventional to develop a storyline, with a subset of experiences you wish for the player to play through. As I have said, this is only convention. The most important aspect of designing a game is to have a single unique concept that you can build a base upon.

If you start with a unique storyline, then writing a detailed series of scenes, chapters or experiences will be important when you come to write the GDD. If you design an interesting weapon, or tool then defining a subset of possible interactions and results will be useful.

It is important to remember that this first step should be evident throughout the entirety of the game’s development cycle. If you decide for centralise the game around a tool’s mechanics, then the majority of the experiences should necessitate the use of such mechanics implicitly, rather than by blind obligation. At least, it should be the case that the player wants to use the interaction method that they have been given, rather than being forced into it.

Recreating an existing game concept is a challenge, technically, but it doesn’t offer much stimulation for the player, who will inevitably compare it to the original experience. It is very difficult to better a previous experience because you will either fail to meet the original design, or you will add a new experience which detracts from the original concept.

How to encourage people to work for you
Before we answer this question, there are a number of criteria you should meet, and ask yourself if you do!

  • Do you have a game design document?
  • Do you have a drive for quality?
  • Are you able to organise and commit time and resources?
  • Do you have realistic goals?

Writing a game design document is important, but not as great a challenge as one might expect.
Here are a number of useful links:

The purpose of a GDD is to denote everything that drives the game’s mechanics. It must outline the mechanics, the benefits and possible negatives of each mechanic. As well as this, taking the philosophy “If it’s not in the GDD, it’s not in the game” is a good way of setting the mood for writing. You don’t need to reference all the details in geometry for example, but enough that one could imagine the level is a good sign.

The GDD isn’t solely there to educate new team members. It provides you with a features set that you would like to realise by the end of the process, and it helps keep you on track when distractions, confusion and scale can get in the way of the process. It’s a reference for all development questions like “How tall should this doorway be?”, which really is a question of “Who built this doorway” and “Who uses this doorway?”.

Some additional comments
Asking the big question can be a challenge. Especially with no prior evidence. We all start there some day. I was lucky, and found good team members, but I wasn’t ready for the challenge of a First Person Shooter. No one actively challenged me on that basis for a long while. This was a mixed blessing. I learned from my own failures, and no time could be considered a waste. But equally, If I had known the scope, I could have perhaps produced my own smaller game or two along the way.

You need to tell us what you are looking for in your game. You need to tell us why you need others to help. You need to explain what they would be asked to do, what they will / will not receive in exchange for participation. You need to outline how long you expect the game to take, how you will organise meetings, how you will involve the perspectives of the team members.

So many people will write “Maybe, if I make money you guys can have some too”. That’s not a promise. You should start with “I intend to sell this game on N platforms” or “This will be a free download”, and mention the purpose of creating this game; “To realise a dream of mine” is very different from “To make many $$$”.

A good blog to follow is Extra Credits. They demonstrate a strong insight into the entire process, from concept to distribution.

Some say that a common issue with new developers is that they aim too high. I disagree with this. We all aim high, and it’s a good thing to do. I think instead we should say that they rush to the end, too quickly. Never loose sight of your goal, and play the long game. It’s important to realise that these things require lots of different skills, and the road is long. But at the end of it all, it is worth it.

For those who worry about protecting their source code, and the potential implications of the BlenderPlayer and GPL licensing: http://www.gamedev.net/page/resources/_/business/business-and-law/you-dont-need-to-hide-your-source-code-r3503

Be honest, and lastly, good luck

2

I LOVE this post! I hope it gets sticky-ed as it’s something I wish I had seen a few years ago. I can’t help but disagree with a few points however, designing a game around a story is generally a bad idea. It’s such a common method though so I understand why you talked about it, but especially as an indie developer you should design your game with mechanics in mind. Your mechanics should dictate your story, how that story plays out, and what that story will look and feel like to the player as they experience it. Games built around a story often have mechanics that create plot holes (like the phoenix downs in final fantasy), or have conflicts in what the player wants to do with the mechanics and what must happen because of a pre-dictated story. And while writing a GDD is necessary and will greatly improve your drive and goal setting, I completely disagree with the idea of “if it isn’t in the GDD it’s not in the game”. That’s like if Picasso couldn’t paint anything that wasn’t in his sketches, it doesn’t make sense and it’s way too constricting. Games are a medium of art, and like any other medium, they change and evolve as they are worked on. GDD’s are there to get your ideas on paper and to be able to set goals, not to dictate every single aspect of the game ahead of time. Great post, thank you for writing this!

3

I think the question has been over-engineered. Don’t get me wrong, it’s all understandable and agreeable but I think that when someone starts thinking about making a game for the first time, what he really wants is to know how to make a box move, how to display text… all the things that looks basic once you know them but are unfathomable when you know nothing.
It may start with a “hey, I want to make World Of Warcraft 3000” but that should be automatically translated in “hey, i like World Of Warcraft 3000 and I want to make some sort of thing that I don’t really know but I need this box to change color”.

4

The first game should be a simple retro clone; Pong, break-out, tetris, etc.

When you’re just starting out, such seemingly simple projects will require a lot of work, and a lot of time to complete, even with a game engine. However, if you push through, you will have a good foundation to make something a little more ambitious … like a retro clone with your own special twist.

Eventually (after a few years), you’ll have the full ability to create fairly innovative games, but you will never have the ability to deliver something that even approaches industry products, because that requires an industry of highly skilled individuals, working for many years, with a ~$20M backing budget.

That’s really the most important thing to understand: Even if you were John Carmack, you would not have the ability to produce a AAA game by yourself. Considering the resources required, that would be a virtually impossible undertaking for an individual.

So, even when you have the necessary skills, you really need to limit your scope, and focus on areas where you have a distinct advantage (gameplay innovation), while avoiding areas where you are clearly disadvantaged (all manner of “game technology” innovation). Building your own tools and systems is fine, and should be encouraged, but trying to compete with “cutting edge” industry output is effectively a waste of time (for individuals).

As for resources:

I’ve created fairly comprehensive video tutorials. Other people wrote documentation, along with providing very useful examples. In general, we can say that there is a veritable wealth of resources.

If you have the time, and the relevant circumstances required to absorb all this information, you really have no excuse; the limits are all self-imposed.

Getting a team:

In addition to having an interesting/realistic idea, you need to have a contributing skill-set. In example: Programmer looking for an artist, or artist looking for a programmer. Design is something that everyone contributes to, so that alone is not a valid role.

You need to have a concrete skill that will complement the skills of your team members, and contribute (directly) to the overall completion of the project.

The idea itself, no matter how amazing you think it is (or could be), means nothing without the ability to execute … Unless you have the money to pay others to execute in your stead, but there is a whole lot of people want to get into game development to “make money”, so in general, they don’t have money to spend, and that brings us to:

Motivation:

If you’re getting into gamedev for fame and fortune, you’re wasting your time, because financial motivation is not nearly strong enough to help one endure years of training required to build even simple interactive products, not to mention anything that would actually turn a profit in the open marketplace.

You need to really love the process of game development. The ultimate product should be a side-effect of an activity that you would actively enjoy, regardless of the outcome.

PS:

To echo some of what imapiratemon mentioned:

There’s too much focus on story, and it’s out of place in the game industry. Games are meant to be played - if you want to tell an interesting story, you should make a movie.

5

I disagree with your counter point. One has the choice to design around a mechanic, but it’s only a choice. A game is simply an interactive experience, and interaction is subjective to the whim of the developer. Look at the Stanley Parable. It breaks a few preconceptions of what a game is. I would argue that most successful games have followed the approach to design around a feature (set), most likely because it is explicit, self-contained and allows the developer to defer plot twists and developments into a later part of the development process. Your comment about “Phoenix Downs” (a game that I lack experience with) is valid, but I do not believe it is the fault of the development. Instead, it demonstrates that the developers did not consider the implications of such a feature from all perspectives (mentioned in the later part of this reply).

With regards to the GDD, I would like to clarify that I state “it is a good philosophy to embrace” (or words to that effect), however I believe that is the purpose of the GDD. Everything should have been considered - enough at least to warrant writing down what it entails. This said, I don’t mean to say that you cannot design freely, moreover your design should be explored and considered from many perspectives - you (the developer), the player and also the fiction of the world (if applicable).

A footnote; I may appear to be terse here, but I don’t intend for that to be the sentiment. Thank you for your reply (which demonstrates that you have read the post), and best of luck. I hope we disagree further!

Ah, this is actually in line with writing this post. I think I need to go a little further in my reasoning though. I did have a lovely blog that would bare relevance, but I cannot remember the link.

A lot of people start with “hey, I want to make World Of Warcraft 3000” and proceed to ask “How do I do this?”. And they sometimes will expect an answer. But in truth, they demonstrate a serious flawed approach to the game design process. Developing a game is fraught with set backs, bugs, and serious design questions. The act of learning how to design a game, how to program and how to think like a developer is simply learning to embrace a mindset where you take an endeavour, an aspiration, and break it down into logically approachable tasks. Creating the next World Of Warcraft is a big task, and the reason we can say this is that we recognise it would require an unfathomable amount of content, of interaction systems, of network logic, and a very, very big budget for server maintenance.

The final part of your post is demonstrative of a user who hasn’t broken down their aim into smaller pieces. To them, all games look the same in terms of the development process (idea + game_making_machine = game). I intend to shift the attitude towards the introspective.
Thank you for your comments pgi.

Goran,

I can’t dispute anything that you’ve written here, neither do I wish to include it in my post. I think it’s well written, and would be a useful co-resource, if you wouldn’t mind leaving it intact!

One sentiment that I particularly wish to stress is the necessity for self-investment. If you, the developer, is not invested in the process, from start to finish, that is going to reflect poorly in the end product. I don’t enjoy this because I consider the potential “fame and fortune”. It’s intellectually rewarding, which is enough for me.

Regards,
Angus.

6

One could argue that The Stanley Parable’s mechanic is choice making, and so the narration was designed around that mechanic. Of course I have no idea what their process was while creating The Stanley Parable, but the differences between the original and the remake make me feel as if they designed the games narrative around the mechanic of making choices instead of coming up with a story and then adding in fps controls. If they had had a preset story they wouldn’t have added anything to the remake. Now this isn’t to say that designing around a story ALWAYS fails, although I may have sounded like that at first, it just isn’t the best way to go about designing a game in my opinion. It leads to unhelpful constraints that will never be present if you design with the mechanic in mind initially. However there have been hundreds of games that have been designed with story in mind first that were awesome wonderful works of art, and with thought and planning this method can work perfectly fine.
EDIT: Oh and about how everything should be considered when making your GDD, in the projects I’ve worked on we’ve used very loose GDD’s and it’s led us to come up with ideas we NEVER could have dreamed of when initially writing the first GDD. These ideas might come from programming breaking, seeing a picture later on, having an experience we didn’t have before, etc. The GDD is a very powerful tool though, I don’t want to seem as if I don’t use it or it isn’t important, because it is and I do.

7

Your extra credits link is invalid (first post, bottom)

Very good post that I absolutely agree with.

EDIT: Oh and about how everything should be considered when making your GDD, in the projects I’ve worked on we’ve used very loose GDD’s and it’s led us to come up with ideas we NEVER could have dreamed of when initially writing the first GDD. These ideas might come from programming breaking, seeing a picture later on, having an experience we didn’t have before, etc. The GDD is a very powerful tool though, I don’t want to seem as if I don’t use it or it isn’t important, because it is and I do.

I’ve found that those sort of ideas tend to be of comedy value rather than of gameplay value.

8

That’s your experience, but mine has been rather different I guess. I’ve found that as you work on a game, as you prototype and rework the idea in your mind over and over, your thoughts about it tend to change. You can write whatever you want down, but the better idea might be different, and it might not come around until you’re halfway done with the game. I guess it also depends on what kind of game you’re making though.

9

Hello, I can agree with the overall but there is two things that I had already read in this thread and other where I can’t.

The first is begin by small project like a pong or other, of course I don’t talk about begin with a wow, but there plenty of other kind of game between, and begin with a project that you don’t care can be a waste of time, motivation and other.
If you’re really motivate and you have time I think you must go for it.

The second thing that I read too much is the no need for story because of game, I’m tired about that because a story can be play and can be great.
And please don’t tell me that if I want a story I go read a book or watch a movie, because my best experience about story was on games that even book or movie can’t reach, they can’t reach about how great the story was and they can’t reach the feeling of the interactivity, even when you can’t modify the story.

Well maybe I can’t say more about “creating you first game”, because I am still on my first project after five years and I don’t care if it need ten years or more again, because I am motivate.

10

@sbkodama story in games isn’t bad, in fact games can have even more compelling stories than movies or books because the player is personally involved. What’s bad is when the story is written first and creates conflicts with the game play. This happens quite often when using the approach of story first, game later, but story itself is one of the best things we can do with a game. Stories in games work a bit different than the story in a movie or a book though as the person experiencing the story has a direct impact on it. If you want to tell a compelling story with a game, you need to keep in mind what sort of effect the player will have on it, and that means you might have to let go of some of your control on the story and let the game play dictate what that story becomes.

11

Battle of the braniacs…COMMENCE! :slight_smile:

side note: I really don’t understand why you need a Game Design Document if it’s not there for education of new team members. Why not just use a forum post and update it with whatever you have, like lots of people already do?

12

GDD’s help to keep your team on track and to set goals. If you’ve ever worked on a painting or a big drawing of some kind, you know its best to draw a few sketches and base your final drawing around them so you have a good idea of what your piece will end up looking like. The same principles apply to games, it helps to have a “sketch” to know what you’re trying to accomplish. A GDD is just one way of doing this, you could use a forum post just fine, but you’d fill out a forum post with roughly the same material that you’d put in a GDD anyways.

13

That process is why you should write down a GDD, or otherwise keep track of what your idea for a game is, and how you want to implement it. If you don’t write it down or flesh it out in some way, all you have is a general idea of “I want a game that plays like x and looks like y”.

There’s nothing wrong with making a game and then changing your mind as to how mechanics work or are implemented, but you should still write down the idea for the game. You can change that idea after it’s been initially written down, but you can’t usually implement a constantly changing one in your head.

@dancreator - As imapiratemon pointed out, it’s a useful document for keeping track of your game progress, and keeping tabs on what you need to do, and how you need to do it. I have a GDD for Valchion that I pretty much just started. I wrote down the plot, items, gameplay explanation, etc. elsewhere, but just now got down to actually writing the sequence of the maps in the game down. It’s really, really helpful.

@agoose77 - Really well-written and informative write-up!

I think it’s worth mentioning that story is a major part of games, and should not be overlooked. However, I prefer some fun with my novel, so I think the developer should focus on making a fun game, but also implementing a good story if the game calls for it and if they wish to. There’s no reason why games can’t have stories - they can. They don’t have to, but they can.

14

Yes, but they need to build on solid gameplay.

If not, it’s just one long quicktime event, or an equally dull stroll through a series of very boring actions, performed to see the next cutscene.

In many such cases, a movie would be a better format for everyone involved … But, this is clearly a subjective thing, and that’s just my opinion.

15

Oh, I agree with you wholeheartedly. I was just saying that games can have and tell beautifully crafted stories, but they should be games first and foremost. Nobody likes a long string of quicktime events.

16

What about Telltales The Walking Dead? Sure it had some parts of gameplay but the majority of the game was quicktime events and dialog options, yet it won game of the year. Im interested to know your opinion on that. :slight_smile:

Edit:
Btw, great post agoose, I hope it gets stickied :smiley:

17

Like the Stanley Parable, the Walking Dead’s mechanic was making choices. The narrative was based around interesting choices the player could make in the given world. Honestly the worst parts of the game were the quicktime events and adventure game puzzles, the interesting parts that made it game of the year were the choices you had to make and the influence you had on the story. If you notice as the series progressed there were less and less quicktime events and less adventure game puzzles, because those weren’t the strong points of the game.

18

I’m just going to bump this(I hope this is ok), as I think is a great post that pretty much all newbies should read :slight_smile:

19

I disagree. It’s a nice reading but it will make new-to-game-making people think that making game is an absurdely complicated thing while, as any human endeavor, it is as complicated as the game you want to make.

20

The latter part of your post is indeed what we focus upon. In the same likening, why write a post that details how to create art badly? It is something anyone can do. Likewise, to create a bad game is not difficult. Add a sphere, give it some awkward controls and share with the world.

A game is not like any other human endeavour. A game is a compilation of art forms, whose interaction with one another changes the entire feeling of the game.

Essentially, you are many people at once, which means a bad game represents the inaction or misguidance of not one but many people.

This is the point. Making a game is hard. And the difficulty Is proportional to the square of the scale (in my opinion)

Sent from my Nexus 5 using Tapatalk