Game development: Difference between revisions

From OLPC
Jump to navigation Jump to search
Line 73: Line 73:
*: Ben? get Jason dlr to talk about XOs; accept pro bono liaison offers. Have a site-section to sign up... ''laptop.org''?
*: 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?
*: 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


'''May & June sprints'''
'''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.
* 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.
* 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.





Revision as of 20:35, 18 March 2007

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

SDKs and more

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

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.

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.

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.

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.

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


Meetings

March 18

  • 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?
  • 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?
    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
    Jesse: CMU? Panda development.
    <Java... Stefano?>
  • 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

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

  • 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

Zork engines

  • Text et al; small and portable

story engines

  • kidpics, kidworks : illustrate drawings with words

visual programming

  • etoys, mindrover [kq]
  • graphical adventurem (SCUM &c), arcade-like games (motion/spatial oriented), story games

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

Portable platforms

Some notes on game development for various portable platforms. 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

See Also