Help me make a script for tutorials

Hello all

We’re packing and shipping alot of stuff this week, and I am mostly preoccupied with that.

Immediately after getting the packages out the door, I would like to make a bunch of short beginner programming tutorials: 1-2 pages in writing, <5 min in a Youtube video.

Now, since many of you have already got experience of working in Online mbed / offline tools / PokittoSim I would really appreciate ideas on topics & order of priority

This is what I imagine the topics could be:

Introductions series:

  1. What the Pokitto is, a short tour of the components on the circuit board and the features
  2. What alternatives you have for programming (online, offline, pokittosim), short tour
  3. Hello world in online mbed, tour of the UI
  4. Hello world in offline EmBitz, tour of the UI
  5. Hello world in PokittoSim, tour of the UI
  6. Starting a new project in online mbed
  7. Starting a new project in offline Embitz
  8. Starting a new project in PokittoSim
  9. Setting project preferences (screenmodes etc)

Understanding programming:
10. The program main function and game loop
11. Basic drawing functions (pixel, line, rectangle, bitmap, print)
12. Making your own bitmaps and importing them to Pokitto sourcecode
13. Getting input (Buttons)
14. Making & importing sounds
15. Load/save from the SD card
16. Using the I/O pins of the Pokitto PEX
17. How to use EEPROM to save game state

… anything else ?


Related to 11:" How to create and import bitmaps to your own Pokitto project?" We could even suggest some easy bitmap editor/animation tool if someone knows one. I am using Gimp but that is too complicated for an “entry” level usage.

Same case with sounds creating and importing.


Should we really be using eeprom to save? We’d have to be careful about overwriting other peoples data, as well as any settings from the loader that might be used in the future.
Would it not be safer to save to the sd card?

1 Like

EEPROM is 4kb of good nice accessible memory. Should we split that up to “savegame” slots, like on consoles?

We can for example make 4x1kB slots, with an ID in the beginning of each slot. If you want to overwrite, user will be asked for confirmation.

How about that?

Actually, maybe 8x512 would be better

I guess it wouldn’t make any difference if the loader could backup and restore the eeprom.

Select filename
Read previous filename from eeprom
Backup eeprom to previous filename.eep
Restore current filename.eep
Save current filename in eeprom
Load game


1 Like

Except it means your programs are always dependent on having an SD card. I like the simplicity of EEPROM.

So: 8 x 512 bytes, out of which first block reserved for system? Each block has 8 character ID as first 8 bytes.

1 Like

I would use even smaller blocks. For many games it is feasible to save player progress when closed. 8 or 7 games do not sound very much. And there might be different player profiles in each game. So at minimum: (player ID + player progress + player high score) * player count = (4 + 4 + 4 ) * 4 = 48 bytes (for 4 players and supposing the player ID contains only upper case chars). Plus the game ID, 8 bytes. So maybe 64 bytes per block? The game can always use more than one block if needed.

Then we need to have list of the allocated game ID’s in this forum to avoid duplicates.


Only if you try to load from SD card. That’s the only time it would attempt to backup.

1 Like

As someone who is not really a programmer, and casting myself to the time before I started to learn how to program, I have to share one thing:

I would not watch/read those tutorials.

I mean, right now I am super hyped for those, but when I was starting - no so much. Sure, they all cover essential building blocks of how to program, but it is just that. They have no end goal that a beginner can strive towards. I only got into programming because I followed a pretty good tutorial from PICO-8 zine that walked me trough making a breakout.

I think you should follow basically the same structure as you have now, but frame it in a game. Even a top down shooter where you have a guy walking and shooting bad guys will be much more interesting to follow than just simple “rules learning.” Even walking and avoiding enemies would be better, anything that has an end goal. This gives both, a reference on how to use those newly found skills, and a great sense of achivement!

With that in mind, this is how I would approach it (with some Berzerk clone for instance)

