HTML5 Games/BananaBread

From MozillaWiki
Jump to navigation Jump to search

Overview

Make an HTML5 first person shooter by porting the Sauerbraten code to JavaScript along with new web-optimized art assets.

Note: Milestone 1 was completed successfully, the docs on this page may be out of date. See the project site in the links at the bottom for more current stuff.

Milestone Two

Requirements

  • Multiplayer gameplay
  • Game servers and master server to organize them
  • Website that allows finding games and joining them
  • Two new levels
    • A larger map for 6 players to play capture-the-flag

Resource Requirements

  • Alon Zakai (2 Months)
    • Will need to be working for the duration of the project on trouble shooting and optimizing Emscripten.
  • Gregor Koch (2 months)
    • Create game maps (worlds inside which play takes place) and texture sets for the maps.
  • Server Side Developer (1 month)
    • Alon can do this but may take more time, would be good to find someone else to help
  • Web Developer (2-4 weeks)

Dependencies

  • WebRTC, which allows UDP sockets to be used, crucial for responsive network play

Milestone One - Completed

Requirements

  • Botmatch game (i.e., player plays against AI bots), visually impressive and fun. Simple free-for-all gameplay (the player needs to shoot everything that moves, basically - there is nothing to explain)
  • Works on modern browsers that support WebGL
  • Works on mid-range hardware
  • One high quality playable level, preferably several
  • One character model + weapons

Non-Goals - Out of Scope:

  • No networking (not a multiplayer game)
  • No editing (it might work, but no way to save etc.)
  • No new gameplay concepts or visual effects not in Sauerbraten (and we will use only part of them)
  • No configuration/UI/etc., people loading the website jump right into action (or after pressing a big "start" button)
  • No sophisticated asset management, people visiting the game page will have the game code + all the assets for one game level downloaded in the simplest way possible. (We will use LZMA compression however to minimize the download as much as possible.)

Resource Requirements

  • Alon Zakai (3 Months)
    • Will need to be working for the duration of the project on trouble shooting and optimizing Emscripten
  • Gregor Koch (2 months)
    • Create game maps (worlds inside which play takes place) and texture sets for the maps

Duration

  • The project is currently estimated as 3 months.

Specific Tasks

  • Populate the github repo with the latest Sauerbraten code and the best freely-usable content we can find (just enough to get working while we wait for the art assets). Make sure the game compiles and runs natively.
  • Decide on a theme for the game, that will influence all the artwork.
  • Add WebGL-friendly rendering path. The game will still compile natively for easy testing on desktop, and the subset of OpenGL it uses will be trivial to hook up to WebGL calls.
  • Compile the code to JavaScript, filling in missing libc and GL pieces in Emscripten as needed.
  • Add texture set(s) and map(s), optimized for the web. If possible, several sets with different themes with different performance characteristics.
  • Add character model with various weapons and colors, optimized for the web.
  • Add miscellaneous necessary artwork (splash screen, bullet impact texture, etc.).
  • Add sound effects.
  • Package the game for distribution so it is easy to just visit a website and have the game start up and run.
  • Profile the game, finding possible bottlenecks in JavaScript, WebGL, etc., file bugs in browsers.

Benefits

  • Find how much we can do on the web, what size maps, what shaders, etc. we can run while keeping the frame rate high.
  • Push for the necessary improvements, both in browsers themselves (JavaScript JITs, WebGL engines, etc.) and in compiler technology for porting code to JavaScript. We can then work to improve performance in those areas, using this game as a benchmark.
  • We also want to end up with a playable, fun game, not just a demo. Also, the game will be open in all aspects, from code to artwork, and usable by others both commercially and noncommercially. We don't want just a simple tech demo that shows "hey, look what we can do on the web" but we also want to provide something that people can actually use to power their own games, projects and startups.

Mandreel has a tech demo of Sauerbraten compiled to JavaScript (see link at the bottom). This is useful as it shows that a naive port, using their OpenGL emulation, can achieve reasonable frame rates. The main benefits of doing our port are:

  • The Mandreel tech demo isn't a game, it just lets you walk around a single level. We will have a playable game with enemies that you can shoot at and that shoot at you. Benoit Jacob showed the Mandreel demo to people at a WebGL talk, and the responses were very positive - but they should be much more positive to see an actual fast-paced game taking place, not just a leisurely stroll.
  • We will have better performance due to optimizing the GL rendering path instead of emulating OpenGL.
  • We will be able to carefully profile the resulting game - including parts the Mandreel demo does not run, like bot AI - to see exactly what needs to be improved in the compiler and in the web platform to run it well.

Dependencies

  • Mouselock API
  • Keyboard input in fullscreen mode (or the ability to mouselock without fullscreen mode)
  • JS engine optimizations for typed array access and type inference calculation (Luke Wagner)
  • MediaStreams Audio API (roc)

Risks

  • Early project in porting 3D games using Emscripten, the goal is to test feasibility and it could require unexpected levels of optimization that were not anticipated in the build time.
  • Dependencies may delay port release, however, this should not significantly increase the scope of work.
  • Hitting unforeseen browser bugs that do not get fixed for some time. Part of the goal of the project is to hunt for these. It is part of the initial wave of end to end game experiments so we are almost certain to find these and the time it takes to non team members to address them could increase scope.

Reference Links