Search the Community

Hunt prehistoric creatures with your friends online. Build your own base, craft tools, and weapons to survive in a large-scale true cross-platform open world game. This game is an application of the engine I’ve built, to prove a statement: It is POSSIBLE to build a 3D version of the Internet, where instead of browsing through websites, we could jump from one 3D space to the next. I “invite” everyone to make this happen. I want you guys to build your own 3D spaces implementing your own ideas what the web should look like in the future. We could just link them all together and make this Interconnected Virtual Space happen - yeah, the Metaverse, for the Snow Crash fans out there Tech Details that I hope provokes further questions: Loading Assets on Demand is even more important in the Browser than on PC or Console. Internet speed is only a fraction of the speed of the hard drive. It is essential to only load whats visible if you want to provide an open world environment for users visiting your world the first time. LOD - Level of Details allows Web Browsers to show something immediately for the users just like an ordinary website. It may look poor and users can see the object improving as they are loaded, still, I think its a good trade-off. Users get a good enough view of their environment instantly and can start interacting with it immediately. Terrain and the Grid System I’ve created the terrain in Blender, then I split it up like a chessboard automatically using Javascript. It is easy/cheap to determine that which cell contains the given coordinate and every single cell in the Grid has a reference to its neighbors. This is the basis of server layers of optimization when it comes to rendering, AI, and collision detection, etc. A recursive search is very easy to do, using those links to neighboring cells. Lighting I've implanted basic Directional and Ambient Lighting to support Day & Night Cycles and Point Lighting for individual light sources like a campfire, torch etc. To my surprise, the difficult part was to get good looking flames, thanks to the lack of Alpha Sorting in WebGL, what I had to implement in Javascript instead. Animation I animate my models in Blender, export them to “.dae". The file format comes with a serious limitation, you can’t define multiple animations and it only maintains a list of keyframes as references. So I maintain a JSON file per “.dae” to define multiple animations by having sets of keyframes. E.g.: “{running: [0, 4], jump: [5,7], ..}”. But I kept it simple and didn’t take it to the realm of animations per body part. Physics In short, I was stupid enough to write my own ..on the other hand, I have a fine level of control over how much I allow it to run. Again, on mobile, it is crucial to have that level of control to navigate 200+ creatures in real-time. I have two different type of Collision Detection. Collision with the Terrain and collision with other model surfaces. Terrain collision is very cheap, this allows me to move so many NPC at once. Collision with other models is heavier though, but that allows me to climb random looking rocks. I optimized it enough to make it feasible to run on mobile devices. I use a low poly version of the models to determine the collision and I only run it for the models near the Player, utilizing the Grid System I mentioned above. AI NPCs can navigate a random terrain, avoid obstacles and “see” and “hear” other NPCs if behind them. At the moment, they move rather robotically, but this allows me to calculate, where they can move next without hitting any obstacles and how long it will take to get there. I only run the AI right before they get to the target location. Basically, 200+ NPCs make only 40-100 AI calls per second. ..I certainly have room for improvement here Multithreading in the browser is difficult but necessary to achieve good Frame Rate. Nothing but the rendering should be on the main thread ideally - Good luck to achieve it though I’ve managed to push most of the heavy logic into a speared thread, but AI is still running on the main one. In a thread you have very limited access to important functionalities of the browser, therefore, there is only so much you can do. Also, specific objects can only be passed by reference between threads, everything else has to be serialized on one end and deserialized on the other. You want to be careful how often you do it. Audio I use the Web Audio API that works as expected. On top of that, I implemented Audio Sprites: I compile all related sounds to a single mp3 file and that comes with a JSON object to define where certain audio snippets can be found. It's a fast, accurate and reliable solution unlike using Audio HTML Tag, but that one has its own use cases as well, e.g.: streaming an mp3 file comes for free, like streaming an internet radio station. Multiplayer - I use WebRTC and not WebSockets - I know, I know, hear me out. The idea was that COOP is a very likely scenario and players may only prefer the company of their friends. I that case, they don’t have to purchase access to a private server, as long as they are happy to let their world go dormant between gaming sessions. Plus, all the logic is implemented for single player mode on the client-side, which logic has to be duplicated on the servers, if I went down the WebSockets rout - just think about where the AI logic should be, server- or client side. I expect this one to be a controversial decision, ..sometimes even I'm not sure whether this was the “right" decision There is a whole lot more to this though. Resources could be distributed between players when it comes to AI to ease the load on the Host - I know it is a potential security issue, but there is a use case for it, like AI for distant NPCs in COOP as long as you have no hacker friends ..this could be crucial on mobile devices. Controller Support The Gamepad API provides you with raw access to every button and joystick. You certainly have to implement your own layer on top of that. Events for pressing/holding down buttons don't come out of the box. Implementation of the dead zone of joysticks is missing and it is inconsistent how you can access different types of controllers through the API, even the same controller but on different devices. In the end, you will have to provide a controller mapping implementation as well in your settings. But its totally doable and works like a charm. Touchscreen Support It's a tricky one. As I mentioned above, on iPhones its completely useless till Apple decides to comply with Web Standards. Even on Android, it is a bit tricky: For the UI you probably want to use HTML. It makes sense because it comes with all the neat features that make our lives easier until you realize that you can’t switch between weapons while running - wait, what? You see, while you are holding down the left side of the screen to maintain speed and try to click on a button, or any HTML element to switch weapons, the click event won’t fire. No click event will be fired while doing multi-touching. As a result, HTML and any fancy framework for that matter are no longer good enough solution own their own. UI When it comes to games we expect a whole lot more from the UI than on a website. Multi-touch support - as discussed above and even controller support is not as straightforward as you might think. You have raw access to the controller, so when a button is selected and the user pushes the joystick diagonally upward, you have no idea what is in that direction, therefore what should be selected next. You have to implement the navigation of your UI with a controller for yourself. And you need controller support because that's the only way to move around in VR and on consoles. Speaking of VR, you want to render your UI twice in VR - once for the right eye and once for the left eye - and only once when not in VR, just something to keep in mind Also, rendering the UI could be heavy. This might be a surprise but if you think about it, on a website you don’t do anything but the UI, so you have a lot mere leeway to work with, whereas in a game you don’t want the UI to impact the Frame Rate, so it has to be very lightweight and probably you want Scheduling to have a final say on what gets refreshed. Taking all this into account, I really don’t see how any framework could be a good option - they were simply designed with different requirements in mind and there is more downside to using any of them than upside. Precomputed Scene Occlusion Culling using a Grid System Most of the optimization is happening real-time or triggered on a regular basis while running the game with one exception: I render every cell in the Grid System from the point of view of every single other Cell. E.g.: Cell A can see cell B and C but not D. I literally diff two images with javascript to determine whether the given cube can be seen or not. Then I record the results in a JSON file, which is used for rendering. This reduces the number of cubes to be rendered significantly, but it takes about 40 hours to run this optimization for the whole terrain. Running the game on Mobile Devices iPhone runs WebGL significantly better than top-end Android devices but practically useless because Apple ignores important web standards. E.g.: Pinch zoom can’t be blocked, therefore when you use your left thumb to move around and right thumb to look around, instead of doing so you end up zooming back and forth the screen. It also doesn't support fullscreen mode - video does, but not the canvas element. Another interesting limitation on iPhone is that you can only have 25 elements in an array in GLSL, which translates to having only 25 bones in an animated model. This doesn't make animation impossible, but you can’t use most animated models that you buy in the stores, you have to do it again with only 25 bones. Profiling “What gets measured, gets managed”. The built-in profiler in Chrome certainly has its use-case, but not good enough for what we want, so probably you will have to build your own at some point with specific features. You want to know how long a certain section of your game runs per frame, e.g.: Rendering, AI, Physics, etc. and probably these sections won’t run sequentially, but they are interrupted by other processes that you don’t want to include into the specific measurement. One thing is for sure, you cant do optimization without identifying the source of the lags. - I've certainly wasted enough time trying Scheduling As long as you are pushing the limits of the devices it is always a battle for a smooth frame rate. Therefore, you have to implement a scheduling system to manage what is allowed to run and for how long. E.g.: whatever is loaded and processed in the background will have an effect on the frame rate even if it is running on a different thread, you want to throttle that. You don’t want to set variables through WebGL API unnecessarily. AI always varies how much calculations it has to do depending on the number of unique encounters of 200+ NPCs in a random environment. Basically, you will have to limit what runs and how long, manage what is a nice to have calculation and a game-breaking one and try to make it seamless for the user. Probably every single topic above deserves a dedicated post, so please feel free to ask anything - there is no stupid question - then I would like to use those questions to write an in-depth post on every single topic that helps fellow devs to overcome similar obstacles - no doubt I will learn a thing or two in the process Live Tech Demo is available on https://plainsofvr.com