Friday, October 1, 2010

Laptop Friendly

Last post I talked about the game getting stuck at 10 FPS on my laptop. This made testing really difficult, so I went through the code and commented out some of the more CPU-intensive stuff like fog of war. That brought it up to a manageable 30 FPS. Once I've got core game-play fully implemented, I plan on going back through and optimizing that stuff so that it can run on a wider range of computers. For now, it's nice to know that the essence of the game can still be obtained on a weak laptop.

Wednesday, September 22, 2010

Keyboard Controls

Up till now the controller code was pretty shoddy - hacked together to get gamepad input working so I could work on more interesting code. A lack of a gamepad has forced me to have another go at it, which is a good thing in the long run.

The controller code is now a lot more modular, which also meant changing some other parts of the code base that used it. Everything is cleaner, which made it easy to slot in keyboard controls as a fallback when a gamepad isn't present.

"Shouldn't a computer game have keyboard controls by default?", you might ask. Well, Mechanized may be a computer game, but I'm writing it with the main goal to be a release on Xbox Live Arcade and/or to be played in a living room with gamepads like a console game. Also, the gameplay really doesn't lend itself well to keyboard controls.

More back-end code changes are likely to come as I'll be developing on my laptop while traveling. It's a wee Inspiron and has trouble getting past 10 FPS, so graphical elements are tough to test on it.

Thursday, August 12, 2010

Still Alive

I just want to throw up a quick post to say that yes, I'm alive, and yes, I still care about Mechanized. I've been very busy with finishing my final term of university and will resume development within a week. Expect more posts then!

Wednesday, June 2, 2010

Operator.

There are two basic chassis types: ones with rotatable turrets, and ones without. The large size of the sniper and artillery cannons restricts the unit to only firing where it's facing. More mobile units like the Scout and Striker (who I will detail in later posts) can fire in any direction regardless of their facing. This can make driving and shooting a fairly complicated matter.

To ease the interface difficulties, I added an auto-aim feature. By holding down the auto-aim button, a unit will automatically track its turret towards the nearest enemy in its vision range. If more than one enemy is in range, the player can cycle through targets with another button.

The Operator is a special unit type in Mechanized; it focuses on gathering and distributing intelligence to its teammates. Tentatively, it has a radar array and a special aim link system, with the option for a mine-sweeping system.

The radar array allows the Operator to detect incoming enemies on a wider scale than could be seen with its regular vision zone. This helps its team coordinate for pending attacks, and protects slower, more vulnerable units by giving them time to start moving.

The aim link system is the key to the Operator's power - it projects a radius around the unit that, when it intersects with an ally's vision range, links their auto-aim systems together. When allies are linked in, they can choose a target for auto-aim from enemies in the vision range of any ally in the link. This lets the Operator protect long-range fighters like the Artillery and Sniper by keeping them away from the front lines but still in the battle. The Operator can also provide supporting fire for allies in range, allowing it to assist the main offensive strike as well. It's an important unit that must rely on quick thinking and awareness, not armor and weaponry, to win the fight.

Monday, May 31, 2010

Aiming HUD

OK, OK, here's the new HUD! Quit bugging me!

The Artillery unit behaves differently than the rest. It's the only unit that can adjust the distance at which its projectiles explode. The downside is that they won't explode if they come into contact with anything on the way, they'll just sail right over it. It requires more finesse to catch an enemy in your sights but the reward is much higher damage.

To help the Artillery out, I've started implementing a HUD to show aiming related data. In orange you can see the minimum and maximum range of the left-trigger weapon, and in cyan the min/max of the right-trigger. I've yet to add an actual reticle but it will be there shortly, showing where the weapon is actually aimed at.




Turns out this HUD is pretty useful even when you're not playing as an Artillery, so I modified it to show just the max range for other units since their weapons don't have a minimum range.

The art style of the aiming marks give you an idea of where the art direction is headed. The red health and ammo HUD in the bottom left will be replaced eventually with something more appropriate and aesthetically pleasing. You can also see that fog of war is on, with some subtle fading at the edges! Here's a shot of an artillery projectile exploding:


I'll post soon about the auto-aim feature I implemented recently and how that fits in with the Operator unit type. Keep the comments coming and I hope you enjoy!

Tuesday, May 25, 2010

Fog of War

One of the most exciting aspects of a game to me is making decisions with limited information. I knew from the start of development that I wanted Mechanized to have fog of war - a screen over parts of the battlefield that aren't in the player's field of vision. It forces players to scout rather than just rush in blindly, and rewards communication and teamwork.

After some searching online I found Catalin's excellent web site, and particularly his code for dynamic lighting. With some minor modifications I had it up and running really quick to my great delight. The lighting code was also good for learning about different ways to manipulate alpha values in textures to achieve different effects.

I fiddled around with different field of vision textures, adjusting the amount of blur at the edge of the field as you can see in my post about the new art style. With the new look, things are bound to change...

Monday, May 24, 2010

Particulars

When it came time to decide on different types of weapons, I realized that I would need to implement some sort of explosion system, rather than a simple projectile collision like I had to start. I debated having a defined, hard-coded explosion/splash radius, but I was working through a particle engine tutorial (RB's tutorials are very helpful and easy to follow!) to learn C# and decided to try that instead. It looked beautiful for explosions, so I worked it into my projectile system. That was a while ago - today I finally hooked it up so that each projectile checks if it is hitting a unit and actually deals damage.

With the particle engine, I get unique, somewhat random explosions every time, so there's no relying on a rocket doing X damage within a radius of Y. The particles go in random directions, and each carry a bit of the rocket's total damage with them. I can tweak the engine for each weapon type to vary the size, velocity and damage it does. This reduces the need for more complex sprite designs, too. Each explosion is just a combination of one basic shape.

Here is a screen showing all the different particles I have so far:


Please keep in mind that they are hard to catch mid-explosion, and don't look as impressive when taken as a single frame - they are moving, fleeting splashes of color.