Home

BananaBread

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

Workflow

• Mapping and testing of models can begin immediately, by using 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.
• Testing on the web will begin when the GL conversion is complete and the code translation to JavaScript is in good shape.
• The GL conversion can begin immediately in this repo, using the placeholder art assets.

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

FAQ

• Why are you doing this?

• We intend to make a game that pushes the limits of what is possible on the web. By porting an existing game we will map out the problems in this space, and push for the necessary improvements, both in browsers themselves (JavaScript JITs, WebGL engines, etc.) and in compiler technology for porting code to JavaScript. We will 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. To make that possible, the code is zlib (a permissive open source license), and the art assets are CC-BY or CC-BY-SA (which allow commercial use).

• Why use Cube 2/Sauerbraten for this?

• There are other good open source FPS games out there, but essentially all of them are GPL licensed. There is nothing wrong with the GPL, but in the game industry it is very hard to get people to build commercial projects on it, and that is one of the goals of this project.

• Also, Sauerbraten has great in-game editing tools, which make is easy for people to build maps (the 'worlds' the games take place in). While editing is not a goal of Phase I of BananaBread, the option to have easy editing directly in the client running on the web is a very appealing (and web-like!) idea.

• Finally, Sauerbraten is a mature, stable codebase, which also happens to be of a reasonable size - just 120,000 lines of code for everything. This helps because the web runs not just on browsers on new desktops but also on older laptops and even mobile devices. The more compact the codebase, the better the chance of it loading quickly and running well at this point in time.