Tutorial Quick tutorial on 'How to make a game when you know nothing about it at all...'

[toolkitxx]

As i have seen many many threads and postings over the last years, asking basically the same question with just a minor difference amongst them, I figured it might be high time to provide a simple and quick guide to what this requires.

This is by no means a tutorial on a specific tool or engine - this is an overall arching quick guide to get you into the process and the right mindset.


Lets begin with the assumption that you know nothing about coding or art creation. But you think you have a great idea about what you would like to create. This is a typical dilemma as it is easy to spit out ideas but actual hard work to make it a real thing.

• Step 1: Write down your overall idea.
  
  
• Step 2: Think of a game you recently played that is similar to your idea.
  
  
• Step 3: Pick a single scene if it is a VN or 1 basic feature if its a full blown game
  
  
• Step 4: Make yourself familiar with the concept of
  You must be registered to see the links
  . Pseudo code is basically a blend of natural language and the way code is written down and most importantly it is not tied into any specific programming language. Drawings are also a good tool for a simple approach to describe what happens in terms of functionality. Watch the video below the article and you will notice how that developer creates a simple drawing of a mathematical function to understand what to do code wise.
  
  
• Step 5: Write down in pseudo code what happens in the picked scene or game feature. It is important to make this as thorough as possible. If there are several buttons that can be pressed you need to address each of them. You need to write every single action that can happen including the ones a user might try to do but they are not supposed to. Also things that obviously seem to happen without the users interaction need to be addressed here.
  Example: a button says 'proceed' and is clickable. You need to write down the button itself in terms of graphics, that it is clickable and that it does something specific - in this case further the story or move to another location etc.
  
  
• Step 6: Check the logic of that pseudo code now. Try to play those steps in your head first and think of ways this can go wrong. If you find inconsistent pieces - expand your pseudo code. During my time as a coder i actually created a simple set of cards at some time that i still use today for standard stuff to quickly rearrange and test things out logic wise.
  
  
• Step 7: Identify and define every single graphical element. What does this mean? Even if you just see 1 picture it usually is comprised of several elements when we are dealing with a game. There are backgrounds, parts of the User Interface and so on. The User Interface usually has static and dynamic parts. The dynamic parts are stuff like buttons the user can click or dynamic meters that fill up, the static parts are things like values showing health or money in words or numbers. Write every single part down you can identify and also define if it is static or dynamic.
  
  
• Well - done. If you havnt given up yet you are ready to make your next step. All that gibberish in pseudo code and from the list of things you wrote down for the graphical elements now need to be transferred into something that a computer can understand. This means you need to decide for some tool now. The best tool for YOU is the one that is easiest to support the transition of making pseudo code into real code and a graphical tool that supports all the things you identified earlier.
  
  
• Step 8: Take any tool you find that appeals to you and that seems to do the job. Start with the graphical parts. Figure out how to make static elements first and then ascend to the dynamic parts once you are done. Dynamic parts like meters are a lot more challenging compared to static parts which is why you should follow this order.
  Important to note here is: Choose a tool and/or language that appeals to YOU. Dont choose by other peoples recommendation or popularity. At this stage it does not matter what tools you use!
  You must be registered to see the links
  
  
  
• Step 9: Do the same for the code now. Find a language or an engine that seems to appeal to you or seems to be simple enough to let you recreate that 1 single scene or 1 single feature from the game you already played. No need to create high def graphics for this or to have perfect code. Simply try to get something in the end that seems to function. My actual advice here is to not create any fancy stuff at all. This is something people call a prototype in game development - thus you should not spend a lot of time on details but try to get the overall thing to function somehow.
  
  
• Step 10: Latest now you have probably experienced either a full blown wave of frustration or at least a whole load of things that dont seem to work as you thought they would. Excellent! Now we iterate. Identify the areas where things fail. One at a time. Check the logic of it, correct obvious mistakes and rerun. Still problems? Reiterate. Repeat this step over and over until things work.
  If you cant get it to work by yourself: Ask questions in forums for that particular tool you have chosen or in forums like here and state properly what you are trying to achieve and what tools you use.
  
  
