What makes up a minimalist 2D game framework?

[user123456789]

Hi,

 

 

I have been having this question on my mind far too long - so I decided to make a topic about it. Hence, I personally believe that things such as minimalist products, user interfaces and games exists (in terms of features and a like), so it makes me to question what could be the contents of minimalist 2D game framework?

 

To give a more deep explanation, the purpose of this topic is to reach some sort of understanding what is needed (minimum) if someone want's to make a new game framework. Moreover, if someone can give an insight how he or she get started of making one (steps to do first), it would be great. Thus, even though I think that there is great existing game frameworks available, for me, most of them are too complex to be used in every single project as there is always things such as the learning curve, file sizes & a like; making things from "scratch" time to time is a great change to learn more.

 

So, what makes up a minimalist 2D game framework? What are the things which you consider as a must-have? 

 

Regards, Mane

[d13]

These are the minimum:

 

- asset loader (to pre-load images, sounds, font files and json files)

- game loop

- game state manager

- sprites

- A render function (to render the sprites)

- sprite state manager (To change how a sprite appears if something happens to it)

- groups (To help manage groups of sprites as single units, game scenes or levels)

- scene graph (to help manage sprites and groups);

- pointer object (mouse and touch events)

- sound player (WebAudio API)

 

Some optional things (you'll be doing these a lot, but they may not need to be baked into the framework):

 

- Collision functions: point, circle and rectangle collisions as a minimum (probably based on SAT.)

- Button object: a kind of sprite that you can click on or touch to make things happen.

- Keyframe animation player for sprites.

- A loading state so that you can display a loading progress bar.

 

I also find all the current game frameworks too complex.

I find that I'm often coding around features and options that I'll never need. 

And if I'm not making the kind of the game that the framework expects that I'm trying to make, it can be an uphill struggle.

 

That said there are some things that are really difficult and tedious to code from scratch.

And doing them yourself can be so error prone that you'll be fighting bugs for months.

These are things like WebGL rendering, particle effects, and physics.

So instead of making these yourself, use some of the best, most flexible open-source components and integrate them into your own high-level framework.

Find ones that are very focused on doing one thing well, and that are easy to customize.

(Some that I like: Pixi, Proton, Howler, PhysicsJS, Tween.js, Font.js.. but the choice is endless)

If you don't like the API that these components use, just wrap your own high level API around them.

So if you don't like some component's horror-show API...

var box = new CRAZY-3D.bodies.squarish(new VECTLAB.MutableVect3(0.5, 0.5, 0.5), "yes", false, 0.87, {"polar", true});

...just make your own function that composes and returns that object, so that you just have to write this:

var box = cube(0.5);

You then end up with extremely minimalist application code, that you completely understand, but that still leverages the power of these frameworks.

 

All the current HTML5 game frameworks started off as somebody's hobby and grew from there - so you can do the same thing

[user123456789]

@d13 nice, really good reply, thnx. ! 

 

Now that I read your post.. maybe also some sort of documentation can be calculated as a must-have. As a minimum, generating it from the source code comments - otherwise it truly is a framework which no one else than yourself uses. (ofc. if that is the point, it doesn't matter).

 

Also, it makes me wonder if build or release functionality is needed. Maybe not.    

 

And good points about existing stuff, I also think that making _everything_ from scratch is not a good idea (today) - its about finding the level which is suitable and providing support for the rest to be added to the framework (used along with the framework, not embedding it in as a must-have).

 

Hmm, and btw. do you have insight is opengl rendering a must-have today(?) - if purpose of the framework is to do sprite based games - do we really need opengl? (such as pixi.js swapping of modes) Or is opengl support essential always if person want's to do games which run at mobile devices and desktops?

[d13]

> maybe also some sort of documentation can be calculated as a must-have. As a minimum, generating it from the source code comments

 

A problem that I find with most documentation, and I specifically mean a generated API reference doc, is that it lacks a narrative.

It's like trying to read a story with all the sentences cut up and out of order.

If you're the only user of your framework, then it's just fine.

But if you want to attract other users then the better, but much harder, thing to do is to write a clearly written, non-technical step-by-step user's guide.

Without that users will just take one look at the API reference, think that's it's too complicated, and find something else... at least that's what I do

 

> do we really need opengl?

 

Low-level rendering on the GPU is definitely the way to go, the only question is how to get there.

 

I think there are three ways of looking at it:

 

- WebGL is vastly faster and more resource efficient than canvas rendering, and all new current platforms are supporting it.

If you want the most performant game engine you can get - right this minute - then you need a WebGL renderer.

The biggest performance bottleneck for games is almost aways rendering, so whatever you save there can be spent on other aspects of your game, like physics.

 

- Canvas and the DOM is fast enough, and the compatibility is great.

And if you wait 6 months, your game will run as fast as it would have have with WebGL 6 months earlier, thanks to better hardware and better software implementations.

And  maybe if you wait even a little bit longer, browsers will automatically start rendering Canvas Drawing API calls and DOM elements straight to the GPU via WebGL anyway, giving your games a free performance boost. (There's early experimentation going on with this - check out webkitjs which renders HTML to WebGL: http://trevorlinton.github.io )

 

-... or you just want to start making games quickly with the best current rendering technology and not have to agonize about it.

This is where using a renderer like Pixi is really useful because it does all this hand-wringing for you, and, presumable will make the best choices for you over time.

 

 

 

[user123456789]

Hmm.. good stuff. I think I got the big picture (or minimum picture within context of this topic ) which I was looking for. I think the list doesn't look that hard or long to make a framework of your own. Especially, because some of the functionality can be added using open-source components. I think the real challenge is just to take hands out of the pockets and start making it. 

[harrywatson]

Great sounds good, this might help....

 

http://corehtml5canvas.com/code-live/ch09/ungame/ungame.html

[d13]

Coquette is a micro game framework:

 

http://coquette.maryrosecook.com

 

Here's Space Invaders in 170 lines of annotated code, without any framework:

 

http://spaceinvaders.maryrosecook.com

 

http://spaceinvaders.maryrosecook.com/annotated-source/game.html

 

Pretty much everything you need in a game, and you could abstract your own minimalist engine from it.

[BdR]

I think you shouldn't focus on creating a game engine, instead focus on creating a game.

 

If you make 2 or 3 games without any engine or library (like the Space Invaders example game) then you'll probably have reused a lot of code between those games. If you extract the reusable functions and classes into a library, then you've got your game library.

 

I suspect that is how most game engines came into existence in the first place.