I had planned to add a bunch of new units to The Imperial Realm :: Miranda
next, but when I started to work on that, I discovered I hadn't actually figured out how best to do that, so instead, I've been doing a few little things while I thought about it.
[Shields, Territory Capture & Unit Caps]
One of the most common attacks against an online game is to use a program like WireShark
(which is awesome) to figure out the networking protocol and then use that knowledge to gain advantage. One common example of such attacks is the dreaded aim-bot
(this one's for Quake) where a computer program aims and fires perfectly for the player in a multiplayer game. Tools like this one also able to gain additional information for the player that normally wouldn't be available to them (like the location of players hidden by walls.)
After today, such attacks will be much more difficult on Miranda because communications between the client and server are now encrypted.
I'm not going to say too much about how it works, but I read a bit about game protocol encryption and it basically comes down to using a fast symmetric encryption algorithm, have different keys for every session, and if you can, use an expert's implementation (don't roll your own.)
Traditionally Command & Conquer doesn't have a unit cap (other than C&C4 which we'll ignore because it's awful) so up until this last week I hadn't thought too seriously about a unit cap in Miranda.
I've been replaying Homeworld (Homeworld Remastered) this last week and one thing I had forgotten about that game is that it has hard unit caps. The unit caps are fairly generous, but nevertheless there are caps (only 6 destroyers! can you believe it?) The reason behind the cap I suspect, is because unlike C&C, units carry over from mission to mission and the designers didn't want to make it too easy for the player to steamroll the AI by simply capturing every ship put against her in the earlier missions.
Homeworld's unit cap is per category, so 6 destroyers, 100 fighters, 16 salvage corvettes, etc. They are reasonable limits, but an average player is going to have to work within these limits eventually.
At the moment Miranda doesn't have a unit cap (other than a limit of 16 construction buildings per category which is purely a UI limit) although I always figured I'd need to add an upper limit at some point. Reasons to add a unit cap include:
- Miranda is more like Homeworld in that players keep their units indefinitely, they aren't given a clean slate before each mission like Command & Conquer.
- Limits force players to make choices - which are always a good thing.
- A cap mitigates force-size imbalances between new players and experienced players. Experienced players will have cooler units, but not a crushing numeric advantage.
- A plague of cheap tanks. A cap would prevent the pathological case of a player creating tens of thousands of units (tanks/superweapons) and using them to annoy other players.
- Load time after login is directly proportional to the number of units the player has.
- A player logging in with 10,000 units may cause performance problems for other players on the same server.
- A cap limits storage/bandwidth costs per-player.
The only really compelling arguments I can come up with against unit caps are:
- They suck!
- Command & Conquer doesn't have them.
So what do you think about unit caps in Miranda?
Once I got the server up, the next thing I wanted to tackle was revamping the design for combat. The original combat system was sort of rock-paper-scissors-lizard-spock. It worked, but it was a little too complicated for people to be able to figure out intuitively.
The new system is based on the design of Red Alert 2. Each of the 6 types of units (construction buildings, ATV's, tanks, utility buildings, air and superweapons) has one of three armour types (light/medium/heavy.) Players will be able to figure out quickly which weapons work effectively against which unit types.
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 say iconography I think I'd include art styles like FTL and other reusable component based artwork. i.e. I really mean non realistic representative artwork. I think people forgive less advanced art design (and some cases love it with the ...
Thanks for the suggestions, but even iconography would only get me so far given that units are made of 6 different components and each of those components can vary in power and effects. One day I will have an art team!
Players killing less-useful units is what I would expect, and since when you dispose of a unit you only get a fraction of its original cost back, that also works as a money sink.
The plan is that players will want to use more exotic units as they ...
This might be a little radical for this stage of the project, but have you considered having iconography for units instead of actual models?
It might detract somewhat from the atmosphere. However if you don't have the time/skills to create a lot of ...
The oversupply of money problem is why WoW has money sinks for various cosmetic and non-essential (but useful) items. The alternative of course is separate currencies (i.e. "food" limits) that perhaps money can influence but only to a certain degree ...