Game making tutorial request

Hi, if been fooling around trying to make a simple game for Pokkito. But i have some trouble piecing it al together.
I have some experience in programming in vb 6, but i have very litle knowledge about C++.

Thing is, if i would like to make a game for pokitto i have barely no examples. It would really help if some of the more excperienced programmers could make a simple game to show the basics.

things i ran into :

  • start program, show titlescreen and press A to start. How is this setup ? within the Main ?
  • pacing parts, like a bullet. I made a topic about setting a pace and i did get help(thanks @Pharap) but did not manage to make it work. shouldnt Pokitto already have a timer /pacer function ? since it is intended as a game device (mostly)
  • Drawing bitmaps on screen, i made a program that displayed 2 bitmaps (background and player)but i always could only see 1 (background). well, apperntly i should draw the background first en then the player on top of that. i did not know that, so it took me about an hour before i got that figured out.
  • where do i place the buttons to be read out correctly ? and why are there 2 types of ways to read the buttons ? (found different ways in other games)

I really apriciate the tutorial that are made so far, but it would be nice to have a simple example game. It should show how to setup the routines for checking/moving/etc. and alot of comments to explain what is going on.

Would it be possible to make and show a simple game as example ? I already looked at the games already availble but they are all different.


Good questions. We will get back to this, I promise


I understand where you are coming from and I have no doubt the these sort of tutorials are being thought about by some of the more experienced coders here, not just those who will want them to learn from.
I imagine you (and others) will be looking fro something along these lines - - which, although is very little help for Pokitto, I would think is the sort of thing we need to create.


One of the difficulties with creating tutorials for beginners is that the easiest way isn’t always the best way.

For example with your example of showing the titlescreen and pressing A to start,
the easiest way is to use a switch+enum class state machine, it works but that has several flaws:

  • it gets hard to maintain if you need lots of states
  • it’s not very reusable so you’ll find yourself writing a lot of the same boilerplate every time you make a new game

An alternative approach involving having an abstract GameState class is more flexible because you can just write a new class every time you need a new state. However it has problems of its own, like requiring dynamic allocation and potentially being ‘overkill’ if only a few states are needed.

In regards to the ‘timer/pacer’ thing, that’s actually not the best solution to the problem of making a bullet move.
In real life bullets don’t move a large amount every few seconds, they continuously move a small amount.
In games that’s usually achieved by giving the bullet a position, a velocity vector and using delta timing to make it move gradually.

As for the Pokitto library not having a timer, it’s a bit difficult because there’s no ‘one size fits all’ solution.

The drawing bitmaps over top of each other thing would be true for any system, that’s just how bitmaps work.

Those are the sorts of questions you should ask the forum though. Even if we don’t have many tutorials yet,
if we have people asking quesitons and the questions getting answers,
then the answers become a resource in themselves.
StackOverflow is founded on that principle.

There’s a good reason for that.

When programming there’s always more than one valid solution.
Every approach has its good points and its bad points.
If there was always a right answer there wouldn’t be so much debate or research involved in finding better solutions.

Also the better answers are often involve more advanced language features and thus require a better understanding of the langauge, or at least require more reading to understand the concepts involved.

People often settle for suboptimal solutions because they either don’t know better or don’t have the time or patience to learn the language features or concepts they’d need to know to understand the better answer.

This is one of the reasons I’m always telling people to please make their games open source and to include the source code along with the binary release.

One of the reasons the Arduboy has done so well is because (apart from one or two exceptions),
the majority of games are open source and their source code is freely viewable on github so its easy to pick apart how the games work.

I’d like to contribute some tutorials when I have time to, but as I’ve mentioned several times lately I still have a lot of stuff to get through before I’m ‘free’ again.

At the moment I’m trying to work on a vita homebrew project as well as spending a lot of time helping out on both the Pokitto and the Arduboy forums (I find it nearly impossible to not offer to help if I know I can help or contribute something useful, and I spend a long time typing long answers).
On top of which I recently had two issues raised on my fixed points library within a few days of each other, so I’ve had to handle those as well.


