Updated Game-play Video

So here’s the latest footage of game-play, very close to complete, just bug fixes left really.

Change list:

• Fixed UI elements to make them sharper, particularly for up-scaling on the PS3.
• Lasers now have a short “power up” window, before then  extending until they hit the player or a shield block.
  This means you have a chance to avoid them.
• All controls are now more responsive:
  Inertia is reduced, player control is less “floaty”
  Button presses are now handled better, some times single button presses for things like the shields or target swap weren’t being picked up, they are now.
• Firewall power-up now protects against lasers.
• Menu elements have been fixed up to be clearer and consistent in appearance and position.
• Enemies now take a very small knock back when damaged.
• Enemies now display their health bars briefly when damaged, indicates that your actually doing something.
• Hit boxes have been adjusted to account for some previous problems with bullets missing.
  Same goes for lasers, but they were actually hitting too often. reduced the hit-box width.
• Point blocks now track towards the score bar, rather than the player.
  In almost all play testing the player was initially afraid of the point blocks, they thought they were enemy bullets.
• UI now displays relevant controls
  Triangle always displayed as the Shield Toggle
  Square displayed for draining, when no powerup is active/ready
  Circle is displayed for activating abilities when one is ready.

Not Seen/Inprogress:

• Bosses are now working, currently testing and bug fixing them before i grab some footage of them.
• “Stun” power-up works, but could do with some edits in terms of visuals, current state could be confusing to the player.

Menu Art Fixes

So here’s just a quick post to try and spur me into posting more material in the run up to efforts to get this game published.
Most changes and posts from this point on are going to just be detail the various fixes and changes going into the final submission.

Here’s one of the most obvious fixes, text/icon glow:

Before…

After…

I really wasn’t happy with the quality of the menu’s, especially on the PS3;
The art in the game itself up-scales very well, it all looks very crisp, clear and almost as if i’d made it that high quality…
The menu’s however, and some UI elements (fixed them a while ago) had problems with soft edges and glow. When they up-scaled they looked somewhat blurry and.. naff.

The solution, no more fancy Photoshop glow effects!
The text for menus now uses a simple drawn “glow”, its clearer and it up-scales well.
I also took the time to make sure all the menu items lined up properly.

I’ve done the same for the the level icons:

Before…

After…

So im not entirely sure if the glow on the numbers themselves works…
But the general effect is better, and the “selected” versions are far easier to tell them apart from the unselected ones.

Technical Requirements Checklist

So i’m now very close to submitting my game to Sony!

This isn’t the same as releasing the game however…

It will most likely fail the first time, and in fact we are counting on it!

Why?

Well it gives a little more time for play testing, but also we doubt that everything will be 100% to the letter for the submission requirements, its VERY easy to fail them, but at least we’ll have the feedback to know where we fell short.

This could be anything as minor as having the wrong version number in my submission, or as major as the game hard crashes.

The latter is what I definitely don’t want to happen, the first is just kind of annoying.

There is a huge list of requirements to meet for my game to be published, and this list is called the Technical Requirements Checklist (TRC).

Turns out all games with auto-saves MUST have these, Sony’s rules.

Luckily as i am producing this game as a Minis Title, a lot of the sections are irrelevant, the Minis program doesnt allow for network or game sharing elements, so the requirements for those aspects can be ignored.

The big items that i am in the process of ticking off are to do with warnings, save games and memory cards.

There are also sections relating to branding and image for any elements to do with Sony.

Thankfully I’ve not had to make any changes to meet these standards, keeping a consistent and recognizable design in terms of tutorials and controls display helped.

That’s all for now, ill try and get a new video up soon too.

Timing and Update functions

Time for a wordy post, as pretty much my whole day has been focused on converting code and very little visual work.

The short of it:

My game’s update mechanics are now time based! Fluctuations in fps should now impact game-play far less if they happen, and u also values are more meaningful and easier to balance!

The mistake i realized while writing this post:

I was using the time elapsed since the last frame, NOT the time since the last update.
Now that ive swapped to using the time since last update (which is updated with the time since last frame) the game play is soooo much smoother across the board.

The longer of it:
Originally my code used a very simple and fast method of timing, integers, each frame I would subtract 1 from the relevant timer(s). Zero meant something happened, or if I wanted to I could check other whole numbers for an event.
This worked great if every thing ran at a constant 30fps and I used multiples of 30 as seconds.
But it doesn’t work well in practice, more often than not I’m running at more than 30, I was running at roughly 90 most of the time, un capped.
So with my 60fps cap all the speeds were off.
But if I adjusted the integers for 60fps then any drop slows down the game…
For example the tutorial text rendering drops the fps to around 30on the psp.

The solution, track everything as seconds (suddenly all the values make sense in your head) and store them in floats.
These floats, instead of ticking by an arbitrary value each frame, are actually adjusted by the time since the last frame, meaning if a frame is slower or faster than average it doesn’t matter to the calculations.
Similar to the timers I did the same thing for movement, objects now move based of distance per second rather then distance per 30th of a second.
Backgrounds too are now uniform across the different menus, regardless of how much additional UI is being rendered ontop

Picture Time:

Move Tutorial

Shields Tutorial

New Levels Screen

Tutorial Level

So now that the levels are setup I decided to turn the tutorial of the game into it’s own level.
Originally it was just an intro section to the first level.

Having it as its own level gives me more control over how it works, as it will work rather differently to a normal level>
Additionally I prefer the design that means a player can go back and replay the tutorial at any time.

Below are the current “lessons” in the tutorial, i haven’t included one for movement at present, unless user testing proves otherwise, it shouldn’t be needed.

Just to compare, here is one of the old style tutorials:

The old versions did display an image to better show the result of the instruction, but this did mean it being superimposed over the whole screen, and having to be closed to continue.
The new ones will be displayed on screen until the action has been performed.

Adding the tutorial level in has meant having to edit and shift around the levels screen, but that had to be done for a few other additions anyway, more on that later…

Save games

So another addition that i haven’t blogged about yet despite doing a while ago is the save functionality.

Saving.

The game uses auto-saves that save at the end of each level or when you die;

If you complete a level that you hadn’t beaten previously it updates your save to show that progression, and update the highest score if it is a new record.

If you die, but have a higher score than previously, it updates your highest score for that level.

Loading.

If you haven’t already loaded a game from the main menu you are given the option to load a game, doing so will load the save, unlocking any levels that you have progressed too, and their highest scores.

If you have loaded a game and return to the main menu for any reason then you will see the “Load Game” button has become a “Continue” button, this will take you back to the level menu.

New games.

If you have no save games available the New Game option will be your only choice to play the game, Load Game will not be select-able.

If you do have a save game choosing new game will start a new game, and warn you, that the auto saves will over write the old save file.

If you have loaded a previous game and return to the menu, New Game will function as above, warning you, wiping the current state and taking you to the levels menu from which point any saves will be a fresh save, wiping the old progress.

Demo.

The demo video lacks the warnings of the final version, should hopefully have those working tomorrow depending on how busy i am.

Nearing the end

The first post in along time… sorry.
Expect a lot more over the next two months however! As the project is getting close to the end!

I don’t want to say the final stretch as it’s certainly not there yet, there still needs:

• Testing and then balancing.
• Checking to see it meets standards.
• Levels finished/tweaked.
• PS3 version testing.
• Digital storefront stuff.

For now here’s a first pass of some of the store stuff!

Icons for the PS3 and PSP respectively.

And the game description (just a draft for now), this one is the PSP version.

More updates to come soon! Really!

Player Death Sequence

Here’s a video demo/testing of the new player death sequence, there’s also the first part of the enemy death sequence in there too, but that has a fair bit of work left on it.
I’ll post a run down of the effect over the weekend.

Better Deaths and Boring Particles

So yesterday was frustratingly unproductive…

The particles I wanted to get working just wont… not in the current system.

It’s not so much the particles themselves but the emitter used to create and control them.

It seems to lack flexibility, and it was a lot than i expected to have an emitter have a variety of particles, or for particles to choose a random sprite.

---

 

I’ll explain what i was trying to do:

1. When an enemy dies it creates a death effect that consists of an explosion of particles
2. These particles should be a random assortment of small sprites that look like parts of that ship
3. The random set of sprites should be defined by the ships level (1 = green sprites etc)
4. The particles explode from the dead enemy before being pulled off screen as the world looks to be zooming past.

 

1. Easy… this was already in, but turns out the order of the sprite creation meant i wasnt actually deciding the size!

I would set the scale, but then it would calla function to load the texture, which, after digging around, turns out it scales the sprite itself to the size of the file.

