Jump to content

  • Log In with Google      Sign In   
  • Create Account

Grand Strategy: Space War

Grand Strategy: Space War - "Mercenaries" -- Log 1

Posted by , 26 June 2014 - - - - - - · 1,176 views


I took a few days off this week. I had promised myself to do some devving on the side this summer, and exposed my thoughts in my previous entry.

I took about 4-5 hours in the last 4 days to look over the dusty code of the now defunct combat simulator for GS:SW and decided to see whether I could salvage it into a spinoff game. Let me examine here the changes it has undergone:

5 Players Mayhem! (Showcased: AIs, but also works as PVP!)

Working Title
First and foremost, I had to come up with a tentative title to label it as a standalone from the original game (which is still WIP). I decided to go with the "Mercenaries" suffix. Why?

I wanted something that would convey the look and feel of what this is about. GS:SW is a 4X game, which implies building an empire at macro scale. Mercenaries is to be much more focused on a single ship and is meant to be an arcade/action type of game. I wanted for it to feel a bit like Raptor: Call of the Shadows and Solar Winds (in which you play a bounty hunter / mercenary of sorts). Decided to come up with the Mercenary code-name for now.

Why plural? Because it will have hotseat multiplayer support of course! (both COOP and PVP!)

Before I could start on actually changing the code base, I had to refactor nearly all classes and debug a bunch of crap I had left behind (it was a prototype after all, which was done as quickly as possible).
I ended up fixing bugs that had eluded me for a long while. I've been a good boy.
That did not amount to much initially, but it really helped me reach the velocity I intended to have (and much faster than I thought!).

In the following 5 hours, I've successfully done:

Multi-player hotseat
There are no winning conditions yet, but up to 4 players can join a game. You might think it sucks to have 4 people crammed on the same keyboard right? Well, because I'm both ambitious and lazy, I wanted to have controller support (gamepads) for this game, but since it turns out it is very hard to implement with browsers, I've been using antimicro 2.4 which is a GNU-licensed software that allows you to map keyboard keys to your gamepad. Not perfect, but definitely much more fun, and also allows 4 people to easily join the same join either as a team or to kill one another.

The best part is how this all works. You could play 1v1, 2v2, 1v3, etc, or 3vAIs. But you could even go as far as:
P1 has 3 AI allied, P2 has 2 AI allied, etc. The possibilities are endless and I'm having a lot of fun toying with game modes.

That being said, choosing to have up to 4 players meant I had to take very drastic decisions early on. One of my original ideas was to have the ship controlled through WASD (W D for throttle, A D for helm rotation) and the mouse to control the weapons (aim anywhere on the map and blast them). Since there can ever be only one mouse, I had to let go of this idea and make a control scheme (and features) that would map to a very small amount of keyboard keys instead.

I wasn't originall hellbent on the idea of hotseat multiplayer, but as I developed the input, it was the first thought that crossed my mind: this would be great as a couch coop or PvP arcade game! Sometimes you just have to follow a hunch and go with it. I felt that, if GS:SW - Mercenaries had a chance to be different than all of the space shooters out there, I had to seize it. This seemed like it, and it gave me renewed hopes that this concept would translate better to a steambox or console (one can always dream).

Modified "Physics"
I wasn't too fond of how rigid the original game felt, but I could live with that. The reason I actually went around and changed it was because, in the original simulator, there was simply no reason for the ships to 'move'. Once they were in optimal firing ranges, all they needed was to make sure their helm was still pointing at their target and dealing as much damage as possible. It didn't feel like it would be possible to circumvent enemy fire and deliver salvos onto their hull.

I've has to refactor the entire movement logic (which turned out to be much easier than I thought, thanks to my very (unnaturally) clean code!). The game now 'assumes' that your ship has thrusters that are used to stabilize it in deep space (effectively stopping your ship altogether), but movement itself may derive slightly from your helm direction because it is somewhat vector-based.

What this opens up is a series of possibilities where you can accelerate and quickly turn your pitch to do some strafing fire on your enemy's flank without fear of retaliation. This is the first major step I've taken to turn this into a skill-based game and the first game design decision I've taken to truly support movement as a key component of this game.

Dummy Balancing
We're still very far from getting any decent form of balancing, but the original numbers (random generators) were simply misleading. Furthermore, they were meant to support a static combat playback, not an actual game.
Quickly after implementing player input, I've come to the conclusion (through playtesting with my girlfriend and brother-in-law) that it didn't feel even remotely close to what I wanted this game to be.

I've increased all firing rates, made ships more agile and faster, reduced the amount of weapons and made some minimal rules for randomly-generated weapons so that there would be some kind of sense of fairness in combat.

Placeholder UI
I've scrapped the original UI that was no longer relevant and put together something hastily to convey the feel of what I'm trying to achieve. It isn't much, yet due to a series of latent bugs, it is the one thing that took the longest to make. It reinforces information that is already on the screen by color-coding players (that has yet to be done on the ship assets themselves).

I don't feel I'm there yet, but I've made some significant steps in the right direction. GS:SW Mercenaries definitely feels different than it's daddy now!

What's next?
I've hesitated between two approaches for this game.
- 1 - Refine/Polish the main gameplay (combat arena) as much as possible to make sure it is fun
- 2 - Build a complete flow of a game mode I envision would work

