A new build is up, these are the release notes.IMPORTANT: Neither the client nor old versions of miranda_setup.exe will work with the new patching data. Testers must download and run the new version of miranda_setup.exe to update the game to the current version. Eventually this will be automated for you, but not today.
The first bug testers encountered this week was me relearning the golden rule: don't mess with the distribution files manually. I deleted a file from the server that I thought wasn't needed, but the installer still expected it to be there so the install failed. Lesson learned.
The first Pre-Alpha invites have been sent and the live server is up and running!
If you're on the very short
friends and family list, you should have received an email with the install link and a Secret Lair Code to create an account.
[Doesn't look like much, but this is the first base on the Live Server.]
There is nothing more satisfying than seeing something you've put so much effort into actually working in a live environment.
So if you're one of the lucky few, give the game a try, and most importantly: let me know how things go.
If you didn't get an invite, be patient, these are the early days. This first test is mainly about finding out if the game even runs on other people's computers.
I was fortunate to receive an SSD as a gift last week. I had long heard that using an SSD made no difference to build times with Visual Studio. But, everyone raves about them so I decided to use the SSD to replace the main drive in my dev laptop. Better boot times are always appreciated. I was able to install the new drive, image it with the standard Dell factory image, reinstall all my software and then wait through 200+ Windows updates. That took about 14 hours. The result though, was well worth the effort. Boot times are under 20 seconds and I got an amazing 44% reduction in build time
from 10:06 to 5:41.
Vendors are finally done! If you signed up for the Newsletter (at the little envelope icon above) you just learned all about it.
Next on the list is setting up the server for friends and family testing.
[Selling components to a Vendor.]
The server software I wrote at EA had a really nice feature: it would display an XML file of its status if you made an HTTP GET request to a specific port on the server. This is handy because it can be used by server-farm monitoring tools or for things as simple as a server up/down indicator. I wanted a server up/down indicator for the theimperialrealm.com
site as well as on the game's login screen.
Adding an HTTP server to the game server's front door was easy, a few lines to parse a new command line parameter for the port number, four lines to add the HTTP server and about 20 lines to output the game status as XML. Easy peasy.
<?xml version="1.0" encoding="utf-8" ?><server><status>up</status></server>
Now I needed to get that status to display in the HTML5 news page that displays on the game's login screen. My whole game UI is built on AJAX and XML, so I figured it would be pretty easy to use the same tools to add a simple up/down indicator. Wrong!
I've been using this for a while, but especially this week so I thought I'd share: it's a class-based state machine. State machines are usually big and messy and awful spaghetti code. Making states class-based makes a state machine cleaner and much easier to follow.
Here's the base classes for the state machine.
When I started developing The Imperial Realm :: Miranda
, Content Delivery Networks (CDNs) were big and fancy and expensive and only used by giant multinationals so I never imagined I'd be able to afford to use one.
With me posting more and more big screenshots on my websites like this one:
[Random screenshot of the week.]
Last weekend I decided it was time to research solutions to improve my websites' performance.
I've been working this week to get combat up and running reliably. It is starting to come together now, at least well enough for a screenshot.
[Things are going badly for Red. Blue is getting a lot of loot!]
I showed The Imperial Realm::Miranda
at Full Indie
again tonight. Just like last time
it was great fun.
I got to The Pint
at about ten after six to set up, found myself a table (actually the same table as last time) and started up the server. As always happens when you want to show someone what you're working on, something immediately went wrong -- the server wouldn't start. I knew it had to do with setting up the game to run standalone with no internet. Firing the game up under the debugger I was able to figure it out just in time for the 6:30 start. It looked kind of funny having 9 instances of Visual Studio running while I was demoing the game. The good news was that once I worked through that little problem, the game ran flawlessly all night.
[During one of my breaks, I took a quick snap of my table.]
Like last time, I talked pretty much continuously from 6:30 until 9:45 (I got just two five minute breaks.) Most people stayed 10 minutes or more and I was often speaking to several people at a time. There are some real serious strategy game fans out there.
If you aren't a programmer, here's a little sample of what we do to make games for you.
Today, at long last, I fixed a bug that goes back to Christmas 2014. The bug first appeared right after I updated the renderer
for better performance. One of the things that that change added was a hard limit to the number of shader programs the Lair engine could support: 4096. I figured that should be lots since I only had a few hundred shaders even with permutations. One afternoon while cruising over Miranda, the game halted because it had hit the limit of shader programs. I was shocked. But when I looked into it the reason became readily apparent: I never released shader programs from materials when they were unloaded. It was a simple oversight, quickly rectified with this little bit of code:
void Pass::ShutdownProgram( void )
if ( mProgramId == 0 )
if ( mGeometryShaderId != 0 )
mGlShaders->DetachShader( mProgramId, mGeometryShaderId );
mGlShaders->DestroyShader( mGeometryShaderId );
mGeometryShaderId = 0;
if ( mVertexShaderId != 0 )
mGlShaders->DetachShader( mProgramId, mVertexShaderId );
mGlShaders->DestroyShader( mVertexShaderId );
mVertexShaderId = 0;
if ( mPixelShaderId != 0 )
mGlShaders->DetachShader( mProgramId, mPixelShaderId );
mGlShaders->DestroyShader( mPixelShaderId );
mPixelShaderId = 0;
mGlShaders->DestroyProgram( mProgramId );
mProgramId = 0;
Now I was destroying the shaders and programs when they were no longer needed. Problem solved.
Then the Bad Bug
Thanks so much for letting me know of the problem. I looked at the server log and you appear to have arrived from a direct link to page 6, which would account for what you're seeing. Maybe check your bookmark is just http://onemanmmo.com/
I think your web server clock threw a wheel. Suddenly your 2016 posts aren't at the top and 2015 ones are. For a while the IT post was at the top, now on Aug 9th the April 2nd, 2015 post moves to the top as if it were brand new. At a guess, the ...
Both buildings and vehicles capabilities are based on the components chosen for them so all the things you describe are currently possible, although I don't have as many component variations as I'd like yet.
In the final design, partially filled harvesters can happen. While there is still a timer to tell the harvester when to leave, if the field is low on resources the timer is shortened, also the player can tell it to leave and it will leave with a ...
Any thoughts to expanding base design/building using components? Possibly as a future feature or expansion.
I'm a personal fan of the Tower Defense genre, which origin is attributed to RTS - specifically the Autumn Tower Defense level in Warcraft 3. ...