A little annoying, i shouldn’t have relied on the stock particle effect from the examples…

2. Managed to add this into the particle effect rather than the emitter, which makes sense. 

I managed to use the unused “Tint” variable to denote a particles image number.

Gotta work with what you got sometimes

3. Yeah… this is where i started hitting my head against the wall.

Without rewriting my own emitter code this just wasn’t happening. 

I did away with the different colours until i could decide on the best approach.

4. Got this working, doing exactly as i wanted, just a simple acceleration to the left in the update function

It doesn’t look good. It looks alright… but it just doesn’t fit with the aesthetic of everything else.

Just like the old shields didn’t.

---

New Plan!

• On death the enemies are going to implode, crushing down to a small cube/packet of bright data to be absorbed by the player.
• Additionally the points gained by the player will also be displayed.

They will then either:

Be pulled towards the player with the cube.

or…

Move towards the score bar.

I’m going to test both ideas to see which looks better, or if neither might even be best

---

 

What i did get done (an annoying short list)

Fixed a few bugs to do with draining abilities

• Old abilities weren’t always being reset
• Sometimes abilities were reset without gaining a new one

Moved some loops around to remove duplicated code

Balanced the boost/non boost attack speeds

Made the initial attack timers for enemies more random 

• Enemies now don’t all fire in unison

Removed redundant enemy creation code and variables

• There were quite a few variables that are no longer needed and were still being loaded from the config files for enemies

 

Oh!
Final thought…

Player damage! I have an idea of how I’m going to visually represent the player taking a hit.
I expect this to be in the game on Friday.

I will update with a video when it is.

@DeceptiousPhil
#RetroFusion

Design Developments – Player Sprites

Since the start of working on Retro Fusion quite a few elements have changed and developed along the way.

The element that has probably changed the most along the way has been the player. The player has changed drastically in both visual design and mechanics, but for this post i’ll keep it short and just about the visuals for now.

---

 

FIRST DESIGNS

 

 

 

Standard player:

• Blue colouring to give contrast to the colours of the enemies
• Large centyral area to represent where upgrades would fit
• Side fins with space for the draining turrets
• Forward section for the basic attack turret
• Bulk is for best use of using a bounding sphere and using the most of the canvas (ugh, i dont know what i was thinking

Stealth/cloaking player:

• Same blue colouring
• Same position for a forward turret
• No drain turret
• Hexagon styled cloaking hull thing

 

Laser turret player:

• Same space in the center, this would be where the laser turret would be rendered separately
• Same colouring…
• Still a frontal turret
• Side wings covered in purely visual mini turrets, to give the sense of power

Shielded player:

• Didn’t get drawn before being redesigned

---

 

CURRENT DESIGNS

 

Standard player:

• New sleeker design
• Symmetrical
• Front turret is part of the sprite
• No side wings
• Tail wings are for the drain turrets to be positioned

Escorted player (REPLACES CLOAK):

• Same sleek design
• Same new colour
• Middle section now has antenna array to control escorts
• Side sections shuttle bays
• Any additional colouring is a bright green to match the abilities icon/enemy
• Drain turrets remain at the tail wings

 

Laser turret player:

• Same sleek design
• Same new colour
• Middle section still has the turret rendered independently
• Side sections are just beefed up a little to give it a squarer shame to visually identify the laser ability
• Any additional colouring is a red, to match the abilities icon/enemy
• Drain turrets remain at the tail wings

 

Shielded player:

• Same sleek design
• Same new colour
• Middle section now has shield projector (is just a miniature of the shielded enemy sprites)
• Side sections are armored, and rounded to represent the shield ability
• Drain turrets remain at the tail wings

---

 

SUMMARY

Cloak has been completely replaced:

• It just didn’t make sense for work as a mechanic in this kind of game.

New sleek design:

• Feels faster
• More streamlined
• Feels more high-tech
• More distinctive

New colouring:

• More distinctive
• Feels more high-tech
• Better contrast in the game

Drain turrets constant:

• Originally you had to use up or discard your power up to gain the drain ability again
• Now you can always drain and over write your current ability

Side sections:

• Used to better effect to show ability based on shape

Front turret included in sprites:

• Less time wasted on rendering

 

That’s it for now, i’ll post again in the future about the changes mechanically for different abilities.