One challenge will be to fit this into 256 228 kb with -O3 with 10 levels. From my rough calculation I’d hope it is possible, but it’ll need some cleverness.
2 Likes
I might try to compile it and try in the flesh to see how it runs 
1 Like
Do you think something that makes random levels like that Catacomb game on the Arduboy would make it easier? ( I know what you will say, level design won’t be as good)
EDIT: it runs really fast! I was humming that Doom tunes while trying this out
1 Like
This is impressive, please think about making a complete game!
3 Likes
Yes 
Random levels are definitely possible, but one thing that made Doom great were the hand crafted levels, so I’d like to keep that. I’ve made a format that kind of “compresses” the information but still stays readable and editable in the source form, hope it will be enough. I want the levels to be editable without extra tools (optional extra tools can of course be made).
This project is also why I am interested in Minimum Pokitto Library.
5 Likes
I’ve always thought it was funny that doom was a benchmark for a device, it never was my favorite but it is interesting to see it being used in such a way kinda like how the 1972 November playboy centerfold became the standard for scanner JPEGs.
1 Like
This is something that gets way too little recognition in gaming. The level design is what makes a good game either great or boring. 9/10 games I’ve played (Horizon on PS4) are dull dull dull after the first excitement wears off.
Doom level design was exceptional. The triggers, the lighting and hear-through walls. Most Doom clones were boring, not because they were technically inferior but because nobody designed the levels properly.
6 Likes
Impressive demo!! It runs smoothly on the HW too
Looking good, controls seem a little fast for me though 
From a gfx point of view, is the renderer capable of a little dithering to hide the banding a little?
Without meaning to turn this into a debate,
if you have the RAM to spare then you could theoretically store the levels on SD card and thus have more than 10 levels.
(That’s the sort of thing I always intended to do, but I never managed to get the SD API working,
and then I never found the time to write anything before getting distracted by something else.)
Yes, you can see it enabled in the SDL version – I turned it off for Pokitto for now but I’ll see, performance tuning will come much later.
Of course, my approach here is the same as with the book reader – I don’t want permanent storage to be required and I don’t want to add that extra complexity of reading files and a dependency on file handling library. My plan is to e.g. have game saves only as an optional feature depending on platform, and each platform can implement it differently (e.g. saving to files vs eeprom etc.).
The game would be a base for potential forks that could add this. People could e.g. add multiplayer and similar things.
1 Like
Although I can see that point of view, I would prefer my projects to be a single .bin file, but considering that 99.9% of pokitto users will be using an SD card, if a gameI was working on needed a little more space, I wouldn’t hesitate to throw a folder full of data on the SD card.
2 Likes
I really want to avoid files at any cost and I think it is very possible. At very worst I can split the game into two parts, or create a smaller version with fewer levels or fewer textures or something, but I have a lot of ideas on where to save space. It’s not just the portability and simplicity that I aim for, but I also want to see and show what’s possible within these limits.
You may have noticed there are only robots as enemies – this is because I not only want the game to be compatible with different devices, but also people, i.e. children, people who hate blood etc. It is also further aligned with my pacifist nature, though I don’t mind violence in video games at all. Here are the enemy and weapon sprites I have so far:
All images in the game, i.e. sprites, textures, backgrounds etc., are 32x32 pixels. One compression trick I use for images is that even though the game uses a 256 color palette (which I’ve also made), each image only uses its own 16 color subpalette of this main palette (as e.g. old Pokémon games did), so each pixel only takes 4 bits instead of 1 byte and thus only takes about 50% of space. I also try to use as few sprites as possible, e.g. my explosion animation is actually only one frame and the explosion sprite simply grows bigger to look like animated, and this explosion sprite is also reused in weapon fire animation etc. Also robots with wheels don’t really need a walk animation frame etc.
5 Likes
Whatever how you do it, I am sure it’s will be for the best! Can’t wait to see the progress.
2 Likes
Here it is with the dithering, left is 2x subsampled (as it is now), right is no subsampling (runs a bit slowly):
5 Likes
One thing I would really like to see in a raycast game , especially on the Pokitto, is rotated sprites. Sure it would mean a lot more art, but having the sprites rotatable to match the viewing angle would be out of this world!
Even if the effect was only used for collectable objects or background sprites, enemies would usually be facing you anyway
1 Like
If you mean rotating around y-axis that would mean having a lot of sprite bitmaps from different angles. Unless there is something like sprite stacks,
but that would need a lot of bitmaps too (and a lot of cpu cycles).
Edit: Actually, sprite stacks would fit better to isometric games
6 Likes
I was thinking more of just having a sprite sheet for the image from all angles of rotation and selecting the correct frame from the angle of view.
1 Like
That’s possible and easy to do of course, I’ve even managed to place real 3D objects rendered with my other lib:
The issue is the limited space, so I’d only do it if there is space left at the end.
Things I still don’t have figured out include:
- name of the game
- the ultimate weapon and what it should do
8 Likes