Game development: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Removed This - moved to SDK comparisons)
Line 121: Line 121:
????
????


== 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."'' [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."''

=== 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 ==
== See Also ==

Revision as of 21:18, 9 April 2007

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

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


Meetings

Moved meeting information to Game Development Meetings. Please see this for meeting information and notes.

Upcoming Meetings

????


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.