• 32-bit rendering effects! Shiny gold, glowing fireballs and tracers, etc.
• Much-improved player interface with adaptable pie menus. All relevant commands just two buttonpresses away!
• 32-bit video mode – no more palette corruption problems.
• Enemy spawns are now data driven… Modders: fight against your own creations, just look in Activities.ini
• Memory leaks massively reduced, can play long games without RAM being eaten, and overall memory footprint reduced.
• Several crash bugs gone and other glitchfixes

We’re proud of this one – enjoy!

We have figured out how to keep the entire engine at 8 bits per pixel internally (for manageable memory footprint), while rendering the last step of each frame in 32 bits per pixel to your screen. This allows us to do some nice glow effects in-game, and will eliminate any “crazy color” palette problems that some have experienced with the old 8bpp video mode builds.

You will still be able to turn off the effects and even go back to 8bpp mode in the next build, in case this slows down the game on your machine. We haven’t noticed a huge hit to performance though, so I think it’s well worth it for the extra eye candy.

Also, we’ve been profiling the memory allocations and have managed to plug the vast majority of the memory leaks present in previous builds. This should make longer games more feasible without CC slowly eating all your RAM.

Just wait for the rocket gib/explosion effects coming soon!

… at least not collision map-related ones 😉

After reworking the way movable objects clean up the map, we ran several hours of stress testing of the engine on all the available machines here at DRL HQ:

No crashes or hiccups.

Also threw in a frag counter due to popular demand!

As Linus Torvalds used to say:

“Release early. Release often. And listen to your customers.”

Yes, B15 may have been a little rushed out the door. But we listened to the issues, and here is the fix to most many of them (plus more):

• No more crashes due to corrupt collision map Nope, still have these.. were introduced with the new optimizations.. sorry. Will work on them.
• No more crashes due to out of bounds of the scene (digging off the bottom etc)
• No more crashes due to unknown materials… defaults gracefully to a safe material instead
• Far more optimized version which runs much faster. We profiled the code and nailed a few hotspots which were slowing down things, especially on larger maps. This is what took a bit longer to do than the other fixes.
• Mouse jerkyness completely fixed.. silly bug
• Mouse interface improved.. no more tedious double clicking!
• Many more small fixes and improvements

Enjoy!

Yes, that’s right: The first version of the in-gameplay integrated scene editor is now for you and your friends to have fun with! Co-operate to build your modular bunkers together or against each other before the game round starts, and then blast them to pieces!

As usual, there are many improvements and changes, but (also as usual) we worked uninterrupted all evening, night and morning to bring this to you.. so we’ll add the details later on after some sleep.

The big points are:

• You can now load stuff back into the rockets and ships and recycle them!
• Mouse control EVERYWHERE! Even in splitscreen games, the mouse cursor will stick to the screen of the player who is using it!
• Complete automatic Data Module independence if you stick to the simple modding rules.
• That goes for materials too! Don’t worry about your material indices colliding with others mods’ out there. It should magically work regardless now. (but let us know if it doesn’t…)
• Drawing order and material copying priorities have been swapped between the foreground terrain and the actors. This has a lot of good implications including helping to preserve the integrity of hard walls, possibility of camouflage and hiding, and just generally looking better.
• New grouping system to help organize all the Objects in the game. Note how your mod items will automatically show up in the bunker editor! (See the new AddToGroup property)
• You can set the gold amount that each team gets at the start of the game. Look in Settings.ini. Will hook up to in-menu UI soon.
• So many more bugfixes and tweaks…

The above complex was built in about two minutes with the editor. Pieces and items still cost gold to build, so you have to save some for when the the actual game round starts!

Next up: Making the AI actually able to navigate your arbitrary mazes and find your brain anyway – Coming soon!

So here’s an update on what we’ve been working on. There was a bit of a slump in productivity in June as we moved our offices, but we’ve picked up the pace in the past week.

A big problem with making mods for Cortex Command has been that any new names you defined in your data module could collide with ones found in any other random mod out there. So, if anyone tried to load both your and that other mod at the same time, very strange and unexpected things would occur (someone else’s arms and legs on your guy!). Or just crash the game with little clue as to what conflict caused it.

So we took a break from working on the new editors to solve this problem. Now, user made data modules form their own ‘name-spaces’, and thus can define whatever names they want, as long as they don’t conflict with anything in the official Base.rte module. This means your SuparGun will coexist peacefully with that other guy’s SuparGun, as long as you both follow some simple rules:

• Your instance names can’t be the same as anything in the official data module Base.rte
• In your own data module you can use anything defined in the official module, Base.rte. You can safely make copies or reference them as you wish.
• You CAN’T, however, use anything defined in any data module other than the official one, or the one you’re working on. This would cause an interdependency between two user made data modules, and will cause errors if they get separated. Just put everything dependent on each other into one module… you can organize it thoroughly. Look at how Base.rte is organized for tips.

