Langenium v6 Retrospective

Langenium is an open source MMORPG project that has been in development since 2012. The latest phase, dubbed “v6” is a major rebuild of the project using the current Open Studios website as a 3D game client, building a reusable TypeScript codebase for game logic and a new Node.js server for multiplayer. The final ticket in the v6 epic (Basic Gameplay – Issue #32) was just completed a few weeks ago making this phase complete. All the best and unique parts of different past versions of Langenium were referenced in this refactor, put to use where it provided a benefit and replaced from scratch when it was easier to do that instead.
When the project first started in 2012, WebGL was still not widely available in the browser and the smartphone market had only just begun to mature with models like the iPhone 5 and Galaxy Note 2. With today’s technology, it is much easier to do 3D in the web, however the practical challenges of working with 3D means it remains a new frontier for the industry. Overheads that originally slowed down this project such as 3D asset production and optimisation haven’t gone away, even with today’s AI.
Game client
The Open Studios website is a fork of the static Langenium v5 game client, upgraded significantly with modern techniques and the latest versions of libraries like Three.js. New libraries like postprocessing were used to optimise multiple shader effect passes and detect-gpu allows the engine to dynamically scale performance to the capabilities of each visitors device and browser. This means that a user accessing the Langenium game website on their PC will get a more high end experience with 4K, shader based special effects, while someone accesing it on a laptop or mobile may see a more demure experience.
The Langenium loader is a script that was devised in v5 to allow the engine to load and unload script files dynamically. The idea was that a static version of the site had to have a way to change itself in the browser, taking on code only as needed and offloading unused code to allow for hot module replacement by using AJAX. Taking inspiration from APIs in CMSes like Drupal and WordPress, Javascript libraries can be added while declaring their dependencies and a callback. This means that a library that needs THREE.JS won’t load into memory until THREE.JS is loaded, and when both are ready a custom function within the game engine can be called to tell it things are ready to go. In the screenshot below, the final callback “l.init()” is called once its two dependencies (TWEEN.JS and the game client) are loaded.

The Open Studios website uses the Langenium loader script to load all its dependencies, without a bundling solution like Webpack or Rollup. Using the loader instead of a bundler adds a little bit of delay in real time, however it also stops the browser from freezing when it downloads the app script and tries to process it. While it’s counterintuitive to pick something that takes longer in tech – in testing it felt like the website was freezing or crashing entirely when the compiled version of the script file was loaded. It seems that while the incremental approach of loading small scripts takes a little longer (0.5s~1s), it prevents the browser from being overwhelmed when crunching a big JS file. We already occupy the users attention with an animation on the screen and found in testing that the device freezing made it seem like the website might have crashed the users phone which was not great. The same may not always be true when trying to handle Langenium’s much larger codebase, we have a ticket to figure that out in a future sprint.
In order for the game to have viable multiplayer, the game clients and server need to use an established set of rules in order to create a synchronised game simulation across all players and itself (as the source of truth). To do this in Langenium, both the game client and server use a shared /game folder which contains TypeScript classes that define game objects like aircraft statistics and capabilities, damage calculations and other code that needs to be shared and could be considered “game logic”.
Touch controls and cross platform focus

A key goal of Langenium is to implement a cross platform experience which means its UI has to work for touchscreen and keyboard and mouse. The game has always supported keyboard and mouse as that is what it was developed on, however it has been lacking touch controls until now.
mese97’s touch library was used to add onscreen controls and was extended with our own custom elevator lever. The combat controls are custom HTML elements overlaid and tied into the game engine.

TweakPane is used to power the game’s menu system and game engine controls including the settings screen and debugging mode. The latter is used during development to test things such as frame rate, changing the active camera to look at other objects and more. This mode can be accessed by going to settings and selecting “Debugging mode”.

Thruster effects
We used the library TrailRenderer as a starting point for drawing missile and player thruster exhaust trails and then built on that with some extensions. The player’s aircraft trail is dynamically stretched and reacts to the speed they are flying. The faster they travel, the more promiment the effect.

Video sprites from a real jet engine are attached in a circular formation around the player’s aircraft jet engine to create the effect of a thruster, when the player accelerates the sprites are stretched out to simulate drag and the video elements within play faster to give the illusion of greater turbulence.
Procedural materials and basic scenery

We turned to procedural generation to create high resolution materials. This topic was so large it has it’s own blog article!
How to implement Blender Principled BSDF Materials in Three.js (WebGL)
Scanners, targeting overlay and missile systems
Langenium players used to only have a mini-gun style weapon that would shoot in a straight line from where the aircraft was facing – this wasn’t a very fun way to play and so it was decided that players should either focus on flying or shooting, assisted by auto-targeting and auto-pilot respectively. The targeting scanner is currently rudimentary with simple options of friend or foe, but the foundation is laid to expand that in future to allow more complex factional relationships between players and organisations within the game’s world, e.g. player teams, guilds, companies of enemy bots, etc.
When an enemy is being target locked, their onscreen overlay pulses in size and from navy blue to magenta – indicating the scanner is locking on. Once a target lock is established, the target overlay changes into a solid thick magenta line indicating weapons can now be fired at the target.
To assist with testing and this stage of development, auto attacking hostile targets is built into the user interface. A player simply has to fly within the scanner range of an enemy and their aircraft will automatically start firing missiles. In future versions, players will be able to manually fire missiles using the on-screen interface and an assigned keyboard button.

Mini map

The new mini-map is based on the player ship’s targeting scanner. Like the rest of the user interface, elements are made with regular HTML and a bit of SVG.
Symbols on the map determine whether a the radar system detected a structure (square), aircraft (triangle) or sea vessel (trapezoid). Green symbols represent passive targets, yellow means aggressive and red means they are currently engaged in combat with the player.
NPC Pathfinding and Artificial Intelligence (AI)
Non player characters (NPCs) use the YUKA library for Sight and Pathfinding. In order to uncouple game AI logic from the frontend game client, YUKA imports are restricted to the common game folder in order to ensure all pathfinding and NPC AI related code lives in the shared /game folder. This is vital to ensure that the server can accurately simulate the same environment in the cloud as users see in their browsers.
Cargo ships travel between Extractor wells and the nearby Platform City, an important resource hub belonging to the powerful Union faction in the game. The initial gameplay goal of the scene is to provide missions where players defend, escort and run errands for Langenium operations based out of this city.
The current demo features one pirate aircraft, but the plan is to have some spawn on missions and others roam the open world in a traditional MMORPG PvE fashion.
Roadmap to production release
With V6 now complete, we have a solid foundation to start thinking ahead to a production version of the game. Ironically, this is something that was never done on the project because it seemed too far out of reach in the past. Langenium’s development was always agile based, focused on delivering the next goal but not looking too far ahead because we were too unsure about what we wanted and what was best.
Below is our current draft roadmap for the next phase of the project, which will be called v7. Technically that version is more like 0.7 in the grand scheme of things but when your project timeline spans decades you have to keep things interesting! Some of the items on the new agenda already have an issue ticket.
- v7 – Build on the new capabilities and start to extend them
- Add new combat features to multiplayer – Issue #34
- New public server with funding arm for the projects resources
- Persist player data
- Items and weapon ammunition systems – Issue #58
- Dialogue capability with narrator/tutorial
- New screens for game intro sequence, player inventory, player hangar, docking with a building – Issue #31 and Issue #55
- v8 – Content systems for the game
- Story missions and side quests
- Player research / tech / progress tree
- Achievements and leaderboards
- Cut scenes, audio dialogue and music
- v9 – Content development
- Align the game world to the lore and writing notes
- Optimise and test things getting ready for 1.0
- Build enough content to be ready for 1.0
- v10 (1.0) – Launch!
- Setup a production multiplayer server
- Funding / crowdsource / promotion
We’re excited to hear your feedback on Langenium v6 – as a game and as a web based experience. If this is something that interests you then please reach out to us on Github or social media! The success of this ambitious effort relies on a collective effort to improve and refine until we have an open source, openly produced and web based game that is as awesome and fun as any commercially produced one.
Want to play Langenium? Simply visit the Langenium website.
Want more information about the game’s development? Check out the Langenium 2012-2025 Retrospective for a look back for the entire history of the project!
References and Links
- Thank you to the hard working and talented developers and the communities behind these open source projects, without whose ongoing contributions there would be no Langenium project:
- Three.JS, the backbone of our game’s 3D engine
- node.js, providing the current paradigm for Javascript development
- postprocessing, lightening the burden of multiple shader passes
- detect-gpu, allowing the game client to select optimal settings before render
- YUKA, a library for developing game AI
- TrailerRenderer, giving missiles and jet engines beautiful trails
- TouchControls, providing a solid foundation for cross platform interactivity
- TweakPane, driving the game engine’s core UI
- Blender, used to produce all in-game models that aren’t procedurally generated
- LMMS, used to produce game music including the trailer music
- Langenium links
- Official website where you can test play the latest version of Langenium
- Langenium repository on Github
- Langenium videos on Youtube
Back to Blog Home