• Step 11: Everything is working now in your prototype. It probably looks like shit on the graphics side and your code is most probably the ugliest thing the world has ever seen. Great! This is where you reiterate again. Now you concentrate on one thing at a time again. Enhance your graphics piece by piece. recheck your code and identify areas where you can either reduce the amount of code or where you can structure it better. Especially for code it is important to imagine yourself picking up that code after 5 years again. Would you yourself still understand what a particular part of the code is supposed to do? If you can answer that positively - keep it as is. If you have any doubts rewrite and comment it. Remember - we are still only working on 1 single scene or game feature. Nothing more.
  
  
• Step 12: You finally made it and finish the prototype. It looks polished and readable. At least for your abilities. By now you have probably identified areas where the tools you have chosen are less ideal for what you tried to accomplish. Now you recheck for other tools and repeat this entire process until you have found the tools that let you implement this part fast and easy. You created the right mindset how to develop a game and can now go back to your original idea. Since you learned in your prototyping what and how much work that entailed you might want to redefine the scope of your original idea to something smaller or less complex for the next iteration. Rinse and repeat basically from Step 1.

Conclusion: As you can see from the list developing a game is much more about connecting small pieces than what tool to use. Your first game should basically be only a prototype or maybe even a copy of something that already exists but has been made from scratch by yourself again. No copy/paste. No taking complete libraries that already exist. By remaking it you will naturally have a goal you can compare your own work with. Compare only the user side at first. Does it play as the original? Does it look like it too? Once you managed to recreate someone else's work you will also have developed your own style and work process. At this time you can actually create something of your own with your own preference of tools and abilities.

 

[01234]

First of all, thank you for taking your time to share your knowledge for the sole purpose of giving a bit of guidance to (wannabe?) newcommers. It is very much appreciated.
Second, I do have a question. In your opinion, how important is it, to start of by imitating an existing/part of an existing game instead of doing something "from scratch"?
If someone already has an idea for a scene, would you still advice on first creating a "copy" of something existing to get a better feel of the whole process, or to dive into the own (and perhaps) original idea, to not lose enthusiasm/momentum?

 

[toolkitxx]

First of all, thank you for taking your time to share your knowledge for the sole purpose of giving a bit of guidance to (wannabe?) newcommers. It is very much appreciated.
Second, I do have a question. In your opinion, how important is it, to start of by imitating an existing/part of an existing game instead of doing something "from scratch"?
If someone already has an idea for a scene, would you still advice on first creating a "copy" of something existing to get a better feel of the whole process, or to dive into the own (and perhaps) original idea, to not lose enthusiasm/momentum?

Thank you and about your question: It is very important indeed and the main reason i wrote this little guide. Ideas are pretty much the easiest part in game development but most often those ideas either get bottled due to lack of knowledge how to get them implemented or they never see the actual implementation due to being all too complex to ever become reality.

Using the copy-method gives you something to measure against which is one of the more important things you will need as a beginner. It allows for constant milestone checking due to being based on something that already existed beforehand and has a defined way of look and functionality. This will help in getting from start to end as it doesnt allow for straying too much. This particular experience is what often lacks when people have their own ideas and try to implement them as they have no way of identifying times or difficulty of their own idea yet. It will also allow you to identify your strengths and weaknesses much better thus giving you a pretty decent outlook if you can manage this all by yourself or if you might be better of teaming up/outsource parts of it/reduce complexity etc.

 

[Night Hacker]

Nice little guide. The first game I ever made was basically a copy of another one, except I was making it for a different platform (an Amiga game ported to PC with my own touches). As the years passed I found planning ahead of time is more than half the process. If you do the planning part right, the game just falls into place. I actually greatly reduced the errors in my code and many years later, when I totally redone a new version of the game from scratch, the first code I wrote for it had literally no errors in it due to a lot of planning ahead of time.

One thing I have always done was I heavily comment my code. There is no doubt what my code done. This helps in the future, which does happen (with me, literally decades later).

When creating a RenPY visual novel (just started not long ago), I wrote out the game code before any images were rendered. In place of images I have text that appears centered on screen with a brief description of what you will see in the scene. This allows me to test it out, tweak it and get an idea of what I want before the lengthy task of creating and rendering the scenes.

I use the following code in a "developer.rpy" file which will display the filename and line number being executed on screen so if I see a problem, I know exactly where to go...

# Show filename and line number of current code being executed
# in upper left corner.

screen bugTesting_Overlay():
    $ fileLine = renpy.get_filename_line()
    text "[fileLine[0]]:[fileLine[1]]" xpos 10 color "#0f0"

In "script.rpy" I add the following line right after start:

    if config.developer:
        show screen bugTesting_Overlay

And then somewhere in code, you can set "config.developer=True" or "False". If it is True, you'll see it in the upper left corner. VERY handy while developing.

I have done similar things when coding in C, with printf() commands that explain in the console what is going on. You never see that text in the game window and the console is only visible in debug mode, which I would have on a separate monitor these days while it runs.

 

[Fanboy-10]

Thank you for posting this.

 

[plasticcactuses]

I appreciate taking the time to guide us newbies.