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

[Devon Scott-Tunkin <djvonfunkin@xxxxxxxxx>]

Does it use its own map format? or did you use a basic txt or graphics file format?

Have you looked at the pgu editor code for examples? they might be helpful, even though I kind of hate them :). never know when map sizes are too big for it.

This project sounds great though, XML objects is something I've been meaning to try. I'm an even worse programmer still, otherwise I'd help (and I'm busy trying to learn in my own projects), and I'm also becoming more interested in making a similar thing in c++ using sfml these days.

One suggestion I have is to abstract the engine enough that you could port it to use another graphics engine (or any component) if you want to in the future without altering the way the classes and functions work, only what they wrap or use.

Devon
--- On Tue, 1/6/09, The Music Guy <musicguy@xxxxxxxxxxxx> wrote:

> From: The Music Guy <musicguy@xxxxxxxxxxxx>
> Subject: [pygame] Re: Working on Retro 80s Game SDK, Looking for general support
> To: pygame-users@xxxxxxxx
> Date: Tuesday, January 6, 2009, 10:26 PM
> Good point. I was sort of thinking the same thing, actually.
> I don't
> think I'll be able to start testing anything, though,
> until I have a
> basic world editor ready, otherwise it will be very
> difficult to
> create any test levels.
> 
> On Jan 6, 5:39 pm, Casey Duncan <ca...@xxxxxxxxxxx>
> wrote:
> > 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.