Lessons 1-9 would stay the same

    1. The program main function and game loop – pretty much the same, but thinking of establishing variables suitable for the game, thinking of IF functions for IF hit, die, etc.
    1. Basic drawing functions (pixel, line, rectangle, bitmap, print) – display a premade character on the screen, draw some level will rect, line and display score and lives with print
    1. Making your own bitmaps and importing them to Pokitto sourcecode – pretty much the same, but now making a Player, Enemies, Bullet? and explaining stuff like transparent colors
    1. Getting input (Buttons) – same, but now you can move your character! Explaining a simple walk animation (2-4frames) and how to play it when button is pressed.
    1. Making & importing sounds - same, but this time you get walk sound, shoot sound and death sound.
    1. By this point, have a playable game: Create a level with solid walls. Spawn enemies, give them super basic AI, make them killable.
    1. Load/save from the SD card - maybe level layouts, maybe some backgrounds?
    1. How to use EEPROM to save game state - pretty much stays the same, but now we actually save a game state!
    1. Using the I/O pins of the Pokitto PEX – no idea here
  • 19 Compile and push the game to your Pokitto!

There have been many different discussions on the Arduboy forums about the best way to share EEPROM among games, and they tried to set up a system of slots that would be shared, with different games having reserved a slot. However, I don’t think that games ever really ended up obeying any standard, and they seem to have gravitated to having more sophisticated loader programs that save and restore EEPROM over USB.

I personally feel that even if we do partition EEPROM into reserved slots, the loader should save and restore EEPROM on the SD card. I would even be willing to add the code to do this to the loader. The loader on the Ganebuino does this and it feels liberating being able to use the entire EEPROM (with the exception of common settings) without worrying about any other programs using it.

The updated version of Armageddon that now saves to EEPROM currently saves directly to the beginning just like it did on the Gamebuino, and I already have corruption of the highscores table data just from switching programs. We obviously will need some sort of consensus, but I think we might have an advantage over the Arduboy in that the creators didn’t endorse an official solution. For the Pokitto, perhaps @jonne can decide on what to officially support so that we don’t just endlessly debate different solutions.

Out of curiousity, is it theoretically possible for the Pokitto to expose the EEPROM as a separate file when connected as a flash drive (so when connected, there would be two files: firmware.bin and eeprom.sav)? If it’s possible, that would be an elegant way to be able to back up EEPROM without a SD card, although I don’t know how feasible that actually is.


I had 30 minutes to think about this, and I have made up my mind.

Developers should not have to care how the data gets stored, as long as it gets stored.

I propose (and I am open to discussion) a templated Pokitto::Userdata class, that would be used as follows:

Pokitto::Userdata highscore; //create instance

highscore.token = "HISC"; //register a user-defined ID for this value, 4 bytes; // permanently save (cached on EEPROM, duplicated on SD on game change)

game.display.print(highscore.value()); // returns value as integer type

EDIT: so what I am proposing is to turn the data fragments into objects that contain the methods of saving and retrieving them, making the EEPROM blocks /SD paraphernalia completely invisible.


1 Like

Thank you. That woke me up - and I agree with your sentiment.

1 Like

looks good to me, as i understand it the user would not see anything of this but would still know his/hers highscore. So simple = good

2 posts were split to a new topic: Saving user data on EEPROM & SD - development discussion

Despite having GIMP installed I actually just use paint to make most my sprites. It might be lacking some features lacking but I like the simplicity, it makes it easier to work with a restricted colour palette.

The only time I use GIMP for making sprites is if I really need layers.

Obviously though Mac and Linux won’t have paint though, so maybe would be a good alternative. I’ve never used it myself, but I’ve heard good things about it.
(It runs on .NET so Linux and OS X would need .NET installed.)

I half agree, but the sad truth about programming is that generally you need to understand an underlying concept before you can achieve cool game stuff. For example, if you’re writing something where the enemies need to be able to find a path to the player then you can’t avoid learning the details of a pathfinding algorithm (e.g. Dijkstra’s algorithm, A*).

Framing it in a game would definitely make it easier for beginners though. A bit of carrot to go with the stick.

The main goal of this tutorial would be learning the concepts, the game is just a framing device. I personally learn much better when I can “connect the dots”, instead of just mastering how to make a dot… I don’t think I am alone in that (I have seen enough posts online along the lines “I read X, Y & Z, how do I now use it to make it into a game?”)

