[WIP] A generic platformer w/ object-oriented game engine

[Jamish]

First off... hi! I'm Jamish and I'm new here. I'm a 23 year old computer engineering graduate from Nebraska. I got my Gamebuino in December and I've been working on a game for about 3 days now.

You can jump, wall jump, stomp on enemies, and hold A to run faster. I mimicked Mario physics, so it should feel pretty familiar (albeit with slightly different acceleration/velocity values).

To be honest, the whole thing is a bit over-engineered right now. I've made a C++ game engine for the Gamebuino (which may be more overhead than it's worth right now... but to be honest, I'm liking the inheritence, because all of the world and object collisions happen in the base class).

Example of why this is nice... all the collision detection is handled in base classes, so all you gotta write is this:

Code: Select all

 
// In Player.cpp
void Player::collideWith(Actor* other) {
    switch (other->type) {
        case T_ENEMY:
            Enemy* o = static_cast<Enemy*>(other);
            if (vy > 0) { // Same check as in Super Mario Bros., bugs and all :)
                o->die();
                jump();
            } else {
                die();
            }
        break;
    }
}


(speaking of which, does anyone know if dynamic casting is possible with Arduino's C++ implementation?)

It has an animation engine, too, but it's currently only used by the player and hasn't been abstracted out. It supports instantiating new game actors on the fly (that go into stasis when off-screen to save CPU/RAM), so it's pretty flexible.

The level is stored in PROGMEM. I generate the map data from a .bmp, so I use an image editor as a level editor. I hope to add SD card streaming for levels soon (provided it's fast enough to do so), otherwise I'll run out of program space. SD card streaming would also allow for a companion game to let you make levels on the Gamebuino itself and save them to SD to play in the real game. If SD card streaming isn't fast enough, I could always read a level from the SD card to EEPROM, but the 100,000 rewrites makes me nervous.

I'm planning on adding music, more levels, more enemies, menus, and so on. Really, what I have now is all the groundwork so I can test streaming assets from the SD card. If all goes well, this game will pave my way for some more ambitious projects. Or maybe I'm just too optimistic

Plus, I'll probably release a less-specific pared-down version of my engine if anyone else wants to use it and improve it!

Here's what I have so far. Ignore the awkward level design, I just needed something to test the engine out:


Try it out and let me know how it feels! It's hard to play on an emulator, but it feels great to me on the real hardware. https://dl.dropboxusercontent.com/u/4239184/gamebuino/JAMISH.HEX

[Drakker]

This looks absolutely fantastic. I really like how you managed to make the character move so smoothly with so few pixels. I can't wait to try it, and tell me if you need help with levels design, I'd love to make a few!

[Jamish]

Thanks! When I get a few more features fleshed out, I'll post the source, or at least a hex. Probably the end of this weekend. I need feedback on the feel/physics/controls, and you can tinker with making bmp levels!

[rodot]

Looks awesome, I think it could be forked in the current state of development to make an example about object-oriented programming before it gets too complicated. Would you mind sending me the source so I can add it to the library examples ? Or simply fork it yourself from the beta branch of the library and do a pull request. Don't forget to add a license header with your name, website, or whatever you want

I've always read that Arduino doesn't supports dynamic allocation, that everything has to be declared and allocated at compilation time. But I just stumbled on that, which seems to provide a way to do it. They say that it may cause heap fragmentation though.

Usually what people do is that they create arrays large enough for them to be able to contain the larger data they will ever need. In the case of object oriented I guess it's kinda the same idea.

If streaming from the micro SD card isn't fast enough, you can write to PROGMEM at running time using the bootloader thanks to a function added by Myndale. Also note that the display buffer is public so you can use it as an SD car buffer (so you save 512B of RAM out of 2048 available, which is nice). All credit goes to Myndale for this idea. You could also use a RAM buffer instead of doing actual real time streaming from the micro SD card.

Edit: you game really makes me think of SMB... I mean Super Meat Boy

[frakasss]

That's just awesome! Need to see this soon on the 'Games' page!

[erico]

Love the gfx and animation!

[Drakker]

This gets me thinking, Myndale as realtime decompression of GIF-like compression for his lunar lander project, maybe this could be of use for your project. It would allow you to store larger levels in memory, thus reducing SD card access. I have no idea how much CPU overhead this causes, but having seen what Myndale can do, I'd guess it's pretty good.

[Jamish]

This gets me thinking, Myndale as realtime decompression of GIF-like compression for his lunar lander project, maybe this could be of use for your project. It would allow you to store larger levels in memory, thus reducing SD card access. I have no idea how much CPU overhead this causes, but having seen what Myndale can do, I'd guess it's pretty good.

You mean this one? http://gamebuino.com/forum/viewtopic.php?f=13&t=1075 I didn't know that project was out there. Fantastic! I'll check it out and see what I can learn from it. Much appreciated!

Rodot, I am indeed doing dynamic allocation in this snippet:

Code: Select all


// Defined in Engine.h:
Actor* actors[ACTORS]; //ACTORS is defined to be some arbitrary limit
void addActor(Actor* actor);
void removeActor(uint8_t id);

// Implemented in Engine.cpp:
void Engine::addActor(Actor* actor) {
    for (uint8_t i = 0; i < ACTORS; i++) {
        if (!actors[i]) {
            actors[i] = actor;
            actor->id = i;
            break;
        }
    }
}
 
void Engine::removeActor(uint8_t id) {
    delete actors[id];
    actors[id] = NULL;
}

// Finally, in Engine::update() somewhere:
addActor(new Player(x, y));


But I am unsure of how to do dynamic casting. In my original post you can see that in order to cast the "other" actor in a collision, I first had to check a "type" variable that I defined myself as a preprocessor constant.

Thank you for the bootloader example, I had no idea I could do that. I also didn't realize that the display buffer is public! I draw the tiles and the actors at the very end of each frame, so it looks like I have an extra 512B of RAM to abuse before I start writing to the buffer.

I'll need a RAM buffer if I'm doing SD streaming. With my tile size, I could fit a 128-tile-wide level into the display buffer of 512B. But I'm already getting slowdown when the screen is over half full of tiles, so I'm not sure I could spare the SD card read every frame (unless use tiles sparingly, which is no fun!) Regardless, loading once at the start of each level would be the best option, meaning writing to flash is the best course of action. Do you know about the life of the flash memory? How many rewrites can it sustain?

Unfortunately, I don't know if this would work as a true Arudino Sketchbook example. Because I'm using header files and everything, my game has to be included as a library and then run with a loader INO. But I'll still get you all the source files! Just let me clean up some of my code and make it a bit more generic before I hand it off to you.

I'll release some code with my current progress by the end of this weekend. In the mean time, try out the hex. Let me know how you guys like the feel of the controls. I found that it's much easier to play on the real without delay from the emulator.

https://dl.dropboxusercontent.com/u/4239184/gamebuino/JAMISH.HEX

[rodot]

Oops, sorry about the dynamic allocation/casting confusion... I'm afraid I can't help you here.

There is an example to show how to access to the public display buffer, but I guess you won't need it considering your level

The lifetime of the flash memory is discussed in this topic :
The program memory officially wears out after 10 000 cycles according to the datasheet, but it's likely to be way more than that, if it's like the EEPROM lifetime.

Out of topic, but wich IDE do you use then?

[Jamish]

Oops, sorry about the dynamic allocation/casting confusion... I'm afraid I can't help you here.

There is an example to show how to access to the public display buffer, but I guess you won't need it considering your level

The lifetime of the flash memory is discussed in this topic :
The program memory officially wears out after 10 000 cycles according to the datasheet, but it's likely to be way more than that, if it's like the EEPROM lifetime.

Out of topic, but wich IDE do you use then?

Cool, so it IS super simple to use that memory space. I suppose I don't need to worry about clearing the data out when I'm done, since "gb.display.persistence" is false by default.

I just use Notepad++ for my .h and .cpp files, then run my .ino through the Arduino IDE. The INO is pretty thin:

Code: Select all

#include <Engine.h>
#include <Gamebuino.h>

Gamebuino gb;
Engine eng;

void setup() {
    gb.begin();
    eng.begin();
}
   
void loop() {
    eng.update();
}

All the code that normally goes in loop() is now in Engine::update(), so I never need to modify the INO.