Hello all,
As is tradition, we celebrate Halloween 2024 with a content-filled Mob-Arena update, including complete overhauls to two zombie-themed Mob-Arena maps: Infection and Tomb. We also updated Mob-Arena to be more challenging than ever by adding the ability for bosses to become enraged, and by making regeneration harder to come by in Endless mode. Finally, we have improved the Mob-Arena joining experience, enabled the Halloween event with a brand-new event map, SpookHouse, as well as returning seasonal maps and limited-time quests!
OVERHAULED MAP: INFECTION
The Infection map has been entirely reimagined by Mohorowe. Set in a post-apocalyptic city block with perimeter walls recently breached by the horde, the survivors must defend themselves from an increasing onslaught of the zombies. Infection is now a horde-style map similar to Last Stand, but with a lower difficulty which is more accessible to new players; its later waves are nonetheless more difficult than before to counteract the increases in the player’s late-game arsenal compared to when the map was first released.
OVERHAULED MAP: TOMB
A new overhaul of the Tomb map crafted by dxc and Mohorowe. Explore an ancient Tomb full of skeletons, spirits, and ghosts. Find refuge in underground tunnels and fight back against the tyranny of the Pumpkin King. This new rendition of the map features a more compact layout and should present a spooky challenge to even experienced players, especially combined with new Mob-Arena mechanics such as Enraged Bosses, also added this update.
SEASONAL PVP MAP: SPOOKHOUSE
SpookHouse is a Halloween rendition of the classic ShootHouse map built by James_4007. The classic layout has now gained an undoubtedly spooky atmosphere where ghostly darkness haunts your every step! Can you overcome the fear of the undead while still defeating the enemy team?
Available seasonally in TDM, KOTH, MineSpades (KOTH Outbreak Mutator), Arms Race, and Aviation Fighter Jet.
Not to be confused with Spukhaus, another returning Halloween seasonal map.
NEW MECHANIC: ENRAGED BOSSES
We have added a new scary mechanic to Mob-Arena: the ability for bosses to become enraged when they are at low health, making them massively more dangerous! This mechanic is mostly only enabled on higher difficulties, and should increase the challenge of the mode while making boss fights more strategic, as it may no longer always be a good idea to deal too much damage to the boss too quickly. It also gives boss fights an extra excitement that has always been a bit lackluster since the very beginning of Mob-Arena, and additionally the increase in difficulty makes boss fights more appropriately challenging to experienced players as each boss now requires more in-depth planning and strategizing to overcome.
Here is what a very enraged boss looks like:
Bosses gain the following effects from being enraged:
- When enraged, bosses gain Speed II, and use skills 66% faster
- When very enraged, bosses gain Speed III and Strength I, and use skills 150% faster
Bosses will now become engaged depending on difficulty:
- In Normal difficulty, the final boss will become enraged below 50% health
- In Expert difficulty, all bosses become enraged below 50% health, and the final boss becomes very enraged below 25% health
- In Extreme difficulty (available to donors), all bosses can become enraged and very enraged with same health thresholds as above
- In Endless mode, after 5 bosses defeated, bosses will start to become enraged. After 10 bosses defeated, bosses gain the ability to become very enraged!
NEW MOB-ARENA JOINING EXPERIENCE
The Map Selector menu used for joining Mob-Arena has been greatly improved.
It now shows (NEW) and (Recommended) tags on maps to direct players to maps that have been recently updated and have higher-quality visuals and enemy design. It also adds the ability to show a description for maps. The player stats display has also been moved below the map description and player count to reduce visual clutter when players try to select a map to join.
Descriptions have been added for most maps that have been updated on the new map system, though currently the descriptions are not yet linked to the builder system and cannot be controlled by builders – this may change soon, however.
ENDLESS MODE CHANGES
- Creepers no longer spawn with Regeneration or Jump Boost higher than level 1 in Endless Mode.
- This prevents the mode becoming trivial in high waves due to the very high levels of Regeneration that creepers could previously provide to players.
- Finally, the Endless leaderboards are based on skill rather than who can grind the most waves before the server crashes or auto-restarts.
- To counteract the new Enraged Bosses mechanic in Endless mode, boss ability timer now decreases 25% less compared to before based on the number of bosses defeated. This means that at higher wave numbers, bosses now use skills less often than before when not enraged, but more often than before when enraged!
MINECRAFT 1.21.3 SUPPORT
- Support for Minecraft 1.21.2-1.21.3 clients has been added
- Added a new BungeeCord fork which contains some security features
- VPN/proxy block feature was enabled for a few days but has now been removed
- Unfortunately, the Fabulous Mode is not currently supported for these Minecraft versions
OTHER CHANGES
- The Halloween spawn has been enabled!
- The Halloween playlist is back!
- The “Your Stats” part of the Mob-Arena map selector GUI has been improved
- The Mob-Arena boss skill cooldown algorithm has been improved to now only round the skill delay at the end, resulting in bosses using skills slightly faster than before on average.
- The Mob-Arena minimum boss skill cooldown has been reduced from 0.2s to 0.15s to account for the new enraged mechanic. This limit can still only be realistically hit in Endless mode.
DEVELOPMENT PROGRESS UPDATE
In recent months, we have been hard at work on the Place Engine on what is perhaps the most ambitious and impactful feature of our entire project: the Place Scripting system, a centerpiece to both official and community content creation in GunCraft, our future standalone game, and beyond.
As with the rest of the engine, we are developing the Place scripting system completely from scratch in order to allow unique combination of capabilities that are impossible for any other game scripting system currently in existence. Most importantly, we wish to combine the performance, developer ergonomics, and limitless possibilities of native modding with the security and cross-version compatibility provided by a sandboxed scripting environment.
No existing game currently contains a scripting system that meets our goals. For example, Minecraft: Java Edition’s community-made modloaders like Forge and Fabric provide modders with great possibilities to develop anything they can think of, but “native” mods such as these are inherently too insecure for our goals of integrating community content into the official GunColony experience. Even if we implement the best sandboxing practices we can think of, mods could still compromise server stability, interfere with other logical game servers (due to our single-process, multi-tenant design), or even maliciously probe the inner workings of our embedded anti-cheat systems. As our ultimate goal is the easy implementation of modded content into the base game, such security compromises are simply unacceptable.
The other type of existing game modding systems consists of scripting systems like the ones in Minecraft Bedrock, Roblox, and Fortnite. These restricted, sandboxed scripting environments solve the safety problem but come at a considerable cost to game performance, modding flexibility, and developer experience. For example, Minecraft’s marketplace modding system has poor support for multiplayer servers and strongly limits the creation of complex game mechanics, while the latter two systems are not designed for multiple mods to work together seamlessly. Additionally, despite being developed by billion-dollar corporations, all three modding solutions also have limited type systems and lackluster IDE support and documentation compared to the gold standard of Minecraft: Java Edition. They also separate scripts and other game object definitions into different file types (or GUI menus), complicating developer experience.
How will Place Scripting improve upon all these current examples of game modding systems, while being developed by a single developer? Our secret weapon is to leverage the power of Kotlin. In the last update we presented a unique type-safe config format leveraging the Kotlin DSL syntax, where configs are written as Kotlin code, compiled into JSON locally on the modder’s computer, and then safely uploaded to Place servers. In Place Scripting, we extend this idea further to design a custom coding language, letting modders define script expression trees through type-safe Kotlin DSL builders and use a custom polymorphic serialization method to allow such scripts to be uploaded to Place servers and executed, producing arbitrary gameplay effects.
Being built on Kotlin, Place Scripting can leverage many features of the Kotlin language and JetBrains IDE ecosystem, such as a strong type system, inline code documentation, and IDE refactoring features, to provide a developer experience unparalleled by any other game scripting system out there, especially when working with large projects. In addition, despite many language syntax compromises we have had to make due to limitations of Kotlin DSLs, the language is still much more concise than any other game scripting language when programming a given logic due to adopting a similar approach to developer convenience as Kotlin itself, with a large number of functional programming-style utilities available to help simplify code especially when working with collections, as well as support for null safety.
Also very importantly, because both our config and scripting formats use Kotlin DSL, we can uniquely integrate scripting and other configuration files into the same project. This makes all assets in your mod and the base game immediately available for safe reference from scripts, as well as allow you to easily embed scripts to change a game object’s behavior right within its configuration element itself. To see why this would be very powerful for a game like GunColony, think of the configuration of a weapon like AN-94 which, as part of its real life “hyperburst” design, features a higher full-auto rate of fire within the first two shots. In the current GunColony weapon system, we would need to create a new configuration entry in the core game codebase just to account for this one weapon, which introduces unsustainable code complexity over time and is inaccessible to modders. With Place Scripting, we can instead simply write a script, embedded right within the weapon configuration itself, that encodes the following: “when firing in full-auto, if this is the first shot in the firing sequence, then lower the firing delay by 3.3x”. Bingo, we now have a realistically-functioning AN-94 without having to modify the core engine to specifically allow for it! Indeed, the aspiration is that all of our official game content will be encoded in configurations and scripts in order to take advantage of this flexibility, and indeed the same level of flexibility will be offered to modders as well.
In addition, special care was taken to maximize performance, as each script expression only requires the bare minimum amount of logic to keep track of resource limits but otherwise serves as a direct wrapper over a Kotlin function or language construct. With special expression types to fully support Kotlin primitive types and even some complex types like block coordinates being treated as primitive values under the hood, Place Scripting is also designed to produce an especially low garbage collection load, meaning that it is likely to be much faster than any other game scripting system in existence while exhibiting negligible GC pause times. Finally, because this scripting engine is written fully within Kotlin Multiplatform, it is portable to different targets and barring codebase size limitations, may be a viable way to add client and UI scripting support to Place in the future, as well as furthering our long-term plan to eventually support cross-platform integrated servers for singleplayer gameplay.
The scripting system is currently still work-in-progress to integrate it with the Config DSL as well as the Commands system, which will see many of the same code expressions that power Place Scripting become available to use in commands as well, making it available to in-game mappers that do not have access to a desktop IDE environment. Although the development of the system takes time away from other game features, we believe that it will be a central part of our future plans to improve our game sustainably at low-cost through continuously integrating community content into the base game. Because we do need to get the system right the first time – as any changes later on would cause breakage of existing official and community scripts – we will prioritize spending as much time as needed to make the Place scripting system as well-rounded and polished as it can be.
