Entry skeleton "skellington" simplified (version 1.9)

richard on 2011/08/16 00:07
— edited on 2011/09/06 00:57

Last comp I switched to a newer, more complex, user-supplied skellington. I recall some people had issues with it. Please let me know what those were and I'll try to update it before the next comp.

The more complex entry skellington from last comp (2.3) caused enough headaches that I've rolled back to the much simpler 1.9 version. This is the one now linked from the rules and help pages.

(log in to comment)

Comments

superjoe on 2011/08/16 03:56:

http://www.pyweek.org/d/3661/
http://www.pyweek.org/d/3914/
http://www.pyweek.org/d/1691/#comment-3524

Mat on 2011/08/21 11:44:

I think the main problem last year was there was a lot of things which were only useful if you used the same tools/coding style as the author (which most people didn't). It doesn't really bother me that much as I can just fork one of my previous entries, but I think it can be offputting to newcomers if things are too complicated.

IMO, the essential things the skellington needs to provide are:
  • an upload script
  • run_game.py so every (source) entry can be run the same way
  • README/LICENSE files
Last year also had a build script for py2exe and similar tools which was a good idea, but I didn't end up actually using it. It was also confusingly named setup.py.

Someone trying to run someone else's game for the first time has the following options:
  • configure/make
  • setup.py
  • main.py
  • run_game.py
This is just too confusing.

Ideally what I'd prefer is a simple configure.py script with an interactive cli that walked you through setting up your team name, entry name, license etc. and then let you choose which bells and whistles you want it to add for you. If there is extra stuff that will be included in the entry it should be named appropriately so users know what it's for.

adrwen on 2011/08/21 21:34:

There is a risk that the more features the Skellington package gets, the more we will see of:

    1. Teams not using it (due to it being seen as intrusive and buggy)
    2. Bugs being introduced into it

superjoe on 2011/08/22 01:45:

I agree with Mat about only having one way to run the game - configure/make, setup, and run_game; these are too many options. I brought this up last time but Richard didn't agree with me.

Mat on 2011/08/22 08:48:

I put my starting point for last year up at github https://github.com/mwehtam/pyweek-skellington

I don't know if it will be useful to anyone else but figured I should probably let you all know so I'm not breaking any rules by reusing it :) 

I'm also thinking of creating a version specifically for pygame with some basic architecture & event handling already in place (something like this http://ezide.com/games/writing-games.html). Would this be allowed if I publish it here?

superjoe on 2011/08/22 21:19:

Mat, my only complaint about your skelington on github is that your build.py has hardcoded stuff that has to be changed. Would be nice if there was a single point (a setup script?) that put the right values everywhere.

Mat on 2011/08/22 21:36:

I can fix that if you like, it was originally generated from a template in the official one.

Adrwen, I agree, I think we should we be conservative in what we add to the official version, and avoid making changes to it close to the challenge date. Although we could always have a "beta" version as well :)



 

john on 2011/08/23 16:57:

For me the pyweek 4 skeleton was the best simply because of its simplicity. I don't need half the stuff provided in the skeleton.

richard on 2011/08/25 04:07:

OK, so maybe I should just revert to the simpler skellington and try to address the issues people had with it.

People could then post recipes for turning a skellington game into an exe or android app or whatever...

What were the issues with the old one?

Mat on 2011/08/27 18:08:

Over the last few days I've been working a bit on mine (linked above), adding boilerplate code for stuff like logging, reading configuration files - things that normally I would want but don't want to spend much time on. Now that this is in place it should be easy to remove all the hardcoded stuff and add a setup script. I'll update you all some more when it's actually usable though :)

Richard, I wouldn't want to abandon the new stuff completely. Maybe you could use the simpler one as the recommended option but still link to the other version?

I'd certainly appreciate more documentation on building executables and common problems though - I don't think I've ever managed to get py2exe working successfully. I'm sure there's enough information out there, but collecting it together (or recommending an existing resource) would be quite helpful.

saluk on 2011/08/29 20:51:

Anyone who wants can use my pywright base code. It has the benefit in not needed to generate an exe at all, the exe is preloaded with pygame, numpy etc and will run any code put in the 'core' directory. It's not really a true skellington, but it's another option while we are listing them :)

http://pygame.org/project-pwbc+-+saluk%27s+base+code-1992-3513.html

Mat on 2011/09/04 10:07:

Yeah I gave up on the setup script with py2exe and have removed it for now. Couldn't get it to work on a simple game with pygame mixer enabled, so I don't think it's going to be useful to many people.

My advice to anyone wanting to build executables is to decide in advance what modules you will need and spend some time before the challenge writing your own setup script that will support them.
http://pygame.org/wiki/Pygame2exe may be helpful if you are using pygame.

For those interested, my skellington has two branches.
 
The main branch is a very simple skellington:
  • run_game.py to run the game
  • basic organisation of source and data, leaving the main directory uncluttered
  • README file
  • Config file which can be used for any constants, key mappings, etc
  • Logging using the python logging module. Running with --debug changes the log level to debug.
  • Utility functions for loading resources from the right place
https://github.com/mwehtam/pyweek-skellington
git clone git@github.com:mwehtam/pyweek-skellington.git
  

The pygame branch is an example game I made in pygame, with the aim of working out a decent architecture I can build on in the next pyweek. It's not as useful as a starting point, but it may be of interest to people thinking of using pygame. See also: http://ezide.com/games/writing-games.html

In addition to the above, it implements:
  • MVC structure based around pygame events
  • Switching between multiple game screens
  • Annoying music
  • Ducks
https://github.com/mwehtam/pyweek-skellington/tree/pygame
git clone git@github.com:mwehtam/pyweek-skellington.git
git checkout pygame

Any comments or suggestions are welcome :)

richard on 2011/09/06 00:56:

I've reverted to using the older, simpler skellington from previous comps rather than the newer much more complex one. Version 1.9 it is!