The goal of those tutorials is NOT to make next pokitto hotness, or even a “good” game. We are just trying to make something, something that you can see your progress. Monsters don’t need A* to move, they can just walk left X spaces, then walk right X spaces… and if someone wants their monsters to use pathfinding, we should show them how to search for answers.

I know that many of you probably come from CS or professional programming backgrounds. You are all much MUCH better programmers than I will ever be and I welcome your advice, but with this experience, I think you are overlooking the need for noob-friendliness, accessibility and how to hook someone on programming. It is easy to learn the bare-bone basics when you have a class or work that forces you to do it. When it comes to learning in your spare time, you need a lot of carrots, and seeing progress being made is a great carrot. Trust me, I have been there recently…

@jonne - As someone who is actually struggling to make a game in C, and just scraping by in lua and Python, I am very passionate about both learning and teaching how to use the Pokitto. If I can help in any way, if you need some gfx or even a sounding board, I will be happy to help!


Thanks! Wanna make a 2D vector drawing that we can use for making a Pokitto Fritzing component?

Fritzing is a system by which you can make diagrams on how to wire electronic parts together.

What we need is a front image of Pokitto with the connector header shown above in a kind of “cubism” way (showing two sides at once). I can do the actual Fritzing part, just need the GFX for it.

This is because @Pharap is making some cool tutorials and we could show them using Fritzing.

EDIT: what we basically need is this in a 2D vector


Hehe, was just going to ask if Fritzing component is basically the GPIO port :smiley: So thanks for the edit.

I will be glad to make it, will work on it tonight!

Do you need the pin labels and the text on the left?

No it should be just a simple thing.

I will send you some 2D projections (top, front) to make your work a bit easier


Sorry this is going to be a long one. :P
(Skip to the end if you want.)

I’ve been on both ends of that sort of thing so I know what that can be like, but usually people aren’t just being mean for the sake of it, they’re being cruel to be kind.

Being able to program also means being able to ‘fend for yourself’ (i.e. to work things out for yourself) at some point, and it’s easy to fall into the habit of “if I get stuck I’ll just get someone else to work it out for me”. Some people (even professionals) make a living just copying and pasting code and begging for help on the internet until they can get a half-working frankenstein program running without fully understanding how it works. Many decent programmers try their best to discourage this by forcing people to work things out for themselves. It may or may not be the best way to go about it, but ultimately it’s usually well intentioned.

I agree that it’s difficult to reach the point where you know how to glue bits together, but even with proper tuition it takes a while to get to grips with. There are things that can be done to help, but it’s more than just knowing techniques for gluing code together, it also requires first-hand experience.

Perhaps I didn’t get my point across quite right.

What I mean is that beginners have a tendency to want to avoid complicated topics or rationalise that they can get on without them, but anything worth having comes at a price and in programming that price usually involves understanding a theoretical topic before being able to put it into practice.

Even ‘walk left X spaces, walk right X spaces’ has theory behind it (i.e. state machines). For simple stuff it’s easy enough to get away with not knowing it, but there comes a time when the hard topics have to be discussed.

In early tutorials it won’t need to be considered as much, but later tutorials will unavoidably hit the ‘theory’ stuff and it’s going to need some inventive tackling.

Actually, I’m not a professional at all, I’ve never had a job being a programmer and 5 years ago I didn’t know the difference between a gigabyte and a megabyte.

Well written tutorials are helpful and I admit there’s a lack of those out there, but it’s also important to be determined and to not back down just because something looks dull. Everything that makes games fun is backed by a shed load of stuffy, boring mathematics written in latin by pompous dead people.

I’m not saying you’re wrong, I’m just saying it’s a hard task and it’s going to need a lot of coordination.

Importantly it’s not just about educating people about programming, there’s an aspect trying to cultivate the traits that a programmer needs, like problem solving and determination.

In the past I’ve seen people argue that programmers are actually problem solvers and programming languages are just a way to express the solution to a problem and while I don’t think it’s quite that simple, there’s some truth in that sentiment.

1 Like