When learning something i believe the easiest way is the best way(mostly), you have to start somewhere.
Best example of this is the Hello World program, it just shows 1 thing how to output 1 line nothing more.

I agree that there are best ways to do stuff, like classes and states.But this should be covered in the following tutorials.

e.g. make a space invaders game, that only shows 1 enemy and the player. Make these move. end of lesson.
Next lesson add a startscreen, then fire a button, make it hit target, add a scorecounter. Add gamestates, classes etc.

This may not be the best way too write code, but it helps explaining the program. Once you had all the tutorials, you can start coding as it should be since the last tutorial explaines how and why a certian pattern or structure is most used/convenient. The first lessons should only cover the basics and not include all the complex best sulotions.

1 Like

That possibly wasn’t a very good example to illustrate what I mean.
There’s other cases where there are two possible solutions, one is a good way and one is a bad way and the bad way is easier to learn but people won’t always stick around for the full explanation.

One example of this (though this might not mean much to you) is with enum class vs #define.
Using enum class to create a name-value association is better than using #define,
but #define is easier to understand and takes less explaining so often people will learn/teach #define and then never bother to learn about enum class simply because it’s a bit more effort or they fall into the trap of “I’ve been doing it this way for a long time now and haven’t had any problems, so I don’t need a ‘better’ way”.

Also, it’s sometimes hard for experienced programmers to write tutorials for beginners for various reasons.

For one thing, so much of the basic stuff is second nature to experienced programmers that it’s easy to forget to explain something.
Secondly it can be hard for a programmer to teach people a method that they know is inefficient because it goes against instinct.
Saying “show someone how to do X without classes” is actually quite difficult when the instinctive answer is “use this class and that class”.

Also writing tutorials on how to make even a simple game can be quite complicated.
Even something as seemingly simple as noughts and crosses or space invaders requires covering variables, types, arithmetic, arrays (possibly 2D arrays), for loops, calling functions et cetera.

Normally a tutorial explaining the language would teach each of those individually and give lots of examples explaining the nuances of how they work.
Teaching them in the order they’re required by the game can often feel unnatural or actually make them seem more complicated.
For example you need to understand loops to be able to loop through an array,
but when writing a game usually the first time you’ll need a for loop is when you need to loop through an array,
so the tutorial would end up having to teach two complicated topics at the same time.
On top of that, there’s a chance that the only for loops required will be for looping through an array,
so the tutorial has no excuse for explaining the other uses of for loops and someone could come away not realising some of the other uses.

I’m not saying we shouldn’t have tutorials, I’m just saying that writing good tutorials is hard,
and that I think no amount of ‘how to make game X’ tutorials can act as a substitute for tutorials about the C++ language itself - they might be a good supplement, but they’re not a good substitute.

1 Like


24 examples, 23 of which are open source games:

Nevertheless, I understand what you are saying. We will make tutorials


Thank you, i do hope it doenst look like complaining to much. :smile:

The majority of those on the mbed page i already checked out, and i did actualy learn stuff from them.

I am just missing a coherent line in them since most were written by different coders. Not all have clear comments so i dont always get what is going on. And theres stuff that wasnt even intended for Pokitto but for the arduboy.

So indeed a tutorial would be great :blush: I hope your todo list doesnt get to long. :wink:

1 Like

How about a slightly different approach?
Start by putting together a post outlining what you want to make, eg, basic platform game. Start with hello world and keep a record of what your figuring out. Ask on the forum when you need specific help, those of us who can help usually will. Keep the blog going as you learn more and it can act as a tutorial for the next people…


Not a bad idea… :thinking:

Truthfully I think learning on the job is better than following a tutorial to create a specific game.

Following a tutorial for a specific game is a good starting point for the sake of learning the API, but games vary so much that I find it’s usually it’s just better to start experimenting and to ask for help when you get stuck.

(Plus I could do with some questions to answer. The lack of code-related questions on this forum disturbs me.)

Not saying we don’t need a tutorial at all,
but jumping straight in, floundering around and then asking for help is a perfectly acceptable strategy too.
(And there’s no risk of drowning. I think.)