HTML5 Games/BananaBread: Difference between revisions

m
 
(38 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=BananaBread=
=Overview=


==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.
** Video of BananaBread working over WebRTC: [http://vimeo.com/57658941 Vimeo Video]
 
* 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==


Make an HTML5 first person shooter by porting the Sauerbraten code to JavaScript along with new web-optimized art assets.
* 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==
==Requirements==


* Botmatch game (i.e., player plays against AI bots), visually impressive and fun
* 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 modern browsers that support WebGL
* Works on mid-range hardware
* Works on mid-range hardware
Line 13: Line 115:
* One character model + weapons
* One character model + weapons


Non-Goals - Out of Scope
Non-Goals - Out of Scope:
 
* No networking (not a multiplayer game)
* No networking (not a multiplayer game)
* No editing (it will work, but no way to save etc.)
* No editing (it might work, but no way to save etc.)
* No new gameplay, no new effects - keep all that exactly as in Sauerbraten
* 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 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==
==Resource Requirements==
Line 26: Line 128:
* Gregor Koch (2 months)
* Gregor Koch (2 months)
** Create game maps (worlds inside which play takes place) and texture sets for the maps
** Create game maps (worlds inside which play takes place) and texture sets for the maps
** http://www.linkedin.com/pub/gregor-h-max-koch/1/216/991
* Robert Pointon (2 months)
** Modify the Sauerbraten rendering code to use a WebGL-friendly subset of OpenGL
** http://www.linkedin.com/pub/robert-pointon/14/527/b17
* John Siar (2 months)
** Create a new character model and auxiliary models (weapons etc.)
** Prior work: http://www.johnny3d.promail.ca/gallery/main.php
* 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==
==Duration==
Line 63: Line 150:
* Find how much we can do on the web, what size maps, what shaders, etc. we can run while keeping the frame rate high.
* 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.
* 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. 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).
* 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==
==Dependencies==
Line 78: Line 170:
* 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.
* 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==
=Reference Links=


* http://sauerbraten.org/
* BananaBread Release Site: https://developer.mozilla.org/en-US/demos/detail/bananabread
* https://github.com/kripken/BananaBread/wiki
* BananaBread github page: https://github.com/kripken/BananaBread
* Sauerbraten/Cube 2: http://sauerbraten.org/
* Mandreel tech demo: http://dl.dropbox.com/u/6873971/data/cube2/index.html
Confirmed users
855

edits