We’re moved to mono, like fully moved. Now we’re working on polishing the things we half added while waiting on shader fixes. Details follow.
We took all of our projects, which were XNA game studio projects in SVN and copied them one class at a time to new platform neutral projects on github. It took a lot of work to get them compiling and we had to redo the process more than once on account of the XNA game studio plugin’s viral nature, but we’ve actually had them compiling and running on Monogame for a good while now. The main issue we faced, as stated before, was that shaders written for XNA were drawing exactly nothing in monogame and had to be tweaked or reworked to get them rendering again.
Shaders were Jan’s area of expertise, and he was distracted by the final month of his masters thesis program at university, so I got started on some other projects and had a bit of fun here and there adding things that didn’t require artwork. You’ll notice some of them, for instance terrain generation got a major face lift for both the arrangement of asteroids in space, and the interiors of asteroids when you go digging. I also made a fancy framework that allows inventory items to exist outside of ships and float around in space, so don’t be surprised if you split a cargo ship in half and suddenly its cargo is spewing out everywhere for you to scoop up.
I’ve also added a bit of framework stuff for ship status effects and thread interaction that is going to allow the UI to display a lot more information about what your ship is doing, and is going to give the game better control over what is going on inside your ship. This was all stuff that I knew would be needed for the UI, like the ability to see how much energy your engines currently have, or how much your max speed is reduced by status effects. The solution was made pretty general as usual which means it’s very powerful and should allow the new interface to do lots of cool things.
Did I mention that while I was bored I added keybinding support? Man I can hardly keep track of all the things that are going into this update. Speaking of which, time for a tangent relating to that other thing that went in recently…
My last blog was probably an indication to you that I’ve been working on ship design elements in singleplayer. That’s since been mostly finished and tested, meaning it needs to be debugged but all of the basic use cases are functional now. You can unlock any ship during gameplay using the new file structures for ship unlocking, and once you have unlocked the ship design aspect of the game you will see new options when trying to spawn a ship that allow you to copy an interior layout to a new design and edit any design other than the default. The primary difference between ship design in single player and the ship designer/editor sandbox is that in singleplayer you can only remove modules that you have the blueprints for.
Why?!? you may be asking, would you be restricted to only removing modules that you have unlocked? Well, there are actually lots of reasons and we thought about this a lot. One reason is to add design constraints that ease people into the mechanics of ship design early in the game. We know it is quite daunting to be shown an empty canvas and a list of modules and have some tutorial tell us “build a working ship” especially when ships have so many interdependent parts and complex requirements. Instead, this system should give you a working ship early on and allow you to tweak a few key modules at a time to learn the mechanics at a pleasant pace while constantly unlocking new possibilities. Hopefully by the time you have unlocked everything you will really be ready to design your ship from scratch and erasing everything will be a satisfying achievement instead of a frustrating mistake.
Another reason we chose this restriction is that we want to make ships more unique than just shapes and colors, and that means we need ship specific modules. Now, I’m a fan of data driven design and insane general solutions that allow more possibility than functionality, so the engine itself honestly doesn’t even know what a ship is aside from the sum of its modules and ship specific modules doesn’t make a lot of sense in that context. However we’re trying to build a game on top of that engine now, so it’s time to add some restrictions and constraints. After all, one of our kickstarter stretch goals was spinal mount weapons, and those certainly seem like something that would not easily be moved from ship to ship. Our vision of a spinally mounted weapon is a bit of a misnomer since what we are really imagining is a weapon built in space, with some ship parts attached to it radially. We should have called them radially mounted ships.
So some ships will now be able to have modules that can never be removed, modified, or placed by the player in singleplayer meaning that those ships can have unique abilities and functions specific to their hulls. This will hopefully make it more interesting to find unique ships floating in space even after you’ve unlocked all the standard modules and hopefully will add more importance and diversity to ship hulls overall.
So if all that is a summary of what I did while Jan finished school, what are we doing now that Jan is back?
Well, as of a week ago we have all of our shaders working fully in Monogame the game renders all the stuff now! Our steady stream of profanity-chat has since been directed towards the creation of some new shaders which I think I’ll announce after you see them. While me and Jan may never agree on the issue of caffeine vs taurine, we will both agree that shader debugging requires one of those plus a healthy serving of profanity and liberal sharing of this meme. We’ve unlocked an entirely new world of both frustration and possibilities with the new shader model and things are already looking a lot better…like a LOT better. I’ll post a list of the new stuff we’ve added once it’s all in there and you are oogling at the spectacular new visuals.
I’ve also got access to UI artwork now, so I’ve finally started the project that was supposed to be the point of this whole massive update. Navigating your ship is going to look a lot cleaner, and you are going to have access to a lot more information about your ship and its systems. Note that we are probably only going to be overhauling the ship navigation screen and some of the game menus for this update. I’d like to have every screen in a state ready to be shipped, but since we aren’t feature complete yet those screens are still being changed too rapidly to nail down with a proper interface right now. The good news is that we think we ‘ve finally settled on a stylization that can be replicated through the rest of the game, and that means future UI work will require less pacing around and cussing for us to design.
The biggest task with regards to ship navigation UI is finishing up the frameworks that will allow interaction with your ship interior while flying. That means crew information and system information needs to be processed and viewed while flying and I’m building some new systems to accommodate that. These changes are also going to tie into the bridge modules as they are your primary portal between the ship interior and exterior. In the future, different bridge modules are going to allow access to different amounts of systems inside your ship. You will have a hotbar for interacting with some modules during flight that are going to add a lot of depth to both ship design and combat while making ship control a bit more intuitive. “All power to engines” is a very complex type of thing to implement when power flows and paths through a dynamic network of conduits on another thread, but none of that needs to be confusing to the user, the new UI should let you do that with the press of a button, and so much more.
I’d say we’re easily more than half done with this thing. We are now working through the todo list to finish up the big projects that got started so we can get the game back into a playable state for testing. I’d really like to have 0.3.0.00 out before mid July, but since the last step is testing and debugging that also means the last step has no simple time estimate. The main source of delays that I can foresee is that we might decide one of these new systems warrants putting in more content before release.
I’ll try to keep posting updates, but feel free to contact me with dev questions as well.