FreeGameDev

I'm looking to add some nice, but non-essential canned features to xSGE, a GNU GPL collection of eXtensions for the SGE Game Engine. Can anyone make some suggestions for such features you would find especially useful for 2-D game development? I'm looking especially for things where having a canned class or function would save a lot of work, but feel free to make any suggestions; even if it's inappropriate for xSGE, perhaps it would be something to add to the SGE.

This is what I have so far:

- GUI toolkit (virtual "windows" embedded in the game window with labels, buttons, checkboxes, radiobuttons, progress bars, and textboxes, plus canned message and text entry modal dialogs)
- Menu system (part of the GUI toolkit)
- Physics (interaction of objects with walls and slopes)
- TMX map loading
- Paths
- Lighting

Ideas for what to add (I'll add any ideas you post to this list):
- Character-by-character text display (for e.g. game dialog)
- Particles and emitters
- Tweens
- Pathfinding

These are in the SGE itself, so it wouldn't make any sense to put them in xSGE:

- Movement, including acceleration support
- Backgrounds (incl. parallax scrolling support)
- Transitions
- Directional collision detection
- Collision detection against groups of objects
- Animation
- Sprite sheets (via sge.Sprite.from_tileset)
- Delta timing

Although I don't have a lot of programming experience, I can suggest that your GUI toolkit could be rewritten to use a cross-platform widget toolkit, such as Qt and GTK+. Your program will require less porting efforts as they already handle most of the operating system-specific stuff. If you don't know how to or are not familiar with using one of the cross platform widget toolkits, you may need to spend additional time trying to learn one first.
You may already have seen some of these toolkits in action; they may be usable for you if you can find a function in one of those toolkits that enables you to "draw" other graphics and similar stuff. But for the only suggestion you said,

onpon4 {l Wrote}:Character-by-character text display (for e.g. game dialog)

may not be doable out of the box unless you can override the particular function that draws the text, as most toolkits will draw text very fast, although not all at once.

If you interested, you can look here for a bigger list: http://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries

Worldblender {l Wrote}:Although I don't have a lot of programming experience, I can suggest that your GUI toolkit could be rewritten to use a cross-platform widget toolkit, such as Qt and GTK+. Your program will require less porting efforts as they already handle most of the operating system-specific stuff.

Oh, that's not necessary. The GUI toolkit in xSGE uses an absolutely defined set of images and draws in the game window the same way any other game object is drawn. So it doesn't matter what system you use, it always looks exactly the same. Integrating a lightweight toolkit or really any regular widget library with a graphical application is too much headache, would have to be low-level (so, not xSGE's territory), and isn't really any more useful for games than the way I did the xSGE GUI toolkit I did.

For modal dialogs, on the other hand, Tkinter works just fine, I found out. That's why I stopped at message dialogs and text entry dialogs. You just need to "withdraw" the main Tkinter app.

Check out some other 2D game engines; if a lot of them support a feature, that's a good indication of usefulness.

I'm mostly familiar with Phaser, a HTML5 2D game engine, in fact for my pyweek 19 entry I pretty much recreated a small subset of it because it handles a lot of common tasks for 2D games. I'm not familiar with SGE's features, just skimming the classes list, but here's what I see missing (and have found useful in the past):

Collision management. Engines are all about improving productivity so make it as easy to add basic physics as possible. This means group vs. item or group vs. group collisions, checking overlap, even resolving overlaps if enabled, figuring out which direction the collision was, modifying the size of hit boxes, players sliding against walls etc. A lot of "game makers" make this as easy as checking a "collide" flag on game objects, you could do things along the same lines.
Animation, sprite sheets. Given a spritesheet, specify the frame dimensions, animation frames and duration, and that's it. You can support bitmap fonts using similar means.
Particles and emitters
Tilemaps. There's probably a python implementation of the tiled format already, if so it'll be good to support that in your engine.
Tweens and easing. A generic utility that you can attach to any variable - sprite alpha, rotation, x/y - to animate or move it.

I should mention that the Pygame SGE documentation can be found here:

http://pythonhosted.org/sge-pygame/

Check out some other 2D game engines; if a lot of them support a feature, that's a good indication of usefulness.

Alright, I'll try. I'm unfortunately not familiar with many of them; mostly just Game Maker, Game Editor, and ENIGMA.

Collision management. Engines are all about improving productivity so make it as easy to add basic physics as possible. This means group vs. item or group vs. group collisions, checking overlap, even resolving overlaps if enabled, figuring out which direction the collision was, modifying the size of hit boxes, players sliding against walls etc. A lot of "game makers" make this as easy as checking a "collide" flag on game objects, you could do things along the same lines.

A lot of that is in the SGE. The sge.Object.collision method can check for collisions between an object and another object, a list of objects, a class, or all other objects, and it returns a list of objects currently being collided with. Directional collisions can be detected with directional collision events (sge.Object.event_collision_{left|right|top|bottom}). Bounding boxes can be changed to whatever.

Can you think of an example of a case where it would be useful to check for collisions between two groups of objects?

I'm not quite sure what you mean by "checking overlap" and "resolving overlap". Do you mean precise collision detection? I've got that.

What aspect of "players sliding against walls"? It seems to me that this kind of thing would simply be setting the position to just above/below/next to the wall in question. The way the SGE currently is, I would set the bbox_{left|right|top|bottom} variables in relation to the wall's bbox_{left|right|top|bottom} variables.

Animation, sprite sheets. Given a spritesheet, specify the frame dimensions, animation frames and duration, and that's it. You can support bitmap fonts using similar means.

Is the sge.Sprite.from_tileset method flexible enough for what you're thinking of with regard to sprite sheets?

Particles and emitters

Didn't think of that. Alright.

Tilemaps. There's probably a python implementation of the tiled format already, if so it'll be good to support that in your engine.

Tilemaps isn't a concept I'm familiar with, but it looks like you're talking about something like this, right?

http://www.mapeditor.org/

And this:

https://pypi.python.org/pypi/PyTMX/3.19.5

It's a good thing you mentioned that, because I might have been reinventing the wheel lately. But is this something that should really integrated into the SGE directly? It seems like it's more likely something to read and then derive a room from.

Tweens and easing. A generic utility that you can attach to any variable - sprite alpha, rotation, x/y - to animate or move it.

That's another thing I didn't think of. Thanks.

onpon4 {l Wrote}:I should mention that the Pygame SGE documentation can be found here:

http://pythonhosted.org/sge-pygame/

Thanks; maybe I'm just bad at finding things but I couldn't find that link anywhere. I suggest you add a link prominently on http://stellarengine.nongnu.org/, preferably a link along the top that says "Documentation" or something.

onpon4 {l Wrote}:Can you think of an example of a case where it would be useful to check for collisions between two groups of objects?

Only for convenience, as the result is simply which object in group 1 collided with which object in group 2, so you can call collide(bullet_group, monster_group, bullet_hit_monster_callback) instead of writing nested loops.

onpon4 {l Wrote}:What aspect of "players sliding against walls"? It seems to me that this kind of thing would simply be setting the position to just above/below/next to the wall in question. The way the SGE currently is, I would set the bbox_{left|right|top|bottom} variables in relation to the wall's bbox_{left|right|top|bottom} variables.

As in collision resolution; if a player moves diagonally against a horizontal wall, they should slide along the wall horizontally for example. It sounds simple but there are a few common traps and corner (literally) cases.

onpon4 {l Wrote}:

Animation, sprite sheets. Given a spritesheet, specify the frame dimensions, animation frames and duration, and that's it. You can support bitmap fonts using similar means.

Is the sge.Sprite.from_tileset method flexible enough for what you're thinking of with regard to sprite sheets?

Does it support multiple animations per sprite? I'm just guessing from the documentation so forgive me if I get it wrong, but it seems that you only support one animation right now. To take platformers as an example, characters would have animations like idle, run, jump all in the same spritesheet, and the game needs to select different animations based on what the character is currently doing.

onpon4 {l Wrote}:

Tilemaps. There's probably a python implementation of the tiled format already, if so it'll be good to support that in your engine.

Tilemaps isn't a concept I'm familiar with, but it looks like you're talking about something like this, right?

http://www.mapeditor.org/

And this:

https://pypi.python.org/pypi/PyTMX/3.19.5

It's a good thing you mentioned that, because I might have been reinventing the wheel lately. But is this something that should really integrated into the SGE directly? It seems like it's more likely something to read and then derive a room from.

Yes that's right. With TMX support, developers can create a map entirely in tiled, load it in the engine, enable collisions per layer, and things will just work. Other features that might be useful include swapping spritesheets for layers, or just for a single tile, or to search for tiles with a certain custom attribute - these are some things I've used in another game. You want collision objects per tile but a single surface for the map (otherwise you'd need hundreds of blits, one per tile), and use dirty flags when tiles are updated to rebuild the map surface. It's not trivial, so it's good to support inside the engine.

c_xong {l Wrote}:Thanks; maybe I'm just bad at finding things but I couldn't find that link anywhere. I suggest you add a link prominently on http://stellarengine.nongnu.org/, preferably a link along the top that says "Documentation" or something.

Good point. I've done so.

c_xong {l Wrote}:Only for convenience, as the result is simply which object in group 1 collided with which object in group 2, so you can call collide(bullet_group, monster_group, bullet_hit_monster_callback) instead of writing nested loops.

Ah, so you're thinking of something that calls a particular function for each collision? This is a real example of a function that would do that:

{l Code}: {l Select All Code}

def group_collision(group1, group2, collide_function):
    for obj1 in group1:
        for obj2 in obj1.collision(group2):
            collide_function(obj1, obj2)


Honestly, I'm not too fond of this way of doing that, though. The SGE supports collision events, which are called any time any collision happens. So for example, if I had bullets and monsters, I would put something like this in the monster class:

{l Code}: {l Select All Code}

def event_collision(self, other):
    if isinstance(other, Bullet):
        self.destroy() # Or some other method that kills the monster
        other.destroy() # Or some other method that kills the bullet


Or alternatively:

{l Code}: {l Select All Code}

def event_collision(self, other):
    if other in bullet_group:
        self.destroy() # Or some other method that kills the monster
        other.destroy() # Or some other method that kills the bullet


c_xong {l Wrote}:As in collision resolution; if a player moves diagonally against a horizontal wall, they should slide along the wall horizontally for example. It sounds simple but there are a few common traps and corner (literally) cases.

Hm, I think I get what you mean. I had some trouble getting walking on the floor in a platformer I'm developing to work properly, and my solution ended up being this class:

{l Code}: {l Select All Code}

class Collider(sge.Object):

    @property
    def on_floor(self):
        # Note: This is expensive.  Store this value in an attribute,
        # such as "is_on_floor", and use that for routine checking.
        for tile in self.collision(SolidTop, y=(self.y + 1)):
            if not self.collision(tile):
                return True

        return False

    def stop_left(self):
        self.xvelocity = 0

    def stop_right(self):
        self.xvelocity = 0

    def stop_up(self):
        self.yvelocity = 0

    def stop_down(self):
        self.yvelocity = 0

    def event_update_position(self, delta_mult):
        xmove = self.xvelocity * delta_mult
        ymove = self.yvelocity * delta_mult

        old_x = self.x
        self.x += xmove
        if self.x > old_x:
            collisions = self.collision(SolidLeft)
            if collisions:
                for other in collisions:
                    if not self.collision(other, x=old_x):
                        self.bbox_right = min(self.bbox_right, other.bbox_left)
                self.stop_right()
        elif self.x < old_x:
            collisions = self.collision(SolidRight)
            if collisions:
                for other in collisions:
                    if not self.collision(other, x=old_x):
                        self.bbox_left = max(self.bbox_left, other.bbox_right)
                self.stop_left()

        old_y = self.y
        self.y += ymove
        if self.y > old_y:
            collisions = self.collision(SolidTop)
            if collisions:
                for other in collisions:
                    if not self.collision(other, y=old_y):
                        self.bbox_bottom = min(self.bbox_bottom,
                                               other.bbox_top)
                self.stop_down()
        elif self.y < old_y:
            collisions = self.collision(SolidBottom)
            if collisions:
                for other in collisions:
                    if not self.collision(other, y=old_y):
                        self.bbox_top = max(self.bbox_top, other.bbox_bottom)
                self.stop_up()


SolidTop, SolidBottom, SolidRight, and SolidLeft are all just classes based on sge.Object that represent what their names suggest.

I suppose it would be a useful addition to xSGE, perhaps in a module called "physics" or something. Maybe some other useful stuff could go in there, too.

c_xong {l Wrote}:Does it support multiple animations per sprite? I'm just guessing from the documentation so forgive me if I get it wrong, but it seems that you only support one animation right now. To take platformers as an example, characters would have animations like idle, run, jump all in the same spritesheet, and the game needs to select different animations based on what the character is currently doing.

It's just one animation per sprite, but it would be very easy to load one sprite sheet as several different sprites. For example:

{l Code}: {l Select All Code}

sge.Sprite.from_tileset("character", "character_idle", x=0, y=0, columns=3, width=16, height=32)
sge.Sprite.from_tileset("character", "character_run", x=0, y=32, columns=5, width=16, height=32)
sge.Sprite.from_tileset("character", "character_jump", x=0, y=64, columns=1, width=16, height=32)


A question about tweens:

An easy, high-level way I can think of to implement them would be a sge.Object class that adjusts the appropriate attribute based on the animation frame. Would that be powerful enough, or should I strive to make actual sprite frames with tweening?

onpon4 {l Wrote}:A question about tweens:

An easy, high-level way I can think of to implement them would be a sge.Object class that adjusts the appropriate attribute based on the animation frame. Would that be powerful enough, or should I strive to make actual sprite frames with tweening?

I'm not sure what sprite frames are in SGE. I was simply thinking of something that is updated every frame and mutates an attribute.

Here's an example in Phaser:

{l Code}: {l Select All Code}

 this.instantReplayTween = this.game.add.tween(this.instantReplay)
.to({alpha: 0.5}, 300, Phaser.Easing.Sinusoidal.InOut)
.to({alpha: 1}, 300, Phaser.Easing.Sinusoidal.InOut)
.loop();

This creates a looping tween that changes the alpha of a sprite (this.instantReplay) from 50% to 100% and back again, taking 300ms per tween and using the Sine.InOut easing function. You can implement the same thing by using Python's __dict__ attribute.

Sprites are used to store the actual images. They're essentially like arrays of surfaces that make up an animation, with some meta-data added mostly to define certain default settings. Objects, on the other hand, are things that are visible or interact in a game, like a player, a coin, or a floor tile. Objects have attributes that can be used to manipulate how their sprites look.

Basically, the difference between making actual sprites out of tweens and making objects do tweening is the former would create actual images (surfaces) that can be re-used anywhere, whereas the latter would simply do dynamic transformations on the image (well, technically, these transformations are stored in a cache for better efficiency, but that's just a back-end detail; point is, you wouldn't be able to, for example, save the resulting animation as an image file, and you would have to re-apply the tween any time you want to use it rather than just defining them once at the start).

Alright, I've got that physics thing as of xSGE 0.4a3. Tested it, and it seems to work perfectly:

http://git.savannah.gnu.org/cgit/stella ... .py?h=xsge

It supports slopes. This is my first time actually doing slopes, but I'm quite happy with the result, for the most part.

onpon4 {l Wrote}:Can anyone make some suggestions for such features you would find especially useful for 2-D game development?

- Lighting and shadows, with support for glow/normal maps for fake 3D/relief effects.
- Repeated background support.
- Path support (as in path finding, or path movements at all)

Sauer2 {l Wrote}:- Lighting and shadows, with support for glow/normal maps for fake 3D/relief effects.

This can be done with color blend modes. Could you explain what kind of API for lighting would make using the effect more convenient, though?

- Repeated background support.

Unless I'm misunderstanding, I think the SGE already has that. Backgrounds can have a color, and any number of "layers". Any given layer can repeat horizontally, vertically, or both, and scroll at any speed relative to camera movement, so it's also easy to achieve a parallax scrolling effect (in fact, I did this with the first game I've made with the SGE, Pacewar).

- Path support (as in path finding, or path movements at all)

I guess there's no reason not to have paths. I've just never personally found a use for them, so I didn't think much of it.

Pathfinding... I've never done or thought about that before. I'll have to figure out how best to do it. What would be a good example to look at?

onpon4 {l Wrote}:Pathfinding... I've never done or thought about that before. I'll have to figure out how best to do it. What would be a good example to look at?

AmitP has some nice pages on pathfinding, here's one: http://www.redblobgames.com/pathfinding ... ction.html

Pathfinding depends on the map itself; you can implement a generic version with callbacks for things like getting neighbours, edge cost, h function and accessibility. If you have a specific map type (e.g. chessboard tiles), you can have a simpler interface.

Thanks! Looks like a great guide.

onpon4 {l Wrote}:

Sauer2 {l Wrote}:- Lighting and shadows, with support for glow/normal maps for fake 3D/relief effects.

This can be done with color blend modes. Could you explain what kind of API for lighting would make using the effect more convenient, though?

Maybe light emitting objects and fast possibility to load a normal map for lightening, like shown in
youtu.be/Xmn6zhDJGLE?
Bonus for supporting flickering!

Also, maybe a function to set the global brightness would be nice, to make things like
youtu.be/ajBURUTRN5Q (1:10) easily possible.

Sauer2 {l Wrote}:Maybe light emitting objects and fast possibility to load a normal map for lightening, like shown in
youtu.be/Xmn6zhDJGLE?

So you're thinking of Ethanon Engine's lighting system? Alright, I'll take a look at that.

As of version 0.5, xSGE now includes a physics framework, with support for unisolid, slopes, and moving walls, as well as TMX loading and basic paths (no pathfinding yet). It's powerful enough to easily produce a great platformer engine, and an example of this is included with xSGE.

Huh, funny I forgot to mention xSGE 0.6 here when it came out. It added lighting support; it works by taking a sprite that represents how an area should be lit up (white is light, black is non-light, red is red-colored light, etc).