Level Editor 0.3 (Dodger)

I know it’s been a while and for that I apologize the last few months have been pretty crazy around here…although I’m starting to see a trend with life in general lately, namely that it’s always crazy.

I’ve been busy with work, Python Magazine, my wife, trips to Dallas, and yes whenever I get a chance this slowly growing level editor. Let’s see what I’ve been working on for the last little while:

Name: There has a been a name for the editor ever since I started working on it. I wasn’t sure if I was going to think up something really cool and change, or leave it. Turns out I just left it.

So from this point forward this project is christened: “Dodger”, or probably more correctly: “Dodger Level Editor”.

The name has its roots in the name of one of my cats and a history in the multitudes of level editors and game engines that I have tried to create in the past, but I wont’ go into that. So Dodger it is.

Saving and Loading: Saving and loading in the default YAML project type now really works. I still need to put in support for optional project types: XML, JSON, and other formats

dodger editor welcome dialog

Welcome Dialog: This was a real pain, but it’s made the last while so much easier. I added a working (at least I hope) welcome dialog with a way to create new projects, open old ones, and a recent file list. The recent file list really makes testing easier for me.

dodger editor rect tracking

Rect tracking: Rect tracking is finally working properly. I’ve had the rect tracker in there for a while but it didn’t really do anything until now.

dodger editor multiple selection

Multiple Selection/Multiple Properties: I’ve also finally got multiple selection going, which is what makes the rect tracker actually useful. You can select multiple sprties, move them around and add properties to all of them.

Remove Properties: Now you can remove custom properties that you have added. This was a must but I was lazy and left it for a while.

Steps towards being made public: A lot of the changes (and I do mean a lot) that I’ve been making have been behind the scenes. There has been a lot of refactoring and reorganizing of the code, often the result of quick and dirty implementations that I made earlier (sigh). I’ve also started working on getting the distribution of this editor going so that other people can use/develop it.

I’ve added support for zc.Buildout so that if anyone wants to develop they can quickly gather dependencies and won’t have to install the editor system wide, not that you have to anyways but zc.Buildout is really neat.

I’ve also worked on the license (GPLv3) and setup.py and README and all of that. None of it’s done but it’s working its way forward.

Faster: It’s also much faster now. None of you have used it so you’ll probably think it’s slow, but trust me it’s much faster then it was before.

Bugs: There have been loads of bugs that have been fixed and created. Plus one doozy related to
changes made to pyglet. Not pyglets fault but it took a long time to figure out what the issue was.

Google Code: The project has a temporary homepage over at google code: http://code.google.com/p/dodger-editor/ There’s nothing there yet but over time I will start to host the project there so that people can easily download it. I’ll still post updates here until the site has a full-time home.

I’m going to use Mercurial for the revision control system for the project so the CVS support at the google code site will just be for downloading. Eventually I will want to host the project on some space of my own and get a nice web interface for the mercurial repository going. I’ll have to find a new hosting company so it will take a while.

So that’s it, that’s what’s happened to the Dodger Level Editor over the last few months. I know I promised to make it public earlier but given the shape it was in at that time there really was no point. I want this to be at a point where people can actually almost use it before I make it public.

I know it’s been a while, and I know the few of you that actually care about this project have probably moved onto bigger and better things, but hopefully if you stick with me there will be something out soon.

