-
Notifications
You must be signed in to change notification settings - Fork 347
- Open, standards-based web technologies like JavaScript and WebGL are capable of a lot more than people are aware. We aim to create a demonstration of how the web can run even a first person shooter, well. No plugins needed!
- Also, having a full 3D game engine running on the web is a good testcase for profiling and optimizing browsers in order to make them even faster. There are some other impressive 3D demos on the web, but it is useful to have one which is open source and built using only open tools, which makes analyzing performance much easier. Also, it is very useful to have a complete game like BananaBread - it includes rendering, physics, AI, a multitude of effects, and even an integrated editor - to test on.
- Another reason for BananaBread is to provide a 100% open source codebase that people can learn from and use. We learned a lot while making BananaBread and others can now benefit from that by seeing our code and even using BananaBread as the basis for their own web-based 3D games.
- Finally, we also hope to dispel the myth that performance-intensive web content is hard to optimize for multiple browsers, a myth which caused some good WebGL demos and applications to write things like "best viewed in Chrome" or "best viewed in Firefox". Instead, BananaBread runs well in all browsers that currently support the necessary web technologies (WebGL, typed arrays and blobs, fullscreen, pointer lock, etc.), which currently includes both Firefox and Chrome (and hopefully soon Safari and Opera). We hope that seeing BananaBread proves there is no excuse for WebGL demos saying they only run well in one browser!
Several reasons:
- Writing a complete game engine takes a lot of time and effort. Years of work by very smart people went into creating Sauerbraten, adding features and optimizing every aspect of it as well as fixing many bugs. By compiling that engine we benefit from all their work (and they benefit as well since they can now run their project on the web).
- C++ code compiled to JS is often faster than handwritten JS, even though that might seem counterintuitive. Handwritten JS tends to use GC, property accesses, etc., which often lead to slowdowns and unpredictable performance. Compiled C++ primarily uses typed array accesses and simple optimized integer math, so it can run faster. You probably don't want to write large amounts of code like that, but a compiler does it easily. (Of course, you can use the same techniques in normal JS by using a library that does it for you or something like LLJS - compiled code is not the only solution here.)
- There are a lot of games in C++ and other non-JS languages, and improving the tools for porting those games to the web is useful in itself.
- Yes! All the code is zlib licensed (among the most permissive open source licenses). Use it freely, both for fun and commercially!
- All the art assets are CC-BY or CC-BY-SA, which means you can use them freely, even in commercial projects (see the main README in the repo for more details).
- In other words, you can take BananaBread in its entirety, code and art, modify it however you want, and do anything with that including selling it. You only need to keep copyright licenses, and in the case of CC-BY-SA content, you need to keep that content under that license (but it only affects them specifically, not anything else).
- 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 primary 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. (You can see a preview of editing already, press 'e' to toggle edit mode. Note that as just mentioned we have not focused on it, so it might be buggy.)
- 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.
- 'Sauerbraten' is a type of food, a pickled meat from Germany. 'Banana bread' is also a type of food. And it's tasty. (Maybe sauerbraten is too, I've not tried it.)
The demo should work on any browser that supports all the necessary web standards (WebGL, typed arrays, blob constructor, compressed textures, etc.). We have tested and seen the demo work on Firefox and Chrome (multiple versions, multiple OSes).
Running games like this on the web is very new, so some problems are to be expected. Aside from the issues mentioned in the "Troubleshooting" section on the demo page, we have had reports of the following:
- If the demo fails to run in Chrome, try to reload in a new tab. The issue is that Chrome fails to decode audio files in some cases (perhaps related to this). Reloading should eventually get it to work.
Please file an issue if with the contents of the web error console if this happens.
A more recent build is available here, which is worth trying too.
If the game crashes the tab or the browser, you should file an issue with the browser so they can fix it. We would appreciate it if you also filed an issue with us linking to it so we can track that.
If you get a JS stack trace, please file an issue with it. Note that you can append ,debug
to the game URLs to make it load a non-minified version of the main JS file for better stack traces.
- Tab crashes are frequent in Chrome, see here
If the game is unexpectedly slow, on a machine with decent graphics hardware that can run other 3D content well, please file an issue on our github page.
Enter the menu with 0 or ` then go to options->keys. Or, you can use the game console, for example /bind G left
will bind G to moving left. The other directions are right, forward and back (see data/defaults.cfg for more).
Sure, in the game type /invmouse 1
.
If your project is just standard Cube 2 with different artwork and scripts, but no changes to C++, then just grab BananaBread and change the art (see Modding) and scripts however you want. See the README for build instructions.
If your project has modified Cube 2's C++ code, you have two options: Either modify the BananaBread C++ code with your changes and do the previous paragraph's approach - that is simplest if you modified little of it - or, modify your project to compile to JS. The following is a sketch of how you would so so:
- First, make sure you can build BananaBread itself according to the README. That means setting up emscripten and LLVM, seeing that the emscripten tutorial stuff all works for you, then build BananaBread according to the instructions there. Make sure your build of BananaBread works.
- The next step is to patch your project with the small amount of changes we had to make to Cube 2 to get it to run in JS. This was just some little stuff like making the main loop async. To see the changes, diff the source files compared to revision b3e041526fa6dcc629c476fa34d1d5120b49cd0b which is when we copied in sauerbraten svn 4059, using something like
git diff -U5 b3e041526fa6dcc629c476fa34d1d5120b49cd0b `find -name "*.cpp"` `find -name "*.h"`
- Make sure your project builds natively with those changes.
- Make a
src/web
directory like in BananaBread, copy in libz.a, and create a Makefile. The Makefile is a modification of the normal Sauerbraten Makefile, adding a little code to use emscripten. Most of that is packaging the files (building for the web is a little different than natively in that respect). See Modding for more discussion on file packaging. - Copy the index.html, game.html etc. files that set up the web page, and customize however you want.
Please feel free to ask for help on our bug tracker here on github or on the emscripten IRC channel (#emscripten on irc.mozilla.org) - we'd love to help you with this stuff.