First of all, I want to thank both our existing a new players who discovered us with version 3.5. It was our biggest version in the V3 series so far and we received very valuable feedback that helped us a lot. Thank you! After getting 3.5 out and doing a week of hotfixes, we went back to version planning. The main gameplay theme for 3.6 was already decided months ago, and it's going to be station events. The current invader events are just a taste of what we want to do with this system. We want to expand the variety of these events, and not all of them will involve combat. This is a good moment for it too, with the base station systems in good working order and with a lot more content after 3.5 We also triage small features from our huge internal backlog, prioritize them and devote some weeks to them before we start with the big new gameplay implementation. Here's what we've been doing.

Individual colors for all specs

This was suggested by a player in the forums. Indeed, why have your most specialized officers share an uniform color with your graduates?

Actual gameplay for opening new star systems

The last "cheat button" is gone in 3.6. We've finally implemented the regular gameplay system to open up new systems. We wanted it to have something to do with planets, so now you'll find a new special building in one of the towns in the inhabited planets in any start system:
As the description implies, this building contains the knowledge on new star routes. But you will have to pay for it (in case the planet civilization is friendly to you) or get it by force by destroying the building. Doing so will tank your reputation with that civilization, fast. Which may not be a problem when the civilization is hostile to begin with. But watch out for neutral civilizations!

Small features

Proper naming: A lot of planet objects, and all visitors, had placeholder or boring names. There's now name generators for all civilizations and all planet objects have proper names. Hiring cost credits: Getting officers for free was more of a development cheat. Now officers will cost credits to hire, and the more officers you have, the more expensive it will be. Drunks: There's now a random debuff for entities that drink too much. They may have some problems walking in a straight line... Civs start hidden: In 3.6 only Spatials and Humans will appear in the Civs screen. You will unlock new civs as you unlock their systems. Early visitor exit: A missing but very important mechanic for station efficiency. In 3.5, when a visitor is done of their tasks and completely satisfied, will linger without doing anything until their timer runs out. This is now fixed in 3.6. They will just walk back to their shuttle after they are done. And if all the shuttle visitors come back early, the shuttle will leave and thus make the dock available again. Wallet scaling: Visitor wallet initial balances are now proportional to your reputation with their civ. The more reputation, the wealthier their visitors.

Performance woes

We've know for awhile that game performance wasn't great with a middle sized station. Frame time starts getting too big, and GC pauses start going for too long. In 3.5 this has become more visible than ever since the more polished station gameplay has kept players playing for longer and noticing this problem. This is rooted in the choice of scripting VM made very early in the development of the game. Initially meant to be a way to make mods, it now powers most of the gameplay, with many thousands of lines of code, running for millions of cycles on every frame. It's not a performance oriented VM and it struggles when things get complex enough (which is not much, because we want people to build huge stations). There's some optimizations left to do, and some of them have already been done. But the game needs a tenfold solution, not a 10% incremental improvement. This means I need to migrate to a new VM. Finding a new VM that can interpret the specific dialect of Scheme I am using is impossible. So I either need to rewrite the entire core of the game in another language, or modify an existing VM to be able to run my Scheme code. The only VM that can realistically make the extremely dynamic nature of the Galactology Scheme source go fast is LuaJIT. And, fortunately, there's already some Lisp-like eval libraries available for Lua, along with amazing bindings builders for C++ to connect the VM with the kernel of the game. This means a partial rewrite of the game is looming on the horizon. And I'm tempted to tackle it sooner than later, because every new feature I write, is just adding more technical debt. It is a very complex task and I will have to rewrite thousands of lines, but it's not a total rewrite. In any case, as a very optimistic estimation, this will take at least a month. While this is going not many new gameplay features will be able to be written. The fact the new scripting system will still be able to interpret some Scheme-like source (in addition to Lua!) means I can still do some new feature work as a break from the porting tasks, and still keep that work for 3.6 in case the porting takes too long for 3.6. I've not decided yet when to proceed. On one hand this porting needs to be done, for sure. On another hand, it's feature updates like 3.5 which sell our game for real, with little sales volume between versions or discounts. Delaying 3.6 for at least a month goes directly into our bottom line. If the next development update takes longer than usual, you now know why :)

[ 2017-03-12 21:27:03 CET ] [ Original post ]