Back from Holidays

August 18th, 2008

Sorry about the lack of updates and responses here everyone. I’ve been away on holidays so I haven’t had any time to access this blog or work on the level editor at all. I’m going to try to get the code up as soon as possible so that anyone interested can start playing with it and hopefully fix all of my mistakes.

Thanks for you patience everyone, I’ll be back with more soon!


Level Editor 0.3 (Dodger)

June 22nd, 2008

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.


Operator Overload! Learn how to change the behavior of equality operators.

June 21st, 2008

By: Mark Mruss

Note: This article was first published the November 2007 issue of Python Magazine

While the equality operator works great on numbers and strings the fact the way it treats your custom objects really is not that useful. This article looks into overloading the equality operator so that you can easily compare your custom classes.

  1. Introduction
  2. Introducing the terms: operators and operator overloading
  3. A Quick Example of the Default Equality Operator
  4. Overloading the Equality Operator
  5. Telling Python that the Comparison has Not Been Implemented
  6. The Inequality Operator
  7. Dangers
  8. Conclusion

Read the rest of this entry »

Possible hackage

May 30th, 2008

Note: The blog was hacked. I spent all night trying to clean it up. If you have registered here you may think about changing your password. Sorry about this folks it pretty much sucks.

Hey everyone,

Just to let you know there is a strong possibility that this blog was hacked recently. A helpful user (Eoin) informed me that when trying to visit the blog from Google he was re-directed to an advertising website.

In response I’ve updated the blog and tried my best to ensure that anything that was hacked is back to normal.

If anyone noticed anything strange happening on this blog please let me know.

Thanks.

Fraking hackers…

Elegant XML parsing using the ElementTree Module

May 7th, 2008

Mark Mruss

Note: This article was first published the October 2007 issue of Python Magazine

XML is everywhere. It seems you can’t do much these days unless you utilize XML in one way or another. Fortunately, Python developers have a new tool in our standard arsenal: the ElementTree module. This article aims to introduce you to reading, writing, saving, and loading XML using the ElementTree module.

  1. Introduction
  2. Reading XML data
  3. Listing 1
  4. Listing 2
  5. Reading XML Attributes
  6. Writing XML
  7. Listing 3
  8. Writing XML Attributes
  9. Reading XML Files
  10. Writing XML Data to a File
  11. Reading from the Web
  12. Conclusion

Read the rest of this entry »

Level Editor 0.2

April 1st, 2008

So I had some free time since I last posted so I hacked a little bit more into my simple game editor. I’ve a few things in there that I wanted to get in:

  • A grid
  • A paint mode to easily add sprites
  • An erase mode so that sprites can be removed
  • Fully (or so it seems) working property addition to the sprites
  • Added some organization to the code. I was hacking on this enough that putting things in their right spot started to make more and more sense.
  • Started to use mercurial to keep track of source changes. I know how important version control is, and after making a silly mistake I decided that I wanted to start using it with this project.

You can take a look at how things are working here:

Python Game pyglet editor

It’s not pretty yet, but it’s coming along.

Pyglet Level Editor

March 22nd, 2008

Hey Everyone,

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:

Python Game pyglet editor

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.

So…ideas? Comments? Thoughts?

More thoughts on the simple Python Game Engine

February 24th, 2008

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

A Simple Python Game Engine?

February 21st, 2008

Is there anyone else out there that is looking for this? A simple Python (2D) game engine? I’m not talking about something like PyGame, PyGlet, or Rabbyt, all of which are very good at what they do. What I’m talking about may use these technologies (I’m thinking PyGlet and Rabbyt) but would do so in a way to create an actual “game engine”.

This is something that I have tried to do many times in the past, and I’ve always gotten stuck on the idea of trying to make it very very flexible, so that you could use whichever technology with the engine that you wanted to. But lately I’ve been thinking of a different approach. What about a very specific engine? Something that is very geared to performing one task well. Lets say a 2D scrolling engine. Something with a set level format, easy save and load, a screen system, and maybe some widgets.

Basically I’m thinking of something that will let people who are interested in creating simple games do so very easily. Something that isn’t that doesn’t necessarily do everything, but if you follow some simply steps you can get a “game” going very quickly.

Anyone else interested in something like this? Anyone else interested in working with me on something like this? Or perhaps you have information on a technology that is already there? Or maybe you have information on simple game engine design? I’ve feeling the itch to create some games again using Python, but I havn’t yet found the tool to scratch that itch…maybe the solution is to create on? If you are interested, or have some information, drop me a comment or shoot me an email.

mark…signing off after a long day on the computer not programming Python or video games, and definitely not doing it for himself.

Thanks for the great ideas

February 13th, 2008

I’d like to thank everyone that commented on my last post, and everyone that has emailed me ideas. They are all very much appreciated. It’s hard keeping up with everything that is happening in the Python world, and sometimes the coolest things are happening in far off places.

I got a few suggestions for Pycairo, which is something that I have considered in the past, but I’ve found it a little bit difficult and time consuming do to the lack of Python specific documentation.

The MDP toolbox also looks pretty cool, I just have no idea what I could possibly do with it!

If anyone else has anymore ideas please let me have them. Anything graphical, non-graphical, game related, swarm theory, random generation, AI, a Rorschach test creator…anything! I’m collecting ideas for this blog and my monthly column so anything that would also really interest new Python programmers would be a huge plus.

Take care and get ready for 3000!