Pokitto is on the way, what games should I make?


he’s a witch.


Hmmm you’re definitely pretty close, it’s not ridiculous, but still casting spells with hands doesn’t have the right feel, and I suspect it’s because guns indicate the target very nicely by pointing at it, have recoil and very clear, sharp shooting sound. I think these are the reasons guns prevail so much in FPS games. An idea emerges of a “magic gun”, but that already seems forced again.

But maybe (cross)bows vs dragons and such? That’s doable I guess.


…worked for Heretic? :sparkles: :smile:


Indeed, they kind of went for the “magic guns” and it seems to be working:

Not sure how kid friendly it is, but still better than guns I guess :smile: You guys have convinced me it can work to a good enough degree.

Hexen should probably be mentioned as well.


Indicate the target with a magic-symbol themed reticle.
It could be a rune, or perhaps a magic circle.


You can also use wands and staves instead of hands.

Magic tends to have a shooting sound as well,
just a different one to guns.
Just look at Skyrim, or the Harry Potter games.
(Especially the old GBA ones that didn’t have the sound quality for voice acting.)

You clearly haven’t been watching enough anime.
Magic guns firing blasts of energy are relatively common in anime and manga.

In fact, by searching ‘anime magic guns’, I found an image that precisely demonstrates both a magical gun and my magic circle reticle idea:

Sure, if you really want to go for something gun-like.

Bows with magic arrows are relatively common too.
Heck, ‘energy bow’ has its own TVTropes page (warning: TVTropes page, try not to get lost).



The aiming cross isn’t a problem, what I meant is that with a gun you can see it physically aiming at the target and that for me makes it more satisfying somehow – maybe it’s the sense of control, can’t really tell exactly why, but with bare hands you have this feel that the spell can go in any direction. Imagine an FPS where you have the aiming cross but don’t see a weapon at all – that somehow feels less satisfying to shoot. But the crossbow solves it as it has a nice pointy arrow. Or a pointy staff or whatever.

I like the energy crossbow very much. You could even make it just stun the victim instead of killing it, or it could “evaporate” the enemy, which is not as bad as letting them die from shots I guess. Depends how far you’d like to go with the kid friendliness. It also reminded me of the lightning gun from Quake, but that one works a little different.


These TV tropes look like movie design patterns.


The spell would go where the palm is aiming, like it does in Skyrim.

That’s what monsters do in Minish Cap - they vanish in a puff of smoke.

And the same in Wind Waker.
In fact as far as I remember the monsters just vanish in pretty much all Zelda Games.

You haven’t encountered TVTropes before?
Then your life has not been truly ruined yet.

It’s essentially a collection of all the tropes that appear in any kind of story-based media:
games, anime, western animation and to a lesser extent live-action TV.


Yeah, Skyrim’s exactly what came to my mind and I was like “man, that never felt right” :smiley: Or at least very different from precise shooting. May be just me though.

I have, but only briefly, will have to take a closer look.


It’s always felt fine to me.
You know it’s going to go towards the centre of the screen because that’s where the projectile goes in pretty much every game.
It’s a darn sight easier to contend with than games where the projectiles arc.

If you only took a brief look then you weren’t doing it right. :P
TVTropes is widely reputed to be one of the biggest black holes of the internet.
The joke is that once you go onto it you keep clicking links and reading articles until suddenly it’s dark out and you realise you’ve spent all day reading tropes.


It used to be called “WWILF’ing” about twenty years ago, which stood for
What Was I Looking For? -> that feeling of going on the net / web / whatever, spending ages looking at web pages and realizing you’ve lost time and can’t remember what it was you originally went on for…:sunglasses::+1:
It’s happened so many times over the years :joy::scream:


I’m trying to play around with porting this puzzle collection.

It’s designed with porting in mind (it’s been ported to many platforms, including JS, you can play the puzzle in the browser by clicking them, there is also a porting guide). So it would be enough to rewrite just the frontend, and we’d get some 40 (?) puzzle games on Pokitto. Not promising to finish, just testing the waters :smiley:

So far what should look like this:

looks like this:



Looking a bit better now, and also getting playable.


The framework even handles the animation and everything:



I think I need an advice – I need to implement a clipping function. It should behave like this:

