Update 1.29.2: Community Maps Update
AUG 6 2025
Hello all,
Today’s update expands GunColony’s community map pool significantly by bringing 3 new community maps to the game! We also share our latest exciting technical development updates in this blog post.
(A new, massive resource pack remodels update will be coming soon!)
NEW COMMUNITY MAP: BLUETOWN
Bluetown is a medium-sized map by SmhBlue, taking place in a sprawling, neon-themed urban environment. It is available in Team Deathmatch (8-16 players), Domination (8-20 players), and FFA (4-12 players).
NEW COMMUNITY MAP: RUSH
Rush is a small map designed for 1v1 matches by Bentpaper. GunColony currently does not have a dedicated 1v1 mode since we still need to refine our server infrastructure to allow spinning up PVP lobbies on demand, so the map will be available in our regular gamemodes at low player counts instead.
It is currently available in One in the Chamber (2-4 players) and Elimination (2-4 players, most likely to appear at 2 players).
NEW COMMUNITY MAP: MOROSCO
Morosco is a large map set in a mountainous forest featuring a great deal of verticality, built by Estelliarmus. It offers both teams multiple approaches to the central mansion and unique sightlines that overlook large parts of the map, allowing for a dynamic mix of long-range sniper battles and close-quarters combat. It is available in Team Deathmatch (12-24 players), Mine-Spades Domination (12-24 players), and Defusal (10-24 players).
OTHER CHANGES
- Community Maps will now have a temporarily increased chance of 1.0x to appear relative to other maps, rather than 0.3x. This will be restored after a limited time.
- Hotfix 8/6/25: Added some bonus limited-time playlists on Sakura map for totally no particular reason, enjoy throwing the mini nukes you get from killstreaks
- Sakura MineSpades + GroundWar scenario
- Sakura Aviation + FighterWWII + GroundWar scenario
- The July 4th event has been removed
DEVELOPMENT PROGRESS UPDATE
June and July have been some very productive months for the development of the Place engine. After lots of preparations, refactoring, and proof-of-concept projects, we have settled on a new design for creating a next-generation content system and SDK (Software Development Kit, or modding tools in other words) for Place that allows creators to develop in-game content using Kotlin DSLs and scripted code.
There are significant technical differences between the new Place SDK design and the previous Place Config DSL, driven partly by a desire for faster realistic development timelines (to avoid, ahem, the Hytale situation), but mostly by the rapid advances in generative AI coding tools that have both made it much easier for us to develop compiler plugins powering our SDK and added new design implications to the final product. Our previous design involved a custom scripting language, Place Scripting, implemented as a Kotlin DSL which compiled the modder’s scripts into JSON to be processed by a custom runtime parser in the server. This design had many preferable attributes such as type-safety, runtime sandboxing and control, and integration of code and configs in the same file, but also had major drawbacks such as the need to design an unconventional scripting language from scratch with awkward syntax.
Our new design preserves the benefits of the previous design by keeping the JSON intermediary format, but replaces the custom scripting language by letting modders develop mods in the full Kotlin programming language. We achieve this while keeping a custom, secure runtime by using a compiler plugin to extract the Kotlin code (more precisely, the intermediate representation in the compilation process) and transpile it into our custom JSON code representation format. We have also improved the runtime design, which now uses Oracle’s Truffle language implementation framework on the JVM target to achieve state-of-the-art performance with relatively low additional development effort, while retaining a pure-Kotlin interpreted runtime on other Multiplatform targets.
Notably, the current scripting runtime design in the Place SDK is only in a proof-of-concept stage and does not support advanced programming language features yet. However, by making the decision of using the existing Kotlin programming language for modding in Place, we are now able to postpone the full secure script runtime implementation to post-launch of GunCraft, considerably speeding up the launch timeline for the standalone game and giving us a better chance of releasing an early version in time for the original 2026 timeline. Since we want to create the official content of the game using the modding SDK as well, in the previous Place Scripting design we would have had to finish the scripting language before we could start working on the game content in it, but now by using the Kotlin language we can start working on official content and have them be compiled into real (non-sandboxed) Kotlin code for now, which works just fine for official content, and then work on completing the secure runtime only after the standalone game’s initial launch when we want to start working towards community mod support.
Other than this speed-up in the standalone game’s launch timeline, the most important benefit of using the full Kotlin language is that we can take advantage of the syntax of a popular, existing type-safe programming language, rather than having to invent our own type-safe scripting system, which entails several benefits for the project. First, Minecraft mod developers are already familiar with JVM languages such as Java and Kotlin, and due to Place being a voxel game similar to Minecraft and encouraging open-source, collaborative modding in a similar vein as the Minecraft modding community (and unlike commercial gaming platforms like Roblox), it is very advantageous for the community to make it easier for experienced Minecraft mod developers to start modding on Place. In addition, modern generative AI tools are more accurate and make fewer mistakes and hallucinations when working with a common, well-known programming language and associated tooling, compared to uncommon or custom languages. Having good support for AI coding tools was already a goal of the previous Place Scripting system, reflected by key features such as type-safety (moving LLM hallucination errors from runtime to compile-time) and the support for defining related configuration and code in a single file. This new migration to the Kotlin programming language should further our efforts by increasing the accuracy of AI coding tools, making Place the most AI-friendly game scripting system on the market, which is extremely important for the success of GunCraft given that we expect most mod developers to be heavily assisted by AI coding tools by the time Place modding becomes public in or after 2027.
The configuration DSL part of the Place SDK design has also received an improvement. We have leveraged the Kotlin Symbol Processing (KSP) framework to develop several internal code-generation plugins that dynamically create convenient and type-safe user-facing DSLs for creating game objects, defining their stats, and accessing the stats from script code, given simple-to-define template files. Under this system, each game object in the template generates three DSLs: one to support the initial mod object definition format, a second to support cross-referencing game objects in the definition process of other objects, and a third to access stats during scripted code blocks. This logical separation lets us expose exactly the right API to the modder in each situation; for example, the modder can mutate stat values of a game object during its initial definition code block, but not anytime outside of it. In addition, by using code-gen compiler plugins and game object templates, we achieve this extraordinary type-safety and convenience without requiring any additional ongoing work when developing the Place engine.
This focus on engine internals will soon result in major new improvements to GunColony. We are now working the first step of the plan: migrating our current Place-powered block destruction system in GunColony to use the new Place SDK for all block stat definitions. This migration will not add new features but will help us test and improve the stability and developer ergonomics of our approach. The next step is to develop a full mob system powered by the Place SDK to replace our existing MythicMobs plugin, complete with scriptable mobs, items, and mob skills and type-safe cross-references between them; this system will even be extended to Mob-Arena bosses and boss skills in the future. This system will give unique capabilities in mob behavior and AI in GunColony’s Mob-Arena mode that are not found in any other Minecraft server using commodity plugins, and give us a path to replace legacy MythicMobs extensions to allow an update of GunColony to the latest Minecraft versions in the near future.
