ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> pygame-users
pygame-users
[pygame] Level editing thoughts
by James Hofmann other posts by this author
Aug 21 2006 11:24PM messages near this date
Re: [pygame] pypy? | Re: [pygame] Level editing thoughts
I've been thinking about how I could build an "above-average" level editor,
something that goes beyond tilemap drawing or placing a bunch of objects at
various coordinates and dictating their behavior through property lists.

I decided that in-game hooks to the editor would be the most interesting
option, primarily for sequences where you want a timed script of events such as
in-game cutscenes, "patrolling" actors, etc.: You could press a record button
while playing, walk around a little, press a second button to denote some
non-movement event(talking, shooting, etc.), and then when you're done with
your recording, the data would be instantly included in the editor in a format
that could be easily tweaked, such as a system of waypoints.

To do the "instant" part means some interface between game and editor has to
occur. The way I'm planning on implementing this cleanly is to use a namespace.
A paradigm I already use frequently is to make a file "glo.py" containing one
or more empty class declarations, and in every other project file include
"import * from glo" so that the classes function globally.

Perhaps even better is that in this case, I can do more with the class than
leave it empty; the editor data will need to be saved and loaded and that
functionality can become a method....so that the game, when instructed to do
so, may load the current editor data, manipulate it, and save it - and the
"play" process could remain seperate from the "edit" process while
synchronizing the pertinent data. Having this interface present means that I
could make "in-game tools" for "in-game content" and leave the static parts
like drawing the scene and assigning properties in the static mode, in the
editor.

It seems like a really simple idea now, yet so few games try to do something
like this with their editing tools. They always make you do everything within
the editor, with the "test" mode only for testing. I wonder why that is?

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
Thread:
James Hofmann
Shandy Brown
Andrew Baker
Patrick Mullen
Greg Ewing

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved