Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.






GS:SW "Mercenaries" -- Log 2 - "Let there be Game!"

Posted by Orymus3, 17 July 2014 · 450 views

"Let there be Game!"

I was hoping to get this done much earlier, but a lot got in the way...
Coming in, I knew this was going to be a tough/long stretch. I wanted to work more on the combat aspect of the game, but I knew I needed to lay the foundations of the 'game flow' before that, so I set out to do just that.
Without further ado, I give you, the game flow (at least, for the 'Arena' game mode).






Game Flow
When I chose to turn this prototype into an actual game, I had a rough idea of where I wanted to go with it. Solar Winds and Raptor: Call of the Shadows have been my two main sources of inspiration for this installment. Of the two, Raptor was simpler to replicate in the short term (Solar Winds has a more adventure-themed type of gameplay).

To mimick Raptor, I had to come up with a simple routine where the player would organically switch between levels and some form of shop system. The idea is that the player is sent on missions, accumulating cash, and spending it to further upgrade its ships. To do this, I needed to implement a lot of UI which I hadn't done up to this point. It took a lot of re-engineering to get there (it was a prototype after all), but here's the rough cycle the player goes through:



- Main Menu / Landing Page

The player enters the game through this page and chooses a game mode:


- Arena: This is the game mode I've been focusing on. It is a single player (and possibly coop multiplayer) mode in which the player accumulates money in 'missions' and uses it to buy upgrades. It uses a fixed camera and an enclosed combat area (the screen) much like earlier titles (pac-man, spacewar!, etc.) It is meant to have an arcade feel to it.

Enemies spawn in waves, which the player defeats, until the mission is over (all enemies have been killed) or the player is damaged. It allows me to introduce enemies of varying strength and even bosses.

I'm still unsure how I'll handle player death however...


- Skirmish: This is very similar to the Arena except it is actually a PVP mode. All players join the game (preferably using controllers) and choose a custom set of ship components 'on a budget' and fight it out to determine the winner. Can easily implement team-based combat as well. From a logic standpoint, it is almost exactly the same thing as the Arena, only the pre-combat UI varies, and the actual play experience.


- Campaign: This is a mode that will be developed in the future based on Solar Winds. I've toyed with cameras a bit (just enough to make a fixed one) and I know this mode will require a camera that tracks the player's movement efficiently. It is relatively straightforward, but it takes time, and I'd much rather invest time in a simpler design for now and see where the fun factor lies.

I'm hoping this is the mode that will be the most engaging, but I'm glad I get to provide other less immersive modes earlier.



- Single Player setup screen / "Shop Screen"

Once the player has selected the Arena mode, he is prompted with a screen (WIP in the video) that allows him to choose the gear he wants to bring with him. The left side of the screen displays the available inventory (combines everything the player currently owns in storage and everything available for purchase) while the right one displays the current ship gear.

The system is rather simple to use and borrows from RPG inventories. Simply drag from left to right into the appropriate slot and the content of the slot will change.

Currently, all slots are fixed, but my intent is to 're-populate' the actual slots based on the hull selection. If the hull tolerates two weapons and not just one, a new container would be created to accommodate for the change.


- Victory Condition (Combat)

Combat begins, and a victory condition is set (generally, being the only side with any remaining forces, but could also be things such as surviving for X seconds).

I've put a placeholder HUD at the top which displays the cumulative life gauge and shield points for each team (the player is in the first slot, and the aggregated enemy ships are currently in the 2nd, but this will be changed in the future as enemies are bound to be added in waves).



- Outcome screen

Once the combat is over, a result screen is displayed. It tells the player stats about the match, and what he gets from it (money essentially).

Currently, the currency system is just an embryo (every kill nets the player some $) but ultimately, it will be used to unlock new gear in the shop, completing the gameplay loop for this mode.

If the combat ends in a victory, the next combat will be harder, otherwise, a different combat with roughly the same difficulty will be fought next, with un-determined consequences for the recorded loss (I'm still debating whether I want this to be a perma-death / arcade-style game, or a bit more casual / forgiving).



Metagame
One of the most important changes I've had to do in the last 2 weeks was the conversion of the current 'dummy data' into a more elaborate and yet flexible metagame data structure.
As can be demonstrated in the above video, ships are now assembled from a list of components that are selected by the player, and these components persist in memory thanks to that new data structure.
It took a while, but it works great and it helped clean a lot of my prototype code into something much more intelligible / malleable for future implementations. It also forced me to slash my original game class into more specified classes: originally, as this was a prototype, the game class was handling nearly everything as far as game flow is concerned. Now, everything that occurs during a combat is a combatSession that is created from the Game instead. Semantics, I know, but it does make it a lot easier to work with!


Couple of other things I've glossed over:

- Bullet spawning positions (automated template)

Now, ship weapons that fire more than one ammunition with each shot will fire in preset orientations. This makes each attack more predictable and reliable.


- Accuracy variation

Although latent, I've implemented a system that cares about the accuracy of a weapon. It basically derives the course of a shot by an angle based on how accurate the weapon is. I have a few ideas of how this would be best used (shotgun-styled weapons) but I did not want to enabled this feature for now given how low-profile it compares to other development I need to do.


- Weapon Swap / 2nd weapon / Secondary Fire Mode / Special Trigger

I've mapped controls and modified all game systems in such a way that these would be relatively easy to implement (swapping weapons would be laughably simple actually) but I'm still thinking about what's the best approach here.

On the one hand, Raptor: Call of the Shadows' main weakness was the ability to have multiple weapons but rarely ever using this feature (except when purposely cheating the weapons cooldowns). I want to avoid spending time implementing a feature that looks good but serves no purpose.

Solar Winds provided a limited use for this by giving the player 'missiles' which were limited-ammunition power-weapons. My system is already accounting for ordnance (but never decrements it) so this would be easy to implement, but this would have an impact on my current approach to this game.

I'm also interested in seeing possibly 2 weapons firing at once, allowing the player to determine what's the best 'pair' for their ship (similar to how Silpheed did back on D.O.S.)


- Dampeners

I've modified how physics worked in my game to give it a more 'space-like' theme. I've also mapped an input key that allows me to modify the 'rules'. When disengaged, the dampeners allow the ship to drift endlessly in the direction it was moving. Re-engaging the dampeners seeks to put the ship to a halt. While dogfighting, a mix of both allows for the best manoeuvres and offers the skilled pilot with more 'lethal' opportunities against the enemies. It is also an element the AI cannot use efficiently, so it gives players an edge, and makes PVP that much more different than Arena mode.


- Weapons: How far can I go?

I've shelved a lot of ideas for later on what to do in terms of weapons (*cough* cluster bombs *cough*) but I still wanted to get an idea of how malleable my current implementation was. Turns out I can actually make a laser without much effort. It is not fully functional as it will require a few modifications to my collision algorithm, but I was surprised to see how 'easy' it was to implement.


Lastly, I've done a few fixes and tweaks, most notably:
There are no longer any 'ghost' ships (ships that were half dead so to speak and rendered victory conditions useless). This bug had been around since my early inception of this game, so it was quite a kill!


At the end of this 'stretch' I've got less clarity about where to go next. I should probably polish what I've just done, because it feels very raw (despite also being placeholder). My gut tells me however that I need to fully implement the 'Skirmish' mode now so that I can retain parity between single player and PVP and avoid bad surprises down the road.

Cheers,

Orymus




November 2014 »

S M T W T F S
      1
2345678
9101112131415
16171819202122
23 24 2526272829
30      
PARTNERS