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.

Milestone One

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)
  • Robert Pointon (2 months)
  • John Siar (2 months)
  • Jeff Simmon (1.5 months)
    • Jeff can produce sound effects and compose music. He is relatively junior however he has developed sound designs for full games in the past.
    • Need to figure out the details of his involvement. He is interested but it depends on the number of sound files we need to produce
    • http://www.linkedin.com/in/ctsproductions
  • Stock Libraries - In an effort to reduce cost and add some flexibility, some budget will be required. This is not to exceed $20,000 USD, it is expected to be significantly lower but this is the maximum until we can create a more accurate budget.
  • Lee Salzman (a couple of hours)
    • Lee is the main dev in the Sauerbraten project, and wrote most of the physics and geometry code.
    • If we find parts of the code that run particularly slowly in JavaScript, Lee can do a few hours of work to optimize them in a more web-friendly manner. This might be the difference between a game that runs ok and a game that runs fast.

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.

Milestone Two

Requirements

  • Functional level editor with new HTML UI where needed
  • Ability to save levels and have them stored on the website
  • Ability to view summaries of levels stored on the website and click to launch them

Dependencies

  • Needs milestone one.

Milestone Three

Requirements

  • Multiplayer gameplay

Dependencies

  • WebRTC, which allows UDP sockets to be used, crucial for responsive network play
  • Needs Milestone one, but not two.

Reference Links