Game development: Difference between revisions

From OLPC
Jump to navigation Jump to search
 
(85 intermediate revisions by 26 users not shown)
Line 1: Line 1:
The XO Laptops need a true Game SDK but the bigger mission goes beyond that.
The XO Laptops need a true Game SDK but the bigger mission goes beyond that. See [[Game development meetings]] for more. For Pygame in particular, see [[Game development HOWTO]].


<div style="float:right; font-size:90%">
<div style="float:right; font-size:90%">
__TOC__
__TOC__
</div>
</div>
== SDKs and more ==


We actually need multiple elements delivered over the course of the year as
follows:


== Mid-level tools and engines ==
1. A True 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. Essentially DirectX for the laptops is a good analogy. This should
include a proper graphics, sound, input API as well as other specialized
things like camera API, support for b/w mode, etc.


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:
2. 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.


'''Lower-level engines'''
3. We need tools and any level of game middleware we can help create. Be it
PyGame, a tiled scrolling engine, etc. but this would be a second layer on
top of core libraries that developers would use. This also includes content
creation tools that let people create graphics, sounds, etc. In that regard
it may just be proper documentation but we may also want graphical drawing
tools right on the laptop to help as well. Some of these tools might end up
formulating on-laptop tools for kids.


* 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.
4. We need a true emulation capability for the PC/Mac. 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.


* Isometric 4 way scroller (different then top down scroller) - good for tactics/wargame/zelda/civ styled games.
5. We need on-laptop tools to help kids build their own games. Ideally this
might be two or more environments -- one programmatic in nature and another
that is more likely a visual system for building games. It might even be a
suite of tools that let you build different types of games like adventure
games, tiled scrollers, etc.
:: --Ben Sawyer


* 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'''
== Meetings ==
=== March 18 ===


Resource Files
* What big picture decisions can we make about each of the above needs? How can we get them properly developed in unison?
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'''
* What do developers really need and by when? ''--guidelines for 2D, 3D graphics, networking, working w/sugar, size/footprint, common libraries''
XO native applications that we need for on-laptop development:
*: What names do we need to reach out to? why? where? etc. ''--see below''
*: What sorts of deadlines can we set?
*: What process and structure needs to drive the next 12 weeks forward? (deadlines, updates)


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.
* 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?


Sound Editor : XO based - simple editing, ogg vorbis output, etc.
* Who does documentation?


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.
* How do we link this work into the core XO OS design group / get involved with that development?


== High-level editable game systems ==
* 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?


There will ultimately be many frameworks for kids to build their own games with the laptops.
<!--
==== attendance ====
* Kent Quirk
* Ben Sawyer
* Mel Chua
* Kal
* Mark
* Chris Murphy (online)
* Jeff Keller
* j, dustin,
-->


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.
==== specific platforms ====
{|
|-
|width="50%" valign=top|
'''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?


We have decided to break high-level game systems into three initial branches:
'''C/++'''
* Cross-development enviroinment for Ubuntu, Debian, RHEL, &c
* C++ engines and frameworks people build on recommendations...


1. A basic 2D spacial system that is the XO answer to "Click-n-Play"
'''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


2. A storytelling game branch that has several sub-branches:
'''[Other] Low-level APIs'''
*


A. Text-based w/static graphics, sounds, etc.
|width="50%" valign=top|
B. A SCUMM like adventure game
'''Game platforms'''
C. An RPG maker style game engine using tiled scrolling engine.
* ''Pygame'': Develop with GTK, et al. now.
** '''Q''': How much more efficient is this?
* ''GCompris''


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.''
'''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


; 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.
'''Audio'''
* ''GStreamer''
* ''CSound'' hooks?
* Vorbis devs? [Ben S. to inquire]
* Microphone libraries


=== Details on the engine ideas ===
'''Inputs'''
* Touchpad input (stylus v. other)
* Probe input
* Wireless/mesh-strength input
* Battery level
* Power/current input
* Gesturing/cam API? Using existing video libraries


; 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.
'''Network'''
* Wireless/cellular
* Standard MMO networking
|}


; 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:
'''New platforms'''
* 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?
* ''visual programming'' -- etoys, click and play, mindrover [kq]
** Define requirements: physics, tiles, animations, sound, events... glass legos


: 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.
'''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


; 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.
==== 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
* 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.


; 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.
== Portable platforms ==
Some notes on game development for various portable platforms. Quotes below from Wikipedia unless otherwise noted.


; 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.
=== Palm OS ===
* Interface: touchscreen


: '''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.''
* 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."'' [http://en.wikipedia.org/wiki/Palm_OS Wikipedia 1]
*: ''"Palm OS Cobalt applications are coded in a variation of gcc, but the compilers have fewer limitations."''


; 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.
=== PPC platforms ===


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.
=== Treo ===
Interface: keyboard, touchscreen, arrow key/wheel


=== GBA ===
== Text-based games ==


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


One category of text-based games is [[Wikipedia:roguelike|roguelike]] games such as Rogue, Hack and nethack, as well as Adventure, Moria and Angband.
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).


Another category of text-based games which could be ported to XO are [[Wikipedia:MUD|MUD]]s. 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.
There are also peripherals to add different inputs to the PSP

* microphone
== Meetings ==
* camera

* gps unit
Moved to [[Game development meetings]].


== See Also ==
== See Also ==


* [[:Category:Developing games]]
*[[Games]]
* 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.
*[[Game controller]]
* [[Games]]
*[[End-user application software]] / [[End-user application software#Game Console Emulators|Game Console Emulators]]
*[[Pygame]]
* [[Game controller]]
* [[Board Games]]
* [[Simple Game Library]]
* [[End-user application software]] / [[End-user application software#Game Console Emulators|Game Console Emulators]]
* [[Pygame]]
* [[Game Development Meetings]]
* [[Game Platform Comparisons]]
* [[Game Development Quickstart]]
* [[Game_development_HOWTO]]
* [[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.


[[Category:Software ideas]]
[[Category:Software ideas]]
[[Category:Developing games]]

Latest revision as of 01:54, 21 May 2009

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


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

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