Forums

python

Category: game engine

So here it is the initial release of the Dodger Editor. You can download the source from the google code page. Originally I wanted to wait longer to release the first version, but as time went on and it kept taking longer and longer I realized that if I didn’t release the first version at some point in time I might never release it.

If I had gotten done everything that I wanted to get done then I would be releasing the full first version of the project instead of this incredibly alpha release. So if something doesn’t work don’t be surprised. That being said you should be able to use it for it’s basic functionality. Or at least that’s what I’m hoping.

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

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.

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.

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.

Sorry I’ve been away for a bit, work and trips and writing for Python Magazine had me pretty busy and I wasn’t able to reply to everyone’s comments on the simple Python game engine. I really do appreciate the comments though so please keep them coming.

I have been thinking about the simple game engine quite a bit though and wondering where to start on it all, and whether or not it makes sense to start on it at all! After some thinking I decided that what I would want most (for a variety of reasons) would be an easy to use level editor. So with a day off from work and life yesterday I started to do some hacking with PyGTK and pyglet to see if I couldn’t get a simple level editor going.

The results are still quite crude, but the basics are starting to get in there:

As you can see it’s a PyGTK application with an OpenGL window that displays pyglet sprites. There is a properties list, where you can add and edit properties or the sprite. There is also a “content” list that displays all of the graphics in your project’s “content” directory. Then you can add any of those images to your level. You can also select sprites and move them around, or edit their properties (notice the monster with the yellow border around it?).

The idea is that eventually this will save the information out into a human readable file type (yaml, xml, whatever) that games (your game?) will then read in for their levels. The properties will be saved with each sprite and then applied when you load the level. That way you can add specific properties to specific sprites.

This is still very much a work in progress, but when it gets a little bit more stable and if people are interested I think I’ll create a project on sourceforge or google code so the other people can start working with it or hacking it.

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….