Back to work on the Scene and Gib Placement editors!

It’s Test Build time! We recommend you uninstall your previous test builds before installing this!

Quite a bit of new stuff in here, but much of it isn’t immediately apparent. Several big changes happened under the hood; examples include the way maps are loaded and the complete reorganization of the material palette.

Some of the many other changes and improvements:

• SLOW CRUSHING OF ANY GIBBABLE OBJECT

• Vastly improved collision detection and response, both against terrain and other objects. Still not perfect, but much better
• Physics simulation and graphical framerate decoupled! This means no matter what your FPS is, the physics will behave EXACTLY the same. No more sinking into terrain because things are slowing down.
• Completely new sets of small gibs and particles
• AI mode control – hold down the switch actor button, and then press a direction to select a different mode for the Actor you’re switching away from
• Your team’s actors are now ordered by their horizontal positions in the scene. Press right switch button and you’ll get the closest guy to your right, for example.
• Much fewer intersection problems with the terrain. Things are not as likely to get embedded and weaken bunker walls.
• ‘Tunneling’ through terrain much less likely to happen
• Enemy AI ships won’t appear directly over your base any more, only on opposite half of scene.
• Long wielded devices are prevented from sticking into terrain; can’t poke a long cannon through walls anymore
• Scene terrains are now simple RLE Bitmaps instead of using weird contour files. Paint your terrain with the material palette and save as 8-bit bitmap with RLE compression, and presto you have a terrain
• Only loads all data once on startup of game, so it’s much quicker to reset or restart the scene.
• …Lots more, going to fill out later by looking at source control logs

What this does NOT have:

• Campaign mode.. saving it for the real game.
• Scene Editor.. ditto.
• Gibbable ships and new ships, working on these, some may appear in next test build
• New guys and guns.. may save for real game too
• Ability to force reload of all ini’s without restarting game, will be in next build.

Also, old mods are unlikely to work with this build! We appreciate the huge amount of effort put into all the modifications for previous test builds, but we just can’t afford to spend time dealing with legacy support of not-even-beta versions! The good news is that mods should be relatively easy to bring up to speed with TB14. Later we will try to post some helpful technical outlines of changes between 13 and 14.

I know some of you are really getting anxious about a new build; here’s the situation:

Up till now the test builds have been a great way for us to evaluate what works and what doesn’t, and with the great community feedback and support we have an idea of what you like too.

Even though the tests have been fun to play in their own right, they were little more than half-finished game engines with some temporary data thrown in to try the different systems out. They did not really represent the larger gameplay design we have planned for the final product. Sure, the gun battles and basic elements are there, but the base building phase and more emphasis on strategy and tactics over twitchy action wasn’t.

Now that we have a framework and and idea of what’s fun, it’s time to build the real game. The project is at a point where we’re taking apart and rebuilding a lot of areas, and replacing most of the old temporary test data with fresh new art assets. It’s just not conducive to putting out tests as frequently as some of you have become used to.

Another reason for not putting out new builds while we’re changing things so drastically is that each one would break all the mods that are already out there.

So, while I will try to keep this devlog a little more frequently updated on things we’re working on, don’t expect test builds nearly as often as before. There may only be one or two left before we put out a version that really starts to look like the final product.

If you can’t handle the waiting, then why not submit your email address above, and give it a break. You’ll get an email every time anything new is announced.

Soooo… this whole week has been spent tearing my hair out over the core physics code. Everything else is being held up by these issues that I’m trying to resolve with the lowest level collision code. Being a physics-based game, Cortex Command’s gameplay is entirely dependent on having this robust foundation, or things really go to pot.

A clear example is the ‘tunneling’ problems, where actors could glitch themselves through the terrain, no matter how hard or thick the materials. The AI-controlled skeleton actors loved to do this in previous test builds. But no more! Although there are still other ways to compromise the terrain through glitches, the major ones have been fixed:

Note how there’s no more tunneling, so the AI enemies have to pile bodies to get over those walls

Also, a lot of time and effort was spent experimenting with having invisible physics springs pulling things apart when two objects started to intersect. The initial method I tried failed miserably, resulting in things being very squishy and mushy feeling. I’ll work more on getting the MO-MO collision responses working better, and see if we can’t get a new build out soonish.

There’s a reason for the unusually long gap between builds: wedding here in the tropics tomorrow, then honeymoon somewhere else. I’ll be back in business in a couple of weeks – although I’m still sneaking in some work on the laptop when ideas for the new collision response algorithms strike!

Until then ~

UPDATE: Thanks everyone for the well wishes and very kind comments! We’re done and married, and will enjoy the relaxing latter half of our two weeks now. 😉