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

Re: [pygame] Working on Retro 80s Game SDK, Looking for general support



On piece of advice I have is to create actual games with the system as early as possible, especially before the apis and features have completely solidified. It's very helpful to point out awkward or missing parts of the system.

-Casey

On Jan 6, 2009, at 4:23 PM, The Music Guy wrote:

Hello all,

There are two purposes to this message:
1.) To test my recent subscription to the Pygame mailing list, and
2.) To announce that I am working on a game SDK that is similar (in
some ways) to Pgu.

My SDK is called "Scrollback," abbreviated "sbak". At the moment, my
it is still just a library and is about 70% through the alpha stages.
It's developed enough that one could make some relatively simple games
with it, but very little of the API is actually nailed down yet.
(That's one of the things I am posting about.)

The main goals of my SDK are, in order of importance:

  1. To be an all-in-one 8- and 16-bit era game SDK.
  2. To remain as OS-independent as possible.
  3. To be easy for people with little or no experience making games
to get a quick start.
  4. To be easy for beginning and novice programmers to begin using.
  5. To take advantage of the Python programming language.
  6. To rely on as few external libraries as possible, even if it
means including 3rd-party libraries with the main package
distribution.

As you can see, the main theme for my SDK is availablility rather than
speed, as in many other game SDKs.

Some of the ideas of Scrollback are inspired by Game Maker, though
Scrollback is far from being a GM clone. I once had a near-guru level
of experience with GM, but since switching exclusively to Linux, GM is
no longer much of an option. I hear a lot of people have this problem,
including Mac users, so I decided to try and do something about it.
While I was at it, I decided to add some features to the mix which I
have felt GM has always needed.

Though I was good with GM, I'm not generally a very good programmer,
and I'm going to need a lot of help, otherwise I could see this
project taking decades to complete by myself. Incidentally, I've been
trying to start projects like this off and on for the last few years,
but kept having to start over. Now it seems I'm finally getting
somewhere, and I don't want to have to start over again.

I'm going through some issues with my web host right now (trying to
get mod_wsgi activated) otherwise I would have a wiki up with as much
information about this project as I have. Until I can start the wiki,
here are some of the most prominent features planned, subject to
change at any time:

Features which are presently implemented either in part or in full:

* "Images", basically a kind of object which can be drawn to a
surface, but has a built-in offset that is applied every draw.
* "Composites", which are clusters of Images that are drawn together
as a stack of layers.
* "Animations", which are clusters of Images that are each drawn
separately at different times as "frames", where each frame may be
displayed for a varying length of time.
* "Worlds", which are basically planes that contain tile maps and
"entities"
* "Entities" are the physical objects which interact with each other.
These would be things like the player, enemies, projectiles, item
pickups, doors, etc.
* "Cameras" that can view worlds and follow particular entities
* Parallaxed backgrounds (buggy at present, but usable)
* "Tile maps" are basically grids of numbers which refer to "tile"
descriptions in "tile lists"
* Collision detection between entities and between entities and tile
maps.
* A "tile list" is what most would describe as a "tileset", but may
use Images, Composites, or Animations as the visual component of
tiles. Additionally, each tile has user-defined data added to them,
including groups that the tiles may be added to and attribute=value
pairs.
* XML-based file formats for defining objects of any of the types of
object described above (with the exception of entities)
* A very simplistic event manager allowing functions to be associated
with pygame.event events
* A customizable user input (UI) system that uses the event manager
described above
* Wrappers for many of the pygame.draw function which draw to the
screen when to surface is given
* Text-drawing functions for both single- and multi-lined strings
* A textbox system for making textboxes like those in Final Fantasy,
Mega Man X, etc. Supports CSS-like styling, automatic word wrapping,
and pagifying text. (still early in development)
* A simple resource file management system (this took a while to make,
and still has a few oddities)
* All-in-one engine for updating and drawing worlds and entities,
similar to the one in Game Maker, but most easily custimizable.

Features that are planned but not implemented yet:

* Semi-WYSIWYG editors for tilesets, tilemaps, images, worlds,
animations, composites, and possibly other things.
* Saving of certain resource file types.
* Drop-in physics code for platformer-type games
* Capability to link worlds together to make "super worlds"
* Support for positional sound
* Support for tracked music in formats like
* Textbox-based menus for making selections with the keyboard or mouse
* Implementation of critical modules in C to improve speed.
* Some kind of online multiplayer support

As you can see, I'm being very ambitious with this, but the project is
getting really big and I think I need some help. I'm open to any
suggestions and advice from people who have developed games before.
--
http://Alphaios.net - Tracked Module Music, Blog, and Links.