[WIP] Doom clone FPS

open-source
wip

#1

Hello Pokitto friends,

I’d like to announce I’ve been for a while working on an FPS game using my raycasting engine. I’ve already shared this privately with some, but I dislike secrets so I am sharing this information. Sharing early has the great advantage of getting early feedback and ideas, so I very welcome any of these.

This may never be finished, don’t have high hopes, but ATM I’d really like to see this completed. Also I’ll be in a mental hospital for the next month so I don’t know if they’ll allow me to program and make progress on this during that time :expressionless:

The idea is to:

  • Create a Doom clone because Doom is awesome.
  • Focus on portability, HW independence and simplicity, so that the game can be played anywhere, can be used as a benchmark, doesn’t die along with any platform or library etc.
  • Completely truly public domain game under CC0, with code and original media, encouraging mods, remixing, porting, sharing, use for education, promoting free culture and so on.
  • Show and prove some design and philosophical ideas, i.e. how to write games in a portable way, show that you don’t need a GPU, FPU, OOP, and other such stuff for nice games.

Here it is running on Pokitto:

out

and on PC:

code:


#2

For some weird reason I like how it looks more on the pokitto than on the PC. It’s promising…

If you can get a base game running.and make it as easy as Doom to make mods/levels, much could be done with this.


#3

Pretty impressive tech demo, well done!
But most important, I wish you get back to full health soon!


#4

Me too actually :slight_smile: I like that look the old build engine games had in low res, the modern OpenGL high res texture filtered mods look weird.

Thanks, I’m kinda okay nowadays, it’s more that they need to send me there for observation, I take it as a holiday.


#5

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.


#6

I might try to compile it and try in the flesh to see how it runs :wink::+1:


#7

firmware.bin (81.0 KB)

I’ve only tried in emulator so far.


#8

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! :+1: I was humming that Doom tunes while trying this out :wink:


#9

This is impressive, please think about making a complete game!


#10

Yes :slight_smile: 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.


#11

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.


#12

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.


#13

Impressive demo!! It runs smoothly on the HW too


#14

Looking good, controls seem a little fast for me though :stuck_out_tongue:
From a gfx point of view, is the renderer capable of a little dithering to hide the banding a little?


#15

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.)


#16

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.


#17

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.


#18

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:

image

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.


#19

Whatever how you do it, I am sure it’s will be for the best! Can’t wait to see the progress. :+1:


#20

Here it is with the dithering, left is 2x subsampled (as it is now), right is no subsampling (runs a bit slowly):