SGE Game Engine 0.24 - Looking for feedback

SGE Game Engine 0.24 - Looking for feedback

Postby onpon4 » 11 Mar 2016, 15:07

The SGE Game Engine is a library for Python designed to make 2-D game development easier. The mission of the SGE is to take care of as many details as possible, so that a game developer's efforts can be focused on the important aspects. In this sense, it's an alternative to things like Cocos2d and Love2d. More information can be found on the SGE website, found here:

http://stellarengine.nongnu.org/

Now, version 0.24 of the SGE has been released, and I'm planning for this to be the last beta release. So I would like some feedback. I inite everyone interested in doing so to check the documentation and let me know, either by replying to this topic or by submitting a bug, if there is anything you feel is useful missing from the SGE.

If you're so inclined, you can also give making a game with the SGE a try and let me know about your experience. :)
User avatar
onpon4
 
Posts: 535
Joined: 13 Mar 2014, 18:38

Re: SGE Game Engine 0.24 - Looking for feedback

Postby aspidites » 20 Mar 2016, 15:44

Just spent about a half hour going through the hello world tutorial, and I have some preliminary impressions. Before I give those, I'd like to offer some context:

- Reading and writing Python is my day job
- In my off time, I write Haskell, as I prefer FP to OOP
- I've worked on a couple of open source game projects, though I've never written an engine myself
- I've also messed with a lot of engines and libraries

All this is not to say that you should listen to me because I know what I'm talking about, but rather that I'm not exactly viewing this objectively, so my subjective opinions should be taken with a grain of salt.

Pros:
- I appreciate that there is both API and tutorial-style documentation. Often, open source projects forget one or the other, especially the latter.
- From what I saw, the API was consistent, which made it easier predict what something should look like without paying too close of attention
- The example works. It seems obvious, but I've often run into projects that give examples that aren't self contained, which leave me scratching my head about what setup I forgot to do
- Supports both Python 2 and 3.
- In theory, not tied to pygame, though that's the only implementation. I suspect that writing another backend (pysfml, for instance) should be easy, though perhaps I should reserve judgement on that until I attempt to do so or another backend emerges.

Cons:
- Stringly typed event handling. If i mistype "escape" as "esape", nothing will warn me. Had enums (or even a class with attibutes) been used, I'd at least get a type error [1]
- Global state. That sge.game is a singleton scares me. Needing to manipulate global objects makes it difficult to reason about the code, which could be a debugging nightmare when things go wrong
- Lack of separation of concerns. The project_text method is concerned with rendering text in a specific font and color at a particular location on the screen. I'd have preferred more separation here [2].
- I don't know what the game class is buying me if we are always operating on the sge.game singleton. I'd expect "self.project_text" instead of "sge.game.project_text" and "game.start()" instead of "sge.game.start() (after defining "game = Game()" of course).

[1] Note that in the following code, if I used "if key is Keys.Esape" (missing "c") then I'll get a runtime value error. In the original where we check against the literal string "escape", the code would just continue to run if I typed "esape" instead.
{l Code}: {l Select All Code}
import sge

class Keys:
    Escape = "escape"


class Game(sge.dsp.Game):
    def event_key_press(self, key, char):
        if key is Keys.Escape:
            self.event_close()

    def event_close(self):
        self.end()


class Room(sge.dsp.Room):
    def event_step(self, time_passed, delta_mult):
        sge.game.project_text(font, "Hello, World", sge.game.width / 2,
                              sge.game.height / 2,
                              color=sge.gfx.Color("black"), halign="center",
                              valign="middle")


Game()
background = sge.gfx.Background([], sge.gfx.Color("white"))
font = sge.gfx.Font()
sge.game.start_room = Room(background=background)


if __name__ == '__main__':
    sge.game.start()



[2] I think I'd prefer that what is being rendered and where it is being rendered be separate concepts.
{l Code}: {l Select All Code}
class Room(sge.dsp.Room):
    def event_step(self, time_passed, delta_mult):
        # of course, I'd also rather that named colors and alignments weren't strings, but that's a separate issue
        text = Text(font, "Hello, World", color=gfx.Color("black"))
        sge.game.blit(text, sge.game.width / 2, sge.game.height / 2, halign="center", valign="middle")
aspidites
 
Posts: 30
Joined: 19 Jan 2010, 11:49

Re: SGE Game Engine 0.24 - Looking for feedback

Postby enalios » 20 Mar 2016, 17:28

Hi there! I tried out SGE last night!

Let me tell you what kind of user I am first: I've done a few game jams using Flixel, I've done a few using Game Maker. I have two projects I'm working on in Unity. I also design tabletop games. By day I'm a full-stack Web developer primarily, but I also work in C# and Java from time to time. I get restless and bored so I plan on using my raspberry pi to develop on.

Setting up and stuff was fairly simple, but I would have liked something on the website that detailed how to go from zero python experience to the first tutorial. Like a Tutorial 0. It's been a while since I've touched python the readmes and stuff cleared it all up, of course - but a newbie, or someone on the fence about diving into the hobby may not know about running setup scripts, or putting the library in the same folder or any of that.

