More thoughts on the simple Python Game Engine

After my last post and receiving a few helpful responses I thought I would make a post outlining some of my thoughts and ideas on what I meant and what I envision the game engine would do. Please note that these are simply some more rough ideas and brainstorming, it’s not meant to be exhaustive or to appear to be too thought out.

What I would like to see in this magical engine (in no particular order):

  • Level Editor/Sprite Editor – I think that this is really important. If the goal is to make creating 2d games very quickly and easily an editor is a must in my opinion. I see this as being the place where you can both position level items as well as perform some scripting. The question is whether this should be written using the actual engine, or with another toolkit?
  • Widgets – I would like to see some sort of a widget toolkit. Here’s where engines start to get large and I start to get worried. But I think that this is important, especially if the level editor were to be written in the engine itself. This would allow people to use menus, scrollbars, buttons, checkboxes, radiobuttons, and so on. This would also have to be theme-able, so that people could easily change the look and feel of their games.
  • Physics – Some sort of physics engine, probably use an existing technology, or a very simple implementation written in pure python.
  • Easy distribution for the final product – I also see this as being important. It has to be easy for people to wrap up their finished product and distribute it.
  • Cross-platform – Goes without saying.
  • Component based – Not sure about this one, but I really like the theory behind it. This would mean that the engine itself would be made up of components. Components that could be intermingled and switch. So one component would be the physics engine, and if someone wanted to use a different physics engine they would simply swap out the old physics engine with the new one. This would also (hopefully) work with with the idea of having say a side scrolling engine, and a isometric engine, these would simply be different components in the over all engine. Is this possible? I’m not sure.
  • Easy to use – Very important, it should be easy for new users to work with, but also allow for more experienced users to make complex and complicated games. Meaning that it shouldn’t stand in peoples way.
  • Standard human-readable level/file type – Be this xml, lxml, yaml, ini files or whatever. This would allow people to create other level editors, or design levels without the actual level editor.

So those are some ideas that I have, some from other “engines” that I have started in the past, and some just from thinking about it. When I go back and re-read the list I start to get the feeling that maybe it’s too ambitious. I mean a widget toolkit that is theme-able? That’s a lot to do. But that could also be something that is done at a later date. The engine does not need to be done in the actual editor. It could be done in a toolkit like PyGTK or PyQT4 to start and then an additional editor could be added on later.

Of course real life and time always play a role in completing anything as large as this…so who knows maybe I’m simply talking aloud, or maybe this is something that would help the Python game community? Just thinking….