17 thoughts on “Level Editor 0.3 (Dodger)”

  1. Of course we are still with you =)

    Timing is good as well as I have in utmost disgust totally given up on Pygame for ever providing an installable binary for Mac at all let alone one time with each release and have thrown all my efforts into Pyglet which even at Beta 2 of version 1.1 is just impressing me more and more and all my time is now dedicated to learning the ins and outs of that game/multimedia module.


  2. Where is the code? I am working on a tile map engine, and would like to add an editor to it, however I haven’t found a good example of gui and pyglet. Yours looks great, is there anyway you could release or email me the code?


  3. Hi Python Nutter, well I’m glad that some people are still around! I should remember to keep my mouth shut regarding deadlines!

    For me there was nothing wrong with PyGame, it was just that pyglet seemed to be getting a little bit more love. I also think that it should be easier to get better FPS using pyglet.

  4. Hi Kevin,

    Right now there is no code available. As I mentioned in the post I’m still cleaning up a few things before I fully make it available to the public.

    Hopefully it will be available soon.

  5. Pygame / pyglet performance.

    I agree pyglet gives better performance.

    I have converted Pygame programs to pyglet and seen CPU utilisation drops all the way down to buggar all (18%) on an old PPC G4 Mac with pyglet.

    I am using the 1.1 Beta framework as it has very efficient handling of Sprites and a very efficient timing loop built in.

    That, combined with no Pygame love anymore for Mac users, it was easy to dump Pygame and not look back.

    If you need some 1.1 pointers, let me know, or I’ll give you an example to run and compare, Pygamepyglet.


  6. I see, but I was hoping to see how you implemented your gui with pyglet.

    Thanks anyhow,

  7. Wow, I’ve written lot’s of things for my first comment but my computer was reseted.
    i’ll return soon, and i sent this comment to say you i’m reviewing all your site.

  8. Hey selsine!
    Nice work! Your blog helped me a lot learning pygtk! I’m developing an application witch uses some databases, so I have the idea of using a “loading screen” before showing the main application. This “load screen” would show the name of the database being loaded an some messages, than it closes and the main application appear.
    I’ve builted everything, the screens, the code to load the data… But I just can’t put this damn “loading screen” to work! I just can’t find where to place the loading code! and I can’t close the “loading screen” with a command in python. It closes only when I press the close button.
    I thougth that you could make a tutorial about it!

    Thanks for any help!

  9. Hi again,
    I want to learn game programming with python and before this i try making some games with some engines like 3dGame Studio,Game Maker, TGB and TGE and … .
    But i want to use libraries like OpenGL and … . and i found Python and pygame more easy to learn and work.
    I’m really happy that i found you and your blog! Because now i can ask you to help me anything i couldn’t understand. 😉


  10. Again Hi,
    I’m looking forward to upload your project in Google Code…
    But i don’t think that you user PyGame in it,do you?
    I really want to learn game programming with python and i’ll be glad if you say me some good sites, books and sources!
    by the way, your Doger level editor has a very friendly interface.
    please continue your PyGame tutorials.

  11. Hi Magnun,

    Thanks for the kind words. As far as a loading screen goes you should look at making the loading screen a modless dialog, and then load your information while it’s up. Then when you are done loading close the dialog.

    I’ve never done it in PyGTK but have in other languages so hopefully that helps.

  12. HI Mostafa,

    THanks, the Dodger level editor is a level editor written in PyGTK and PyGlet. However the files that it creates could be used by any game regardless of what technology they use.

    Hopefully there will be something up soon. I’m just getting the setup.py working.

  13. Hi selsine, awesome work! I’m trying get a crew to develop a GUI to create 2D RPG Python Games, like RPG Maker, but for GNU/Linux and Open Source.

    I think your project would be great and helpful for the community, i will keep i eye on your Google Code page for updates.

    Thanks for share knowledge friend. It just great.

  14. I found this while browsing sourceforge and I thought of your project. It also appears to be 2d game development system though based on the popcap games framework.


    I didn’t do more than read the main page but was curious if you had seen it?

    thanks for all your work.

  15. Hi Kernel_script,

    Thanks I’m glad you’re interested in this project. Hopefully it will be available for people to use and test soon. Sheesh life can get so busy sometimes. If Dodger keeps going it will be GPLv3 so you should be able to use it with your project as well.

  16. Hi Kyle,

    No I hadn’t heard of that before. I’ve seen the Popcap game engine before and the python bindings for it (never tried it) but it does look quite interesting. I think I’ll take it for a spin when I get a chance. Thanks for the information.

Leave a Reply

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