[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Game Maker but with Python?





On Wed, Oct 1, 2008 at 6:12 PM, Nathan Whitehead <nwhitehe@xxxxxxxxx> wrote:
I just saw "100 Game Maker Games", a cool 10 minute video that shows
the wide variety of cool games you can make with Game Maker.

http://playthisthing.com/100-game-maker-games

There should be something like this but with Python and pygame!

My friends at UCSC have taught intro programming using Game Maker, and
it went well but they were ultimately unhappy with GML (the Game Maker
scripting language) as a first programming language.  When I taught
game programming I went straight for pygame and Python (of course).
It worked out pretty well, but the students had to spend quite a bit
of time figuring out programming concepts before they could even get a
square moving around on the screen.
Yes, using pygame as a backend certainly would take plenty of time before people new to progamation could do something. But what about a very restricted engine, based in pygame ? Pygame not exposed at all. Call it mrgame, and use python + mrgame at start of the course. Let me sketch a little this mrgame:
Target games: one screen arcade-like levels, fixed resolution 800x600, up- to16 same size actors, up-to 16 bullets. Terrain. 16 Stock sfx. Can play music. controllers1 and 2.
Terrain:
    based on 1 .png file for backgrounds, 1 .map.png file given solid-air info
    The student only inits it by providing a fname.
Actors:
       mrgame knows up-to 16 actors, equal sized  at 32x32
       Typical use is player, monsters, pickables, triggers, patrol points
       Visible primary attributes for actors:
             name,heading, centerpos, vel, visuals, flag_visible.
             Note: visuals is 64x32 .png , two cell animation, heading W. mrgame derives the remaining visuals N,S,E , and handles internally the loading.
        Actors Functionality:
             autoupdates centerpos
             autoupdates the [internal] image from heading and visuals. 
             .spawn()
             .can_move(direction) [ this internally uses terrain ]
             .touches_actor(other_actor_name) # the hull is a fixed rect ,say 30x30, centered at centerpos
             .touches_bullet()
             .die()
Bullets:
        mrgame knows up-to 16 bullets, wich really are like actors but small size, say 8x8
        The visual can be a fixed ball, harcoded in mrgame.
        Bullets Functionality:
        .spawn()
        .time_to_live()
        .die_on()
        .autobounce() # terrain interaction
        autoupdates centerpos ,
Controllers:
       a suitable( meaning no frills, no options) proxy for player input.
Now, the code for this engine seems doable. At the very first can be exposed with a functional style API :you use python, but calls to mrgame dont even  need to know about classes.
Example program writen to the functional API:
from mrgame_f import *
spawn_level('pacmano')
player = spawn_actor('player',...)
badguy = spawn_actor('badguy',...)
exit = spawn_actor('exit',...)
while 1:
   if touch( player, exit):
       # you win
   if touch( player, badguy):
      # game over !
...  
When the group manages classes, you can show the underlaying, more pythonic
API based on a few classes: level, actor, bullet.
Do some game using the class API, but not digging into the engine.
If justifiable from an educational POV, in paralel a small subset of pygame can be taught, aiming to later do small customizations on the mrgame functionallity. 
... 
 
Would you use a graphical tool like Game Maker to make your games if
it used pygame and was extensible using Python?  Why or why not?  What
would such a tool have to do to be useful?
--
Nathan

You are talking about a RAD for games. Basically, a flexible RAD for games is probably imposible: You must limit the flexibility, or the API will go really barroque, unusable. Or, you restrict heavily the flexibility, and come with something usable in this small scope.

The last can be wortwhile, if its scope coincides with what you want to write, but if you need to learn other languaje, is less appealing.

So, would I use...?

If the script language is not python, near sure no. 

If the script language is python, and have interesting high level features, and there is a

clear, appealling API to use them , probably yes. But this looks more like a high level library built on top of pygame (or pyglet), maybe with alternative APIs for simple works.

Interesting theme you has throw, Nathan.

--

claxo