>Get too specific and participants end up constrained without any room to stretch, too general and the less able participants pancake against the very start of the difficulty curve.
For sure, there is definitely a balance to aim for somewhere between "hello world" and a complete game.
>It really depends on what gameplay possibilities you want to load into the base toolkit you're creating.
I really don't want to constrain anyone's gameplay possibilities. That's one reason I'm trying to keep the criteria as broad as possible. I haven't even defined what a 2D platformer is. As long it's from a side view and you move around a 2D screen, I don't really care what people make. Sonic-like? Metroidvania? Shooting game like Alien for the SNES or Jurassic Park for the Genesis? VVVVVV-like puzzler? Game with vehicles? Terraria-clone? Go nuts.
>This starts to get into too-specific territory, but I think including a basic implementation would go a long way towards getting people started.
You think? It's actually kind of involved, loading a level, its map, graphics, enemies, pickups, level-specific logic or scripting, and then unloading it all (without memory leaks) to move to another level. My idea was a Level() object that would be loaded from xml, with 2 or 3 of them to show how to handle that. A basic "game" could then be: new game -> load world 1-1 -> beat that -> load world 1-2 -> beat that -> load world 1-3 -> beat that -> game over. congratulations. A "level" would only be 2-3 screen lengths (or heights) long and can be whipped up in Tiled in minutes. What did you have in mind?
>It'd be especially good if the monster used the same state machine system as the player.
Can't guarantee it'll be that generalized but I can try. I'd like to think the player state machine would serve as an example for implementing enemy or level/world state machines in case I wasn't able to.
>Maybe you already addressed this, but what about sound and music?
I did not, though I had thought of it. I'm still looking around for good stuff but year, BGM will play (maybe level-specific), and sounds will be used where appropriate (on jumping, collecting something, attack/explosion, death, etc.).
>I know you don't want to do a theme beyond "maek platfoemr" but I think it might be a good idea.
The goal was to keep it sufficiently broad, while still keeping everyone mostly "on the same page." I'd like it if people were able to share both high-level approaches and algorithms as well as implementation details, hence constraining the game type and framework (Raylib). Both are optional, though, if you really want to do something else or are more comfortable with a different framework. I figured some small subset of people might be turned off by those constraints, and adding a further one - theme, might turn off yet more people. But who knows. It's the first time, I have no idea how many people will participate and no idea how it'll turn out. I just hope the jam can garner some interest and be fun and educational.
That said, I'm open to suggestions. Did you have a theme in mind? What do you think would be fun to do?
>Really admire what you're doing here, by the way. I'm fully bogged in the jungle quicksand of my own game but perhaps I'll find time to make a little thing for this too.
Thanks. What are you working on?
Nice fox butt.
>They need not be projectiles, but having examples of the create/move/do-something-on-collision/remove cycle would be a good thing. Projectiles happen to be a very simple case, so perhaps they're a good thing to include in the standard example.
Sure, that was the idea. Spawning something, updating/tracking it, doing something if it interacts with something, and destruction of it.
>I think this goes way into "too specific" territory, and also provides more to go wrong.
You may be right. I wanted to get away from my very-specific Mario-like that I've been playing around with and to a more general platformer framework, one that could support both old-school pixel/tile types as well as newer ones, with freely-placed objects and non-grid aligned colliders and graphics. I grabbed some pics of games that I'd consider not-tile-based, at least not wholly-rectangular ones. That's why I'd like to have examples for other collision types besides AABB - AABB. Tiled supports drawing collision shapes over maps as well, so I'd like to show how to import those and collide with them, provided they're properly convex. See first pic for what those triangles look like in the editor. In the exported XML they show up like so:
<objectgroup id="6" name="Object Layer 2">
<object id="8" x="160.043" y="159.957">
<polygon points="0,0 15.913,15.9565 -0.0869565,16"/>
<object id="9" x="176.063" y="176.063">
<polygon points="0,0 32.0625,15.9375 -0.0625,16"/>
You can add custom properties to these with values that get exported in the map file as well, so you could tag a volume as damaging, or collision shape as slippery, or whatever. I'll write up something about that then. But yeah, balance. Trying to make the skeleton of a game here, not necessarily a game engine. Appreciate the input and hope we get some more coming in eventually; I'd like to hear more about what people are interested in doing too, whether it's themes or mechanics or styles or whatever.