I've spent a little time following "1" and I feel it is hard to make final decisions on anything until I know what the entire flow would be like. I have way too many header constants that allow me to turn on/off certain features or behaviors just so I don't lose track of them (in case I want to rollback). Overall, it is hurting my code base and my ability to make decisions.
For these reasons, I'll be turning to "2" in the coming days. I'll try to build a game mode / flow / loop and see how fun/addictive it can be prior to revisiting the actual combat.

As per usual, feedback is more than welcome!

Me, taking a beating from a carrier-ship in PvE (1:1)

Grand Strategy: SpaceWar (Spinoff?) and the RubberDuck...

Posted by , 18 June 2014 - - - - - - · 949 views

A year ago, almost day-for-day, I started work on a game project which would later be known as Grand Strategy: Space War.
(Don't worry, I'm still working on that!)

A few months ago, we've chosen to scrap the way the combat system is currently handled because it does not meet our expectations of what would fit within the game. However, there was some good progress made with that and I've toyed with the idea of converting this simulator into a mini-game: a GS:SW spinoff of sorts.

Here's the last video of the combat playback that was published through my youtube channel. As you can see, a lot of it was severe WIP. The simulation aspect was fully functional however, and the code was starting to look good.

Two teams fighting with relatively straightforward AIs. Simple eh?

So I've been thinking long and hard about a way to turn this into a mini-game/spinoff, and here are the dilemmas I've ended up with:

1. Game Type

I'm left with 3 main options that I'd like to explore.

A - Make it an arena-type arcade game where the player spawns at the center, and enemies spawn on the edges endlessly. Player accumulates points by surviving as long as possible, and killing as many enemies as possible.


I get to keep most of the development I've already made.

Additional programming is minimal (Score system, enemy spawners and player).


I'm afraid it could be a bit boring over time and a very short-lived experience.

B - Make it an arena-type arcade game where the player spawns at the center, and enemies spawn on the edges in fixed numbers. Player accumulates money for each kill. If he survives the entire wave, he gets to spend this money on ship upgrades for the next level.


I get to keep most of the development I've already made.

Additionnal programming is relatively straightforwards (except for the entire metagame aspect).


There are a lot of unknowns and I'd like to be sure that the "shop" approach is worthwhile before making it part of the gameplay loop.

C - Make it an open game where the player spawns in the universe and can freely move around. He encounters enemies randomly. I could add shops, etc.


Seems like there's a lot of untapped potential in this idea, and very cool gameplay to make.


This is meant to be a prototype spinoff, and I feel this would require a lot of additional code before it is even playable.

I'm afraid of feature creep and I don't want to lose sight of development on GS:SW itself.

Beyond the game type however, there are a number of other questions that need answering...

2. Player Controls

I've investigated a number of ways the player ship could be controlled, and I'm still trying to find what's the most suitable approach in regards to helm rotation, camera and "aiming" weapons:

Helm Rotation

A - Have the ship's helm rotate based on the mouse coordinates.

This feels "right" and gives some freedom of movement. It might be more intuitive to newcomers and can lead to interesting arcade moments.

On the downside, it would limit my options for aiming controls (see below) and other inputs (gamepad, mobile tap, etc.)

B - Have the ship's helm rotate based on "A" and "D" (Solar Winds)

This can be a bit imprecise and may lead to some frustration. Also, not everyone has a clear understanding of how that works when the ship helm faces south and you press A (it will still go counter-clockwise...)

Definitely not suitable for mobile, even though that's not a current goal.

C - Have the helm adjust automatically by selecting a target (this is how enemy ships AI works: trying to match an angle that's in line with the target).

The enemy ship AI determines a target and moves towards it by adjusting helm as needed. Making it a "point and click" would make this game much less of an arcade game and much closer to a RTS, but it is worth considering the option nonetheless.


A - Fixed Arcade Camera (status quo)

Basically, "as is". the game takes place within the current "box".

I think it suits the game well, but makes keyboard-based controls tougher to implement well.

Opens up Coop and PVP play options.

B - Tracked Camera

Here, the camera always has focus on the player (keeping it at the center of the view).

C - Camera Rotation

Here, the camera keeps track of the player as he moves, but more importantly, as he turns. This effectively means that the ship never turns (always faces up) but that the world around it does.

I feel it could be a bit disorienting in a large map, but could otherwise simplify input challenges.

Aim Controls

A - Have the weapon firing from the ship's front (status quo)

Basically, upon a certain keypress or mouse click, the weapons would fire in the direction the ship is facing. The challenge would be to line-up the ship with its target without having the opponent face you back. It's an interesting premise as it forces the player to flank the opponents to destroy them without retaliation. This is reminiscent of Solar Winds.

B - Have the weapon firing in any direction the mouse is pointing

Would give the player a big edge (although I could grant the enemies the same advantage). Positioning becomes less important, and leading targets becomes that much more important. I feel that it could lead to total mayhem on screen though.

This would greatly limit my ability to do 4 player coop or versus (mouse).

C - Have both (primary weapon A, secondary weapon B) where B is used mostly as a counter to missiles and fighters

Have one keypress or mouse click to fire the main weapon (big damage) which has a fixed orientation (front or sides maybe?) and a second input for the secondary weapon - could be a top-mounted turret - that is particularly useful to intercept incoming missiles. May be adjusted into a gamepad joystick feature.

That's where I currently stand with this, and I thought I'd ask for feedback before making a move.


June 2014 »


Recent Comments