Game development

The XO Laptops need a true Game SDK but the bigger mission goes beyond that. See #Meetings for more. For Pygame in particular, see Game development HOWTO.

SDK, libraries, engines, tools, etc.

At this time we've identified the following deliverables for the XO relevant to game development:

1. C/C++ game SDK

This effort would provide low-level open-source libraries and tools stitched together properly to provide a clear means for building and running games on the XO with C/C++ and "hardware level" code. Essentially a DirectX (although at first we don't need much hardware abstraction - which may change as the program evolves over many years) is a good quick analogy. This API should include graphics, sound, input API, and specialized APIs for the camera, microphone, support for b/w mode, common USB attachments.

CURRENT THINKING

SDL works perfectly for this; it is an excellent fit. We are also looking at OpenKode/OpenGL ES. We expect to get these answers and articulate at least paths for integration of a C++ styled SDK out by mid-to-late April. Those interested in commenting see the C++Api element below.

2. Python & PyGame

A Python enabled API centered around Pygame (www.pygame.org) with enhancements for special XO features that sits on top of an adequate graphics stack (eventually to be integrated if needed with the above C/C++ pipeline) that further feeds into libraries of code and tools that fuel various silos of game engines with both code-level and visual interfaces for kids and developers alike to build games with. This document is under development at PyGame Implementation.

3. Flash/GNASH

A Flash Based solution (using GNASH) which we can certify and support as being compatible in some form for various games that push flash. We need to take some flash games and throw them against GNASH on XO and derive what works and what doesn't and essentially create two documents - one for the GNASH team to use to improve compatibility and one for developers to use to inform changes on their end.

CURRENT THINKING

Our goal with GNASH is that while it currently is being integrated into the browser we will seek a standalone version that can run outside of the browser when called upon by a program written in Flash. These programs would not call upon any browser needs and some sort of header or extension would help the OS delineate between a program that wants to run within or outside of the browser. We will need to double check security issues with outside the browser operation as well as test UI and speed to see if this provides an advantage although our guess is there might be enough of some kinds of advantages to warrant it. There was also some talk of Flash Lite. Finding an easy means to implement peer-to-peer/multiplayer in Flash on the XO is also something that needs thought.

4. Middleware/dev tools

We need tools and any level of game middleware we can help create. We need to create a suite of content creation tools (which in many cases may just be documents and recommended programs for content creation) and articulate some core engines we'd like to see built on top of our PyGame stack and eventually the C++ stack. Some tools like a graphics paint program for sprites, backgrounds, etc. we'd like to see actually native to the XO as well. Please see below for more information.

5. Emulator

We need to improve emulation capability for developers. We are trying to understand emulation as it exists now and build a document to express what an ideal emulator for game developers would be. Ideally an emulator would simulate the entirety of the laptop not just an OS port. It would simulate speed, it would simulate keyboard layout, buttons, camera, etc. We need to figure out also how to deliver on a means of compiling to the laptop in such a way to integrate an IDE with the tools we build to enable development.

6. XO-Based Game Maker Tools

We need on-laptop tools to help kids build their own games. We are looking for systems that run on top of the pygame stack initially and then the C++ stack. We are already expressing ideas for what initial editable game frameworks might enable (see below) and we are looking for more ideas. We see the tools offering ways to modify themselves both at the programmatic (i.e. Python level) and at higher visual only levels. Bringing in new first contact language derivatives will also be explored and looking for projects that could teach game design such as the one MacArthur is funding Gamelab/UW to produce or which Square Enix showed at serious games summit would also be cool.

This was initially outlined by Ben Sawyer and modified after initial meeting on 3/18/07

Mid-level tools and engines

Between lower-level frameworks and stacks, and before we get to editable game systems we also have a layer of middleware, libraries, examples, and content tools. Here are some of the ideas which were discussed in the meeting. Some may fuel things in higher-level editable game systems:

Lower-level engines

• Side scrolling engine, vertical scrolling, 4-way scroller (step and smooth?), Zelda Static Tiled Screen Engine :: these may all be in the same library with different parameters. Be nice if the basic map file format is same and well documented.

• Isometric 4 way scroller (different then top down scroller) - good for tactics/wargame/zelda/civ styled games.

• Basic 3D game engines, FPS (less for shooters more for things like 3D RPGs/Adventures), Quake I has been run on the laptops. Need to figure out way to build editable system then to envision games built on top of these.

We need more here...

Tools

Resource Files Simple resource editor to pack graphics and sounds, etc. in common grouped formats for access by pygame framework - be cool if we could try and enforce a voluntary standard that would make it easy to extract graphics, sound, text from resource files for all games...

XO native apps XO native applications that we need for on-laptop development:

Graphics Editor : Pixel perfect XO native graphics editor that can save items for use in various games. More like the old Deluxe Paint/Animation package then Gimp or Photoshop. Perhaps with simple page flipped animation capabilities.

Sound Editor : XO based - simple editing, ogg vorbis output, etc.

Music Files : Find royalty free music files to make available easily for games that kids build. Ideally tools to compose music would be great but realistically having a library of midi or looped wav files would be needed as well.

High-level editable game systems

There will ultimately be many frameworks for kids to build their own games with the laptops.

However, we must articulate our core early goals and build support around some subset of tools so we can evolve them as needed. Eventually this can expand as other incredible ideas come forward.

We have decided to break high-level game systems into three initial branches:

1. A basic 2D spacial system that is the XO answer to "Click-n-Play"

2. A storytelling game branch that has several sub-branches:

   A. Text-based w/static graphics, sounds, etc.
   B. A SCUMM like adventure game
   C. An RPG maker style game engine using tiled scrolling engine.  

3. A final branch would be a "wargame/tactics" like engine that would be useful for creating simple turn-based strategy games of any type with story elements.

Key Items to Stress

These frameworks developed correctly for the laptops could be useful for other systems as well. In the case of the XO and kids we must realize that usability, lack of major defects, and language issues must be taken into deep consideration. This mean adapting various existing systems might not work. If there are good ideas for open source tools to use that would be welcomed in the discussion. We've looked at a few and don't find the sort of perfect fit we want with exception to ScummVM.

Details on the engine ideas

Click-n-Play Style Engine

We need to spec this out but the idea is something with visual editor that sits on top of Pygame, and has a playback system also within pygame and separate outside files that describe various relationships. The ultimate idea would be for it to create actual pygame code for playback that could then be further edited at a codebase level.

Adventure Engines

The key aspect to the adventure engines we employ is to encourage the use of storytelling and narrative in game-based form. This is why we want to emphasize different styles of games that make up commonly played adventure/RPG syles. As mentioned there are three engine branches to pursue:

Text Based w/Media Support : We are beginning work on this design at Text With Media Game Engine.

The text-based w/static graphics/media tools is an easy element to design and/or adapt from other free engines. We would avoid a large scale parser system and integrate in more of an multiple choice engine with parsing available at times. Make the editor easy too and Sugarized. Certainly we can point various Z-machine style systems or other systems in the interactive fiction space but we might be better off with a newer system that is simplified and easy to author.

Graphical Engine

This would be a SCUMM like adventure game engine and ideally it'd be great. We're looking at http://www.scummvm.org/ which would be great to port over. The issue of course is creating a SCUMM compliant game is not easy and this would be less of a need focused on kids and more focused on giving developers another engine tool with which to provide end-games for kids.

Tiled RPG Engine

An RPG maker like engine we could adapt from: http://hamsterrepublic.com/ohrrpgce/index.php/Main_Page.html but this may be a lot of work and actually may result in an engine that is too much work. We should look at how we could design or find something simpler in nature to develop and move over.

Tactics/Wargame Engine

Simple engine + some basic AI/multiplayer to allow people to create and tune their own empire/advanced wars/tactics style games. Again we may find some existing open-source frameworks to use but we may also have to resort to something simpler and new to get exactly the deliverable we need.

Note: It would be nice eventually if the scrolling/static screen (Zelda) style tiled code we want could be the same code used for these engines. Building modularity into the system like this would be a really welcomed route.

Other Engines

There are certainly other game engines like RTS, card game, First Person, etc. but for now we will focus on the above because they ultimately will be simpler for kids to build with and to build ourselves.

A racing game engine would be a good item as well. Jim Parker's book on racing games might be a good start adapting since we could adapt some text as well with permission.

Text-based games

There are several classes of text-based games which might be ported to the XO.

One category of text-based games is roguelike games such as Rogue, Hack and nethack, as well as Adventure, Moria and Angband.

Another category of text-based games which could be ported to XO are MUDs. MUDs (usually understood to mean "multi-user dungeons) are text-based multiplayer computer games. Usually these are organized around a fantasy or science fiction theme, but they can be used for chatrooms, virtual classrooms or even for online theater. Among MUDs are Tinymud, dikumud and LPmud.

Meetings

Moved to Game development meetings.

See Also

• I would like to remember that at OLPCities/Tutorials are some lessons of a tested JavaScript API for the creation of games for the XO; the lessons have many samples, demo etc. that can be accessed by the browser of any XO.
• Games
• Game controller
• Board Games
• Simple Game Library
• End-user application software / Game Console Emulators
• Pygame
• Game Development Meetings
• Game Platform Comparisons
• Game Development Quickstart
• Game_development_HOWTO
• Game_Developer_Docs
• Game_Developer_Program_Information
• Creating a networking API
• Porting pygame games to the XO
• Game psychology
• Physics

People interested in 3D graphics on the XO should check out the 3D Graphics page.