The tutorials deal with drawing things to the screen. It would be nice to have an example of how to add an image sprite, and how to add a simple animation. I can suss out how to do it from the documentation (which is pretty great, by the way!) but I've seen a few people compare SGE to Flixel and for a lot of people that means dead simple, "spell it out for me" tutorials - but then again those are primarily by enthusiastic users ...

I absolutely plan on recreating a few simple ideas with this engine soon! It "feels good" to use and your whole package (website, tone, and code) feels very approachable and welcoming and not like it's only for the most experienced and technically-minded. I'm legitimately excited to use it, so please keep developing it!
enalios
 
Posts: 2
Joined: 20 Mar 2016, 17:09

Re: SGE Game Engine 0.24 - Looking for feedback

Postby onpon4 » 21 Mar 2016, 01:51

Thank you for the feedback! I see you mostly commented on the general design choices of the SGE, which probably aren't going to change much, but I still appreciate the perspectives. :)

aspidites {l Wrote}:Stringly typed event handling. If i mistype "escape" as "esape", nothing will warn me. Had enums (or even a class with attibutes) been used, I'd at least get a type error

Yes, that's true. The main reason it's defined purely as strings is to simplify creation of config files for games and ensure that they would be implementation-agnostic. Alignment used to be constants, but I changed them to strings as well for consistency. But keeping the strings
while also having the key names as some sort of variable (perhaps a class with attributes as you suggest, or even just as a module with variables) might be something to consider. Thanks for the suggestion! :)

aspidites {l Wrote}:- Lack of separation of concerns. The project_text method is concerned with rendering text in a specific font and color at a particular location on the screen. I'd have preferred more separation here [2].
...
[2] I think I'd prefer that what is being rendered and where it is being rendered be separate concepts.
{l Code}: {l Select All Code}
class Room(sge.dsp.Room):
    def event_step(self, time_passed, delta_mult):
        # of course, I'd also rather that named colors and alignments weren't strings, but that's a separate issue
        text = Text(font, "Hello, World", color=gfx.Color("black"))
        sge.game.blit(text, sge.game.width / 2, sge.game.height / 2, halign="center", valign="middle")


That method is actually possible by using the sge.gfx.Sprite.from_text method to create a sprite, and then projecting that sprite with sge.dsp.Game.project_sprite. In fact, project_text is just a shorthand for this in the Pygame SGE. The main difference from your example is that Sprite.from_text takes the alignment arguments, and uses these to define the origin of the created sprite.

aspidites {l Wrote}:- I don't know what the game class is buying me if we are always operating on the sge.game singleton. I'd expect "self.project_text" instead of "sge.game.project_text" and "game.start()" instead of "sge.game.start() (after defining "game = Game()" of course).

I'm not quite sure what you mean here. If you're questioning why the Game class exists, it's so that you can use an extended class instead of the base sge.dsp.Game class, in particular to define events. If you're questioning why the object is automatically assigned to sge.game, it's actually for the benefit of the SGE internals, so that the SGE code always knows where to find the currently active game object. Being able to reference "sge.game" instead of a "game" variable you assign is just a bonus, and not at all mandatory.
User avatar
onpon4
 
Posts: 535
Joined: 13 Mar 2014, 18:38

Re: SGE Game Engine 0.24 - Looking for feedback

Postby aspidites » 25 Mar 2016, 20:42

Thanks for the response. What I was getting at was that it was bizarre for me to have to instantiate my own Game subclass only to then refer to the universal one directly. Basically, rather than this:

{l Code}: {l Select All Code}
game = MyGame()
sge.game.start()


I'd have expected:
{l Code}: {l Select All Code}
game = MyGame()
game.start()


Alternatively, since I seem to have to be cognisant of sge.game's existence, I'd have preferred to register event handlers with it directly, nad not needed to write a subclass. Something like:

{l Code}: {l Select All Code}
@sge.game.register("event_key_press")
def key_handler(key, char):
    if key == 'escape':
        return sge.game.event_close()

sge.game.start()


I'd have used a class attribute or enum instead of a string, but you like strings. Anyway, in either case, I no longer have to think about whether I should be doing something to sge.game or my game instance. It's very clearly one or the other. I do appreciate that there are other ways to do things within the engine, which I could perhaps use to overcome some of my other complaints. Thanks for listening and best of luck continuing with the project. You've certainly accomplished a lot.
aspidites
 
Posts: 30
Joined: 19 Jan 2010, 11:49

Re: SGE Game Engine 0.24 - Looking for feedback

Postby onpon4 » 26 Mar 2016, 00:24

aspidites {l Wrote}:Thanks for the response. What I was getting at was that it was bizarre for me to have to instantiate my own Game subclass only to then refer to the universal one directly. Basically, rather than this:

