Game development

The XO Laptops need a true Game SDK but the bigger mission goes beyond that.

SDKs and more

We are trying to define specific deliverable areas to address with the XO for games:

1. A C++ oriented Game SDK that involves low-level open-source tools stitched together properly to provide a clear means for building and running games on the XO with C++/hardware level code. Essentially a DirectX (although at first we don't need much hardware abstraction - although that 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: We envision looking harder at SDL for this and we are investigating issues of integrating it into the XO. Kent Quirk of Cognitoy is writing a page SDL Implementation articulating how/if SDL or the like could fuel what we need. Our immediate thinking is that stripping down SDL (since like DirectX it focuses a lot on hardware abstraction we are less concerned with) might be a good way to eventually get it working. 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. A Python enabled API centered around pygame with enhancements for special XO features that sits on top of an adequate graphics stack (eventually to be integrated if needed with the above 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. 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.

4. 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. 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. 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: A basic 2D spacial system that is the XO answer to "Click-n-Play" and a storytelling branch that itself has several sub-branches: text-based w/static graphics, an SCUMM like adventure game, and an RPG maker style game engine using tiled scrolling engine. The final branch would be a "wargame/tactics" like engine that would be useful for creating simple turn-based strategy games of any type.

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

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 seperate 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. We envision three engine styles here:

Text Based w/Media Support 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.

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.

Meetings

We are working toward a series of future meetings between now and July focused on producing parts of the game SDK and actual games for the laptops:

• Conference call about XO Game Jam for spring in Boston : This will be a call with Boston IGDA and Boston Game Jam organizers to create a XO specific Game Jam for early June. This both serves as a goal to meet some of the development needs by then and to articulate games we'd like to see built as rapid prototypes.

• Localization [across software & content fields] : We are looking to host a small call to iron out specifics about how localization needs will be articulated for games that will run on the XO. It should be straightforward but we're double-checking things prior to finalizing a document on this.

• In-person, Cambridge, early April (10?), to set final development goals and 9-mo calendar : This will be a larger in-person meeting over a weekend in Cambridge to focus on final nuts and bolts issues related to producing initial workable game SDK (especially the pygame stack and initial libraries/engines/tools) for development. A formal agenda for these two-days is under construction.

• XO Game Developers Summit, July : This will be a first XO developers summit where there will be a release of tools , documentation, and sessions on developing for the XO. A fully articulated developer program, future schedule, and hosting of games built. E3 and GLS are 11-13 so we will not be meeting then. Perhaps the following weekend (21st?)

March 18

Our March 18 conference call focused on the following questions and subsequent notes:

• What big picture decisions can we make about each of the above needs?

      How can we get them properly developed in unison?

• Weekly meetings. Are Sundays good? -- I think in general weekends will be good if we can keep the calls shorter and use the Wiki aggressively as well. - Ben

• What do developers really need and by when? --guidelines for 2D, 3D graphics, networking, working w/sugar, size/footprint, common libraries

• What names do we need to reach out to? why? where? etc. --see below

• What sorts of deadlines can we set? --tentatively we have set July as a date to deliver the first feasible pygame stack, initial suite of documents, and host a developers summit.

• What process and structure needs to drive the next 12 weeks forward? (deadlines, updates)

• Where should development be centered and how do we create a means for making tough decisions?

  Who houses this work? Who makes sure builds are working and certified?

• Who does documentation?

  Kent: SDL, Ben & Peter: Khronos,

  Ben: high-level games, general notes

  Ian, Rob, Gnash-doc-writer: Gnash

  CMU ETC: Housing integrated platform, helping with key holes as identified?

  <Java... Stefano?> What will be the Java VM and when will it be finalized?

  What are the preferred file-formats? Can we make a common resource file format? common XML format for translation?

• How do we link this work into the core XO OS design group / get involved with that development?

  Docs on how to take part.

• What should a developer program look like?

  Specifically what should we be able to tell developers now, in a few months, in the future, and what do we want them to make, to build?

  Ben? get Jason dlr to talk about XOs; accept pro bono liaison offers. Have a site-section to sign up... laptop.org?

  Places to gather to show off; SF/CMU/CAM?

Timelines

First 2 weeks in April

• Meet in person; Cam / CMU (both?)

  Turn out a document to show the world what we want / expect

  Set 9-month calendar. Compare boston gamejam; indy gamejam for the XO in May?

  Get every game co in Bos/NY to come out.

  1 artist & sound guy for every 15 devs

  Figure out how this would work - separate conf call, with Darius/DanR [startup]

  Olin --> good for an offsite

  MIT --> available; harder to reserve

May-June sprints

• prep for a v1.0 in July -- have sprints in Cambridge? school's out. cf. CMU's 2-wk sprints all fall.
• articulate 9-month cal including Austin, for full-game devs.

July XO dev conference

• Something to prepare for / develop for

  Set up piggybacking on fall events.

specific platforms

SDL: "It needs to start working nicely on the XO." -- orospakr Work out an SDL spec : what we need and why (who would use it) 1200x900 is too big for most 2D SDL games to render quickly. if we activate hardware scaling for SDL applications (Mitch says that the Geode in the XO can only handle hardware scaling for "video", not "graphics". I'm not sure, but I think "video" simply means no access to any other 2D hardware acceleration primitives.) SDL doesn't seem to play nicely with matchbox. You have to kill it and start twm. Avoid hardware optimization? C/++ Cross-development enviroinment for Ubuntu, Debian, RHEL, &c C++ engines and frameworks people build on recommendations... Gnash and Flash Status on the system: working, somewhat; no games testing; sloth issues in browser Get standalone Gnash working, test on specific games. Q: A Gnash-activity or a separate one per game? Find out if this is possible this week Java J2ME, JREs? Harmony [super]Waba Footprint requirements Key target apps [Other] Low-level APIs Smalltalk... TBD. (people to invite. check with mobile platform, emulator devs)

Game platforms Pygame: Develop with GTK, et al. now. Q: How much more efficient is this? GCompris 3D and animation platforms Blender variant? Polygonal 3D Open GL ES [subset] (or 1.1?) Or 1.1? Java 3D? Check w/mike ab., david, et al. OpenKode Audio GStreamer CSound hooks? Vorbis devs? [Ben S. to inquire] Microphone libraries Inputs Touchpad input (stylus v. other) Probe input Wireless/mesh-strength input Battery level Power/current input Gesturing/cam API? Using existing video libraries Network Wireless/cellular Standard MMO networking

New platforms components tile based animation, sprite and animation tools tools for loading maps and doing simple game development; perhaps built on top of greater pygame frames -- Ben S. to write? Define requirements: physics, tiles, animations, sound, events... glass legos Emulation Display: shaders? How to differentiate b/t color and b/w? How to make a 640x480 image fill the screen properly? cf. display swizzling... et al. Give directions to people with games optimized for normal displays... for pixel-counters. "The Pixel Manifesto" [compare modex & vga learning curves] Speed: emulate low-cache, cpu/memory.

High level languages universities: CMU, USC, MIT : would love this division note that people can build things on fixed levels [C++ | pygame | Gnash], while discussing other classes of language visual programming etoys, mindrover [kq] graphical adventures (SCUM &c), arcade-like games (motion/spatial oriented), story games story engines Zork engines, text et al; small and portable kidpics, kidworks : illustrate drawings with words arcade and spatial click and play, et al [KQ]

Notes

• Cameras : Check with Richard M & Jamil M about Sony's cam labs -- Ben S
• Shadow Garden, from GDC '03, SIGGRAPH '06 : cameras --> projection --> distance detection
• David Chait - x games dev; gl es
• Note from the Khronos group : open source tools 'facing group' for marketing. Send memos to khronos.org...

  Ben S and Peter -- update on Khronos support next week

next steps

• schedule another meeting to go over specifics, with devs from related projects.

  First week of April? Can Carnegie-Mellon host?

• Writing a spec of what we need for SDL, and other low-level implementations: Kent
  PyGame implementation spec here: PyGame Implementation
  SDL implementation spec here: SDL Implementation
• Writing about network and mesh offerings (P2P size, limiting factors): ??

  Note what server apis might be interesting/useful here [available within some network distance, reliability, ...]: <>

• 3D update : Ben S & Peter
• Server spec (beyond networking): <>
• Have Ian work on Flash games this week.
• Talk to Jamil now about Austin & the next GDC

Portable platforms

Some notes on game development for various portable platforms. Please provide parallel thoughts on development and networks for these platforms; with an eye towards doing the best we can for OLPC machines. Quotes below from Wikipedia unless otherwise noted.

Palm OS

Interface: touchscreen

Development tools include "CASL, AppForge Crossfire (which uses C#) and Handheld Basic or HB++ (which uses Visual Basic)... A Java Run time Environment is also available for the Palm OS platform, however it isn't shipped as standard on non-Treo[s]" and Plua, which requires an additional runtime to be installed.

Garnet, Cobalt

"Palm OS Garnet applications are primarily coded in C/C++. There's an open source compiler tool chain prc-tools, based on an old gcc. PRC-Tools lacks several of CodeWarrior's features... a version is included in the Palm OS Developer Suite (PODS). OnBoardC is a C compiler that runs on the Palm itself." Wikipedia 1

"Palm OS Cobalt applications are coded in a variation of gcc, but the compilers have fewer limitations."

PPC platforms

...

Treo

Interface: keyboard, touchscreen, arrow key/wheel

GBA

...

PSP

Released by Sony in America in march in 2005 and in september 2005 in Europe and Australasia. The PSP has a large screen and the is a directional pad, analog stick and the playstation face buttons. There are also two shoulder buttons and interface control buttons (start, select and volume control).

There are also peripherals to add different inputs to the PSP

 microphone
 camera
 gps unit

Nintendo DS

"The Nintendo DS ... is a handheld game console developed and manufactured by Nintendo, and first released in 2004. The console features a clamshell design, with two LCD screens inside - one of which is a touch-sensitive screen."

• two screens
• one screen is a touch screen
• microphone
• local wireless + 802.11b

http://en.wikipedia.org/wiki/Nintendo_DS_homebrew#Notable_homebrew

See Also

I would like to remember that there are here, at this wiki, some lessons of a tested JavaScript API for the creation of games for the XO:

OLPCities/Tutorials

The lessons have many samples, demo etc. that can be accessed by the browser of any XO.

• Games
• Game controller
• End-user application software / Game Console Emulators
• Pygame