If clip(rect) is called, a clipping rectangle is established. All drawing calls will then only affect the pixels inside this rectangle. Then, when unclip() is called, the rectangle is destroyed and drawing affects everything again. (I am working with persistent display, the drawing API counts on it.)

How should I do this without having to reimplement all the drawing functions that Pokitto library offers?

Maybe I should draw into a separate off-screen buffer of the clipping rectangle size and then blit in on the screen? Can Pokitto lib draw into specified buffer, or only to the screen?

Going to sleep, will be back tomorrow :sleeping:


Having some palette issues, but it’s looking much better now:


Some issues worth mentioning:

  • Controls: some games are best played with, or even require, some advanced controls, like numerical keys or mouse. How to address this? Have a little on screen keyboard and a toggleable cursor mode?
  • Filled polygons: how to draw filled non-convex polygons without much hassle? At the moment I use an approximate method – I compute the polygon center, then draw a triangle fan from it to all the boundary points. This can fail of course, but may turn out to be good enough.
  • Clipping: mentioned above, ATM solved by clipping at the primitive level (not pixel accurate). E.g. you can easily clip a rectangle against the clipping rectangle by just adjusting its position and dimensions. But e.g. text you can only clip in a limited way like this (drop characters, skip drawing altogether, …). Again, may be a good enough solution.
  • Saving: the framework supports saving/loading, but I don’t know if it’s really needed. I may leave it out. actually not, I’ve misunderstood some function names


There is really huge number of puzzles in the collection!


Yes! And there is also an interface to easily add new ones.


Oooh this one looks nice:


Let’s see what the others look like.

Well, more or less glitchy still:


I love porting now, you get nice results for low effort:



Ooops, we’ve got one problem though :smiley: It doesn’t run on the hardware, I think it eats up too much RAM, or maybe the stack gets too deep? I thought that the emulator had the same constraints. Reported sizes (which one is relevant – hex or elf?):

gcc-arm/bin/arm-none-eabi-size BUILD/HelloWorld.elf 
   text	   data	    bss	    dec	    hex	filename
 106320	    552	   6824	 113696	  1bc20	BUILD/HelloWorld.elf
gcc-arm/bin/arm-none-eabi-size BUILD/HelloWorld.hex 
   text	   data	    bss	    dec	    hex	filename
      0	 106872	      0	 106872	  1a178	BUILD/HelloWorld.hex

I can’t debug this without a hardware debugger :confused: I think I can still try to go through the code and make variables const so that they end up in flash instead.

EDIT: Good thing is that the nullgame (just an empty game template) does runs.

EDIT2: Okay, fifteen game runs as well.

EDIT3: Hmm the cube runs as well, but very slow.


It does have the same constraints… but some of the exceptions are disabled because it would break whenever a game accessed something that wasn’t implemented yet.

Some exceptions are caught if GDB is connected, so you might be able to find out what’s wrong if you run the emulator with the -g flag.
Connect to it using arm-none-eabi-gdb (not native gdb) and target remote :1234


That is the best part of porting!

You can check the stack by using CheckStack() function. See the example “TestCrashScreen” in PokittoLib for usage.


Thanks @FManga and @Hanski, both very useful advice. I’ll give it a go. I’m now thinking that the problem is actually just speed because as I test more games, most run but very slowly. I’ll try to replace floating point with fixed point and also make use of the emulator profiling capabilities :slight_smile: If this all turns out to be more difficult to solve than writing my own puzzles, I’ll scratch this :smiley: (I still remember @FManga warning me about the pitfalls of porting, but sometimes you have to learn the hard way :slight_smile:) The sauce is available here.


Stupid, stupid me :exploding_head: I had debug printfs in every drawing function that I forgot to disable :neutral_face: Now it’s running fast of course.


The framework supports building the games into separate binaries or all into one monolithic binary. I wanted to go for the latter, but the issue now is that all the games don’t seem to be able to fit into flash, even with -Os (don’t know why they take up so much space, they contain no bitmap images or sounds.) Maybe I could split it into a few parts, let’s say by 10 puzzles.


Looks like they fit into 3 parts by 13 puzzles.


That … will have some performance impact :laughing: