History

BananaBread

This is the original documentation written in the planning stages of Phase I of BananaBread. That phase is now complete, so this page and those it links to could be outdated.

The Plan

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

Phase I aka "let's see something working"

Goals:

• Botmatch game (i.e., player plays against AI bots), visually impressive and fun
• Works on modern browsers that support WebGL
• New art assets
• Works on mid-range hardware

Non-goals:

• No networking
• No editing (it will work, but no way to save etc.)
• No new gameplay, no new effects - keep all that exactly as in Sauerbraten

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. Details: Populate-the-Repo
• Decide on a theme for the game, that will influence all the artwork. Details: Game-Theme
• 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. Details: WebGL-Rendering
• Compile the code to JavaScript, filling in missing libc and GL pieces in Emscripten as needed. Details: Conversion-to-JavaScript
• Add texture set(s) and map(s), optimized for the web. If possible, several sets with different themes with different performance characteristics. Details: Maps-and-Textures Maps
• Add character model with various weapons and colors, optimized for the web. Details: Character-Model
• Add miscellaneous necessary artwork (splash screen, bullet impact texture, etc.). Details: Other-Artwork
• Add sound effects. Details: Sound-Effects
• Package the game for distribution so it is easy to just visit a website and have the game start up and run. Details: Packaging
• Profile the game, finding possible bottlenecks in JavaScript, WebGL, etc., file bugs in browsers. Details: Profiling-and-Benchmarking
• Wait on browser features and fixes that we need. Details: Browser-Dependencies

Workflow

• Mapping and testing of models can begin immediately, by using native builds from Sauerbraten svn. Note that svn has some nice improvements since the last stable release, and that is what we are targeting.
• Also possible to use native builds from the repo here, there should be no difference with Sauerbraten svn builds at first. Later when GL conversion is further along and some art assets have landed, we should move to working entirely with native builds from here.
• The GL conversion can begin immediately in this repo, using the placeholder art assets.
• Testing on the web will begin when the GL conversion is complete and the code translation to JavaScript is in good shape.
• Need to set up a Sauerbraten server for multiplayer mapping.

Performance Profile

Part of the goal of this project is to find how much we can do on the web, what size maps, what shaders, etc. we can run while keeping the frame rate high. So setting specific goals ahead of time is not possible. However, in general terms the following should be taken into consideration:

• JavaScript performance of compiled C++ code is generally in the range of 2x-6x slower than natively compiled code, closer to 2x for small benchmarks, and closer to 6x for large compiled codebases. However, that is for fully optimized code, and sometimes browsers have problems (see for example sql.js). Those problems will be fixed, but in the short term they might delay when our code can run at a reasonable rate. On the other side, some of the main JS engines have plans to optimize for compiled code, which means we can expect to run more quickly than current results indicate. A conservative estimate though is to assume that JavaScript will run 6x slower than a native build.
• WebGL shader performance should be very close to a natively compiled game. However, there is overhead in each WebGL call. Let's assume GL rendering will be 2x slower than a native build.
• Assuming general code and GL rendering take about equal time (handwavey estimate), that means maps run about 4x slower than natively, which means to get to 50fps on the web, we need 200fps in a native build.
• kripken's old laptop can do 200fps on douze (a smallish map) with 1 bot. We would have smaller textures and less detailed character models so the comparison is a very conservative one.
• Download size is very important on the web. We will use LZMA to compress the download to make it as efficient as possible. Let's assume that the total acceptable download - including code, map, model, etc., and after compression - is 5MB (random number that needs revision).
• Startup time is also crucial. Even if we can run with large textures and complex models with no change in frame rate, it might better to use smaller ones just because they can be loaded/processed more quickly. Sauerbraten map startup times are pretty good, but ours will be worse because of the speed of JavaScript, and slow startup is more of a concern on the web where people expect things to show up immediately.

Phases II+ aka "the future"

Future-Work