{l Code}: {l Select All Code}
game = MyGame()
sge.game.start()


I'd have expected:
{l Code}: {l Select All Code}
game = MyGame()
game.start()


...

Anyway, in either case, I no longer have to think about whether I should be doing something to sge.game or my game instance. It's very clearly one or the other.

I think you may have misunderstood. In your example, "sge.game" and "game" both refer to the same object, so they are completely interchangeable.

aspidites {l Wrote}:Alternatively, since I seem to have to be cognisant of sge.game's existence, I'd have preferred to register event handlers with it directly, nad not needed to write a subclass. Something like:

{l Code}: {l Select All Code}
@sge.game.register("event_key_press")
def key_handler(key, char):
    if key == 'escape':
        return sge.game.event_close()

sge.game.start()

Yeah, that's another method I could have used, and possibly a better one. I actually considered switching to it at some point, but decided not to. I think the main reason I stuck with the singleton class is the use of properties (which allows, for example, switching to and from fullscreen mode just by setting sge.game.fullscreen to True or False).
User avatar
onpon4
 
Posts: 535
Joined: 13 Mar 2014, 18:38

Re: SGE Game Engine 0.24 - Looking for feedback

Postby enalios » 31 Mar 2016, 03:34

Hey there! I used SGE as promised! Overall, I found it to be a joy to use!

When I first started using flixel (almost 5 years ago) there was a tutorial that really helped me get going. I only half remembered it, but I tried to recreate what I remembered as the end result. Anyway, I ended up making something way more substantial. It doesn't have sound yet, but I think I'm ready to share!

Image

It's a simple side-scrolling spaceship game, enemies fly in from the right, some of them are fast and dart around, some of them shoot homing bullets, and some of them take multiple hits to take down. The game gets steadily faster as the game goes on, and more enemies spawn together, along with more that fire bullets.

Link to tar.gz of the game

The game doesn't run as *smooth* as I'd like - that may be because I'm using the zoom, or it could be because it's running on a raspberry pi.

I would have really really liked to be able to use the blending modes basically everywhere. There were some places where it was forced to be Multiply. Also it seems not every field that allows Color allows for the alpha channel to be used? I specifically remember Text not using alpha, only RGB.

I should add this to the tarball, but I'll state here that I'd like to post this as CC-BY-SA 3.0 ... is that compatible with SGE?
enalios
 
Posts: 2
Joined: 20 Mar 2016, 17:09

Re: SGE Game Engine 0.24 - Looking for feedback

Postby onpon4 » 31 Mar 2016, 04:23

The game doesn't run as *smooth* as I'd like - that may be because I'm using the zoom, or it could be because it's running on a raspberry pi.

It's because of the Raspberry Pi. The Pygame SGE is a bit more demanding of CPU power than I'd like, so low-power devices like that don't tend to have great performance with it. I hope I can solve that with an implementation that can work with PyPy.

I would have really really liked to be able to use the blending modes basically everywhere. There were some places where it was forced to be Multiply.

It's not multiply blending in most places, but thank you for pointing this out; I forgot about it. That's an incredibly simple thing to add, too.

EDIT: Done.

Also it seems not every field that allows Color allows for the alpha channel to be used? I specifically remember Text not using alpha, only RGB.

Huh, that's probably a Pygame limitation I didn't notice. I'll take a look at possibly working around that.

EDIT: Done. Using the latest SGE from Git now gives the text in your game the transparency you wanted it to have.

I should add this to the tarball, but I'll state here that I'd like to post this as CC-BY-SA 3.0 ... is that compatible with SGE?

The SGE is under the GNU LGPL, so any license is permitted as long as you do not statically link it, though I urge everyone to choose a libre license. CC BY-SA is a libre license, so I don't have any objections to it and it makes your game eligible for a listing on the "Games" page on the SGE website. That being said, it would be better to put the code (stellarStarship.py) under the GNU GPL, even if the game's art assets are under CC BY-SA. The Creative Commons licenses are not designed for software. Creative Commons explains why using Creative Commons licenses for software is a bad idea here:

https://creativecommons.org/faq/#can-i- ... o-software
User avatar
onpon4
 
Posts: 535
Joined: 13 Mar 2014, 18:38

Re: SGE Game Engine 0.24 - Looking for feedback

Postby onpon4 » 06 Apr 2016, 12:32

Alright, the release candidate for version 1.0 is out:

https://savannah.nongnu.org/forum/forum ... um_id=8505
User avatar
onpon4
 
Posts: 535
Joined: 13 Mar 2014, 18:38

Re: SGE Game Engine 0.24 - Looking for feedback

Postby aspidites » 07 Apr 2016, 03:33

Kudos on the release. I appreciate the compromise by way of the s module. The scale_method change is a nice addition driven by real usage. Great job on implementing feedback in a way that allowed you to remain true to your own style.
aspidites
 
Posts: 30
Joined: 19 Jan 2010, 11:49

Who is online

Users browsing this forum: Google [Bot] and 1 guest