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")