Prismatic Engine: An engine to simplify C development on Playdate

Hey all, I've been working on an engine for building games using the C api and it's reached a point where I feel that it's ready for the games that I'm personally looking to build.

The primary goal is to simplify and speed up the development process by minimizing memory management, without sacrificing flexibility. Essentially, it has a bunch of modular convenience functionality that you can choose to use, or not, as you see fit.

I wanted to share with the community in case anyone finds it helpful, and because I'd love for some other people to poke at it and give me some feedback.

Screenshot

A demo running an imported LDtk map, with collision. After a few seconds, it transitions to a new scene with a moving Sprite.

Peek 2024-05-09 21-43

Primary Features

  • Scene Management System
  • Animated Sprites
  • Graphical Transition Effects
  • State Machine System
  • LDtk Super-Simple Tilemap Loader
  • Small memory footprint
  • Playdate-style api: Scene* s = prismaticScene->new( "Scene" );
  • Convenience Playdate API aliases

Caveats

  • Work in progress - Probably has bugs I haven't uncovered
  • Linux-specific build system (for now)
  • Boilerplate project, not an imported library

The repo is public and can be found here: GitHub - Sheep42/prismatic-engine: A game engine for the Playdate C API

9 Likes

I've had a quick look at the source. It seems that you wrap structs like sprites and images into your own data structures and expose some of the convenience functions but still expect user to operate on playdate's API directly too right? For example if I want to update Z index for a sprite I would need to access the sprite pointer from the PrismSprite and call pd->sprite->setZIndex? Just making I understand the API design :smiley:

Great work and thanks for sharing!

Yep, that's exactly right.

It was a conscious decision to do it that way, in order to avoid reinventing the wheel in regards to the stuff that the Playdate API already does well on its own.

Continuing with your example of Sprite z index, a full example would look something like this:

string paths[3] = { 
    "assets/path/to/frame-1",
    "assets/path/to/frame-2",
    "assets/path/to/frame-3",
};

LCDBitmap** images = prismaticSprite->loadImages( paths, 3 );
PrismSprite* player = prismaticSprite->newFromImages( images, 0, 0.15f );

sprites->setZIndex( player->sprite, 1 );

So, this example creates a PrismSprite with a PrismAnimation - Under the hood, the animation is just setting the LCDSprite image for the parent PrismSprite on a timer, meaning your z index will carry through for static or animated sprites.

Like I said, this is still very new and I'm just starting to build with it myself. So if you do wind up playing with it, let me know if anything feels like it could use improvement. :slight_smile:

1 Like