February 18, 2013 by jonmillymiles
At some point I need to sit down and write a Functionality Specification… or as it shall be known from now on – an fSpec.
An fSpec is a design document that tells you what everything does and how it responds within a game. My problem is that I am now at a point where I’m going to have to reverse engineer a fair proportion of this document. But for tonight, I shall be mostly blogging and getting my progress down on eInk. I think that Apple may have started something horrible with the iDevice naming… or should that have been iThink??
Bad jokes aside I’m finding the reflective nature of blogging quite cathartic, more importantly I’m beginning to find that it is greatly assisting my work flow and process as it is allowing me to capture my thoughts, actions, progress and reflections. Its almost like some kind of process, but for designing stuff.
When I finished my last post I was happy with myself for creating a simple parallax star field. For those who don’t understand what parallax scrolling is: it is a method of convincing a person that a 2D environment has depth. It mimics the view from a car window, the objects that are close whoosh by quickly, while those in the distance move at a more sedate pace. It can be seen clearly in this video which is from an old classic from the Commodore Amiga: Shadow of the Beast by Psygnosis.
If you look closely you can make out the separate layers of scrolling in the grass, the trees and the sky. These layers move at differing speeds to give the illusion of depth to the player.
But that wasn’t enough for me, I had to keep going and so I started to create some weapons and drones for my player ship. I want the player to have multiple weapons systems available to them:
- A circling drone that crashes through anything and everything, but only offers limited protection.
- Gun drones that sit above and below the player and increase the number of bullets fired forwards, but offer no protection.
- A “force” type of drone that docks with the front of the player ship, similar to R-Type. When the drone docks the player suffers a movement penalty as they have more mass to move.
By building these into the game, and offering the player a choice of what they can use, I aim to introduce player preference and strategy. You may be thinking that I am running before I can walk, and you won’t be far wrong there – but if I have goals to aim towards I can learn how to achieve them. But if I do not set myself goals I will have little reason to learn. More importantly for me I want to make a good shooter and I want it to be the best that I can make.
Click the links below to sample the game so far.
Created some of the drone images – for the simpler stuff: bullets, missiles, gun drones and rotating mace. Also an Orb but not sure how that will work yet.
Learned to reference the movie clips – After Thursdays lesson I learned how to reference the movie clips properly. So I moved the code for the buttons into the main Actions layer on the stage – I doubt you’ll notice much difference.
Learned myMC.onEnterFrame = function () – This was a biggie. By doing this I can create code that plays for each MC, which means that I can begin to look at using variables properly. It also means that I can use code to calculate motion rather than using animation – which is ultimately easier to test. I now have a Mace moving around the ship using the Math.sin and Math.cos functions 🙂
Removed the lag in the key presses – This was another biggie. When playing a game the controls must be responsive and work as expected (even more than as intended) otherwise the player will feel frustrated and cheated. The way that I was scanning the keyboard originally was by using an event listener. This seemed more natural as the listener takes its input directly from the hardware, however there is a repeat delay built into each motherboard (and sometimes configurable in the BIOS) and this was causing the lag. To overcome this I used the Key.isDown command and ran this within an onEnterFrame function for the player ship. This allowed me to move all of the control out of the listener and begin to build in realistic ship control.
Inertia – The one thing that I wanted to accomplish this week (hence the post title) was to introduce smooth acceleration and deceleration to my ship. This gives the craft a feeling of mass and allows the player to control the ship more naturally. It also enables me to create different handling styles for the variable geometry of the ship thus giving each mode a unique feel.
Press Q to transform – I bound the ship transformation code to the Q key. Then I did a little more and altered the code so that the players ship loses acceleration and top speed when it is contracted. This fits in with the model that I want to use for the “force” when docked with the ship. Should I not be able to code that then I’ll use the slower mode to increase the hit damage of the bullets and give the player another tactical option.
Gun Drones – Just a little code went into here. I made the gun drones follow the player as I would like them to do – with just a little lag to that it feels like they are responding to the movement of the player and not just stuck to them.
In all the above examples I also began to comment the code completely. There have been times when I have had to go back and retype in a lot of text to explain what I have done but it needs to be understood by the examiners.
Have fun 😀