HTML5 Games/BananaBread

From MozillaWiki
Jump to: navigation, search

Overview

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

Status

  • Milestone 3 is slated to get underway on the 28th of January.
  • Milestone 2 is currently underway, progress has been rapid and we expect to have a working demo in the near future.
  • 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 Three

Functional Requirements

  • Firefox Android support on high end phones
  • Touch Interface Support

Duration

This is very hard to predict at the moment as there are significant potential challenges to getting this to work on Mobile.

Resource Requirements

  • Alon Zakai (?)
    • Will need to be working for the duration of the project on trouble shooting and optimizing Emscripten.
  • Vladimir Vukicevic (?)
    • Vlad will be focused on solving platform performance and blocking issues to making this work.

Specific Tasks

  • Test port in Firefox Android and determine major blocking issues.
  • Review project plan at this point and determine more specific tasks.
  • Will need to design and develop a touch interface for the game.
  •  ?
  • Finish web dev on master server and interfaces to game engine.
  • Work with marketing ahead of time to make a plan for launch.
  • Video in HD.

Dependencies

  • None currently, project is slated to begin on the 28th of January when Vlad returns from vacation.

Benefits

  • Show viability of 3D on mobile.
  • Improve the platform to better support games on mobile.

Risks

  • This is a really hard challenge and it is expected that a lot of work will have to go into the platform as a result. As the this risk is also a key reason to attempt the project, there is no way to mitigate it. Time frame for this projects success is unknown as a result.

Milestone Two - Completed

Functional 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

Duration

2 months, WebRTC is still a pretty big unknown, will need to re-estimate once WebRTC connection is confirmed to work for the use case.

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.
  • Alan Kligman (1 month)
    • Alan is working on the WebRTC matching server and client side implementation.
  • Web Developer (2-4 weeks)

Specific Tasks

  • Set up testing environment - two browsers that can connect to each other. Preferably on the same machine
  • Get the engine's networking layer to work over WebRTC
  • Connect clients using master server in a simple way
  • Develop art: new levels and pickups
  • Finish web dev on master server and interfaces to game engine
  • Work with marketing ahead of time to make a plan for launch
  • Video in HD

Dependencies

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

Benefits

  • Test WebRTC
  • Be the first to demo WebRTC games and drive that
  • Prove even peer to peer multiplayer games work on the web
  • Shows that fast network communication is now possible

Risks

  • WebRTC UDP sockets not landing, or staying landed
    • Mitigation: Not start until this is done
    • This is now done!
  • WebRTC UDP sockets behaving oddly or restricted in some manner, or otherwise cannot implement UDP sockets like the game engine expects
    • Mitigation: Investigate early to insure the solution will work for the project, we won't start art or master server until we have better insight

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

Retrieved from "https://wiki.mozilla.org/index.php?title=HTML5_Games/BananaBread&oldid=665578"