22 thoughts on “More thoughts on the simple Python Game Engine”

  1. Hi again,
    i think that by now you differ slightly from what i had in mind.
    When i read your above post i get the notion that you try to create a new “pgu+ocempGUI” system.
    I am not sure if that is “enough”.
    I think that one could utilize some systems that are already there and the really important task would be to “integrate” them into something new.
    This would also correspond to your “component” idea.
    But in the end i think what would suit people is a complete framework that handles much of the game logic (grouped per game type) and is configurable.
    I think “programming” your game would be ok for the more experienced people only.

    Let me pick some of your points:
    * Level Editor/Sprite Editor – I think that this is really important.
    It definetly is !
    But i think there is no need for a complete leveleditor as long as you have a simple human readable format that can be output by solutions already there. So we would provide plugins for some good editors. Spares the project a lot of work and lets it concentrate on the engine/framework itself rather than programming a new tool.

    * Widgets – I would like to see some sort of a widget toolkit. Here’s where engines start to get large and I start to get worried.
    Thats why i would rather try to define a pluginarchitecture and add the apropriate interfaces to GUI solutions that already exist.
    It would allow for different gui systems and perhaps those that already developed one would offer support here.

    * Physics – Some sort of physics engine,
    Same as above. Provide interfaces and either implement something or add existing solutions by impolementing adapters

    * Easy distribution for the final product – I also see this as being important.
    I agree totally here. This is a must have

    * Component based
    See what i wrote above. I would think it makes the whole project far easier if the framework would define interfaces and one could adapt existing solutions to these interfaces or implement new solutions. In the best case the momentum of the idea could bring different projects together and decrease the workload for those defining the engine itself
    * Easy to use – Very important,
    This is what i miss in your list/idea above.
    From what i gather i don’t see how it becomes really easier to make a game. In the end i fear there still would be manual programming. I think especially for the new people we should provide some “gametemplates” that include a running system and only need to be filled with content and configured concerning some parameters (gravity, speed etc.)

    * Standard human-readable level/file type
    Definetly yes

  2. Took a look at PGU for isometric ideas, unfortunately its Alpha quality code for hex/iso. Last update to PGU was a year ago (is it still actively developed?)

  3. Yes I would say so. Actually PGU is not being actively developed, but you can use the existing isometric code in your own library / game engine according to Phil.


    I’m not actually working on pgu at all right now .. but if you want to grab the isometric code and try to make your own lib with that bit, feel free 🙂


  4. Kerim – I’m not looking to create a “pgu+ocempGUI” system, but I’m also not looking at creating a “game builder”. I’m looking for something basically in between those two solutions. There will always have to be code done by the game creator, I want to make it possible to use the engine in anyway that the creator wants at the end of the day.

    But I still want ease of use to be there for beginners. So depending on how it’s structured there might be something like a Side-Scrolling component (or screen or rendered or whatever) that will provide the basic functionality for a side scrolling game. Same goes for an isometric game.

    As far as things like that Physics go, I didn’t meant to suggest that I would be writing my own solutions, but that I would make it possible to “plug” different solutions in.

    I’m still thinking about this, and my come up with something a little bit more formal when I get a spare moment. But I thank you for your ideas and comments! Keep em comming!

  5. Patrick – Thanks for the information, I’ve used PGU in the past, and it’s something that I will probably look at for ideas. Too bad he’s not working on it anymore.

  6. Selsine,
    first of all i fully agree that in many cases (actually in most especially at the beginning of such a project) games would still have to be coded.
    In my view it would even be futile to create an engine/framework that prohibits coding. You can’t configure everything.
    What i meant was perhaps closer to your idea than we both thought.
    My idea would be to create something built on top or utilizing different sorts of functionality and providing a system or interface to code either games or even game generators.
    So for me this “in between” is not a problem. I simply assume that if the system is good enough then people will eventually also build kind of templates (you mentioned a side scroller) that others can use for their games.
    And IF (thats actually more a question i ask myself than a statement) certain games have much in common (depending on their type), then it should be possible to actually archive a state where you do not code a game completely but configure it. At least for sidescrollers or platform games i think this could be possible.

    But of course the start would be a framework that simplyfies only and provides you with easy to use interfaces and certain default behaviours.

  7. I think I set my bar a bit lower with what I thought about.

    My idea was more along the lines of
    “OK, I want to create a game, so I just need to import basic classes which provide simplifications (for the game type) on pyglet, and then I can start the creative part.”

    I thought about what a game engine needs, because I didn’t want to have to refactor too much after suddenly realizing, that the structure I created can’t support some feature I forgot.

    I for myself would see a first version of the game engine as useful as soon as a game dev can either modify an example which uses the lib, or using the lib would be as easy as typing:

    # import the necessary parts.
    from babglet import SidescrollerScene, Being

    # create the protagonist.
    protagonist = Being(image_src=”protagonist.png”)

    # create the scene with the protagonist.
    scene = SidescrollerScene(protagonist=protagonist, bg_image_src=”background.png”, level=”levelfile.yml”)

    # Start the event_loop.

    This would allow non-programmers to create games very easily, since only a few files would have to be modified, and if the lib provides sensible defaults, the game could also look good instantly.

  8. A question that i ask myself currently:
    Any engine that one would implement would have to depend on something else. In the end some c(++) library like sdl, allegro etc.
    As far as i know there exist more or less 2 solutions in python at the moment
    -pygame uses sdl OR opengl
    -pyglet uses opengl.
    -pyallegro seems not really up to date

    With pygame one has to decide rather early if he uses opengl and forgets about most methods then or uses normal sdl and thus forgets about certain graphic features and performance.
    with pyglet you have opengl but in my view still too much hardcoding of gl commands.

    My question would which one of those apis and which technology (opengl, sdl) one would use as a start OR if one would better create a new binding to some existing 2d c++ engine that allows more general use of underlaying technology (mor abstraction of the graphic layer for example).
    I think any engine would have to be implemented on top of that.

  9. I use pyglet for my own games, because i can just bundle it with my game and put it out without requiring any installation from the user.

    A MacUsing friend of mine can put the game into a Mac Program with a few clicks, then, and the game looks just like any regular Mac App.

    Using Pyglet worked very nicely for me (I only use 2D graphics, OpenGL only for transparency – two lines inside my library, and I didn’t have to touch OpenGL since).

    Its only disadvantage is, that it is kinda slow.

  10. I am more on the line with Arne, besides that i kept my requirements to the basics. I set some milestones and just started coding and see what will come out. One of my main goals is that each “milestone” will produce a clean and working code set that others can use too.

    @Arne: Pyglet is only slow if you dont use OpenGL. I made a tile mapping test with the highlevel blit of theirs and the performance sucked. The tile mapping part of Spryte (in contribs) used opengl all the way and it was pretty quick, 5 times my fps….
    IMHO Pyglet does only make sense if your using opengl.

    @Kerim: I guess there are none to millions of 2d c++ engines out there and i bet they are pretty much only rendering engines and miles a way from a game engine , even on the lowest levels we agree here. Neither i think they are faster. I’d go with a python solution.

  11. hi
    interesting post, i would also be interested in a python game engine.
    you are right that almost all engines out there are only rendering engines, most of them are written in C++. its sad that there is no really good 2d game engine at all.

    a nice clean _game_ engine in python for 2d games would be really nice.
    i’d like to see a good and clean network design, use of opengl & nvidia cgfx for high level shader effects and good integration with physics (maybe PhysiX would be nice, its good + free, or Bullet) game network graphics.

    it can be very hard to combine all those together with a clean design.
    just my 2 cents.

  12. So far, no python game engine has convinced me. My idea of the engine should be something like flash, but more powerful.

    By flash-like, I mean that you are not constrained to a single type of game, you have a canvas, and you have all the essentials (keyboard detection, drawing, effects, animations) and then add all the other things as modules depending on the programmer’s need (physics, side-scrolling, collision).

    That would turn into a more modular, lightweight layer.

    Good luck.

  13. @Azarai: I don’t yet use much OpenGL stuff, since my X-server breaks on many OpenGL tests.

    I hope using the Sprite class will provide the speedup I need.

    What i really like about pyglet is that i can just deliver it with my game without bothering to compile for different platforms (or forcing people to install anything beside my game).

    I do want to stick with pure Python, more so since I just had to fix something inside pyglet and found out, that I could just do it – and that’s a very nice feeling 🙂 .

    I’ll slowly work onwards, but if you want to join in (or get inspiration), you’re invited to have a look at the code or just talk via mail or chat, or in here or at any suitable place.

    – mercurial:
    -> file in question:
    – svn:

    jabber: drak ät
    mail contact:

    A forum would be avaible at

    But we can also easily use an existing python forum, if you can give me a pointer 🙂 .

  14. Sorry Arne, your post got flagged as spam accidentally I was just cleaning house and I saw it so I pushed it through. Sorry it took so long to show up.

  15. Don’t know if it’s what you had in mind, but I’ve always loved an engine called Game Maker ( It has a very nice GUI that allows you to easily add sprites, create levels, objects, etc. It also has it’s own programming language where you can use scripts rather than its beginner-drag-and-drop interface. The library has just about every feature a game engine would need (simple networking library, friction, gravity, joystick, etc.) I would love to see this exact thing designed but using Python stuff. Game Maker is Window only right now, and the built-in language will only help you get a basic idea of how other real programming languages are. If we could script in Python, and still retain all the easy creating tools, that would be awesome.

  16. Hi Brian,

    Thanks for the post. Right now a gamemaker-like tool is not exactly what I am going for, I’m currently concentrating on the level editor pretty specifically. However I see the level editor being part of a whole toolset.

    So, perhaps there will be the level editor for those that simply want to design their levels. And then maybe there will be a configurable runtime that those who want a move gamemaker like tool will plug their level into.

    I’m not sure if this is going to be the way that it develops, but I think that there is a possibility that it may go that way. I’m concentrating on the level editor now since I see it as a nice separate starting block.

    You can checkout some of my other posts on the level editor to see what I mean.

  17. Hi, i’m really interested! I would like to see a Python Game Engine too, but unfortunely i’m not a programer, but i can help with Sprites, i draw on GIMP and Inkscape, and, i can help with documentation and administrative tasks too, don’t know if i can be useful for your project, but would like to shot some links and ideias:

    Maybe it can help in some way, look what i found on Python site:

    I’m a GNU/Linux user, so can give you some info help if you wanna port your project.

    Thanks for the attention, keep going with the project!
    Sorry for my English, it’s not my native language.

    See ya.

  18. Hi kernel_script,

    Thanks for the reply sorry it took me so long to get back to you. I’ve been away on holidays and extreemly busy.

    The project will be open source so if you want to help out in anyways that would be fantastic. Once I get the level editor code up there, feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *