On Wed, Oct 1, 2008 at 6:12 PM, Nathan Whitehead <[EMAIL PROTECTED]> 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
