Saturday, 16 January 2010

Presentation + Evaluation

So just yesterday, I presented my final game to my class, detailing the main features of the game and the ideas that drove the output.


I feel that the general feedback I received from my tutors was absolutely bang-on and straight to the point, I recently discussed the idea of using a flash engine to calculate the physics, collision testing and other elements which were implemented into the game, and whether that could be classed as something I had worked on. My thoughts were that I had taken what I would call an "inverse" method of working in comparison to my peers; as they would take something from the ground and build it up with extra scripts and preloaded content, I was just taking something complete, and breaking it down into smaller parts by remodelling something. 

My overall feeling is that I have learned an immensely great deal in my approach to certain design problems, my proficiency in flash has massively improved from where it was when I first started the project and I'm more confident in the way I approach my documentation work and what I should be improving on.

If I was to take on this project again and do things differently, I would really research the feasability of an idea before I start developing it, rather than just coming up with many ideas and picking the best one. I understand that I'm encouraged to think outside of the box, but pitching my idea with openness to my tutor and them telling me it will be good isn't going to tell me whether my idea itself is practical. Even if my tutor does tell me that I can do it, I have to become more informed, and I realise there's a danger of limiting myself by being too cautious and knowing what I can or can't do, but if I realise that my selected idea will actually take me 6 months to complete (In this case, if I have no Actionscript experience and expect to build a fighting game with all of my originally planned visions, I won't even come close to a final proof of concept to present as my final submission).

I want to be able to create things off my own back, I strive to try and not rely on resources because I'll be limited by them, and next time I will take my idea as far as I can, and then assess it. This is the biggest lesson that I've learned from this module, and I'm incredibly glad that I've realised that.

Thursday, 14 January 2010

Environments + Research


I've been taking some time to start thinking about what kind of environment I want to start setting my game in. I think I want something that is visually appealing and eyecatching, but something that will really make my game stand out and bring out the quality and focus.

Here is some visual inspiration and research that I have collected:

 







Resources:
Cold Heart, Unfinished Gears of War Map
Mega Man X8 Review
LittleBigPlanet
Machinarium

AS3 Switch + Full Movement

With the continuous frustrations of having to deal with mapping key movements to Actionscript 2.0, I decided to see if a switch to Actionscript 3.0 would be more beneficial.


Arrow Keys and W,S,A,D to move the characters.
Numpad 0 to raise player's arms, was supposed to be summoning some kind of energy beam, now it just looks like a hug.

And with that, full character movement was born! What I realised in the difference was that in AS2 the coding revolved around the objects, but when I switched over to AS3, everything made a little bit more sense. I didn't really like the switch from AS2 because I was already used to writing my own functions and events, but AS3 organises the information in a much more logical way.
In AS3, my code was based on event listeners that would understand when a key would be pressed down, and when a key was released, and when animations should be stopped. All of the code was organised under these three different event listeners, and everything seems to happen perfectly without glitching by pressing multiple keys at once. This made it easier to add in more animations and map more actions to different keys. This would make way for collision testing with hitTest functionality, and testing for keylock combinations in modern keyboard to troubleshoot the multiplayer experience.

Jumping Animation Troubleshooting

So after my last post, I have been wondering how to add extra animations to my character, as now that I have used nextFrame(); to walk the character on screen, I now have to find a way to have him jump.


Arrow Keys and W,S,A,D to move the characters.

So in this example above, I took the jumping animation and placed it along in the timeline, along with the other movieclip animation tweens, and the results was that the first frame was flickering on and off in any possible jumping instance.


Arrow Keys and W,S,A,D to move the characters.

With a little bit more progress, I managed to have him jump, but only the first frame would stay on, and to even see that possible, you have to be holding one of the left or right directional keys down, otherwise if you press the jump button, you're only going to see the same flicker as you do in the first flash I posted. What also interestingly enough happens is that when you are jumping (with a directional key held down) and land to the floor and keep holding, the jumping animation itself is holding itself without reverting to the original standing frame.



Arrow Keys and W,S,A,D to move the characters.

This one isn't really useful in any way, but I posted it because one of my "good" ideas was to change the registration point of my character completely to see if the jumping would be possible, but my little guy gets stuck in mid air, which is really a worse problem than the two above..

Walking + Variable Control


Arrow Keys and W,S,A,D to move the characters.

Another movement update, thanks to Trev, my character now continuously plays his walking animation when going in both directions. What seems to happen is that from the first frame, a movieclip and nextFrame(); tag is used:

mcMain.nextFrame();

Here the first frame of the movie clip is being referenced, which is the standing still animation that is sitting in a movieclip of its own. What then happens is that after the first frame is the walking animation tween, which means when the keypress is made, mcMain will more or less play the frames after frame 1. When the key is released, the animation will use a gotoAndStop(1); tag to send him back to the standing animation.

Now I already had variables set to dictate the speed of movement of my character, however once I slowed down the speed variable, the walking speed matched the animation speed, so that was something I was very happy with once having worked on it with Trev.

What has to be figured out now is the possibity of adding more animations, as a nextFrame(); element can't be used whether my next animation comes after the walking animation in the timeline, or if it's in a separate movieclip on that timeline..

First Keypress Animation


Arrow Keys and W,S,A,D to move the characters.


Just a minor update here, but I've added a small keypress movement and x_scale code using Maths.Absolute to reverse the character depending on the direction he is moving. Right now only moving him left will play the full animation, however moving him right doesn't, as it just seems to be calling the first frame of the animation label continuously with an onEnterFrame element at the start of the script.

And there's more coming..

Movement + Gravity


Arrow Keys and W,S,A,D to move the characters.

So here is a new post with my original fighting game added to it. This is the character model that was developed previously when I made my character model post earlier in the blog. Right now this is the first live fighting screen that I have, and a lot of the interface is still in planning, however I think there has been some really nice development as I have two movable on-stage characters.

- The character model is separated into its separate body parts ready for animation, each body part can be independently animated in order to create movements.
- A stationary “standing” animation has been mapped to a stationary player displaying that character breathing when they are in a still state.
- Character clipping has been introduced to prevent characters from moving off-stage. This is good as it keeps the players in contact within the stage at all times.
- Character flipping in different left and right directions hasn’t been introduced yet.
- Character animation on keypress events also needs to be introduced before hitTesting and collision detection can take place.
- Jumping action and gravity has been introduced into the game, a key element of the final product.

Monday, 4 January 2010

Features + Overview

General Features
- Classic Fighting Simulation
The game will emulate qualities of other classic fighting games, live interaction between two users. The main emphasis on this game is that it is a two-player experience, so the possibilities are made by the people playing the game, and that's what is the engaging part of the game.


- Interactive Media Design students as characters
More of a personal aestethic and something that can add more personality to the game. The characters in the game will reflect real life personalities, and gives me the challenge of transferring real people to digital.


- 2D graphics
I think 2D videogames are very much overlooked these days, and it's always something that has been very successful. Many of todays games are 3D, but I find 2D easier to interpret and identify with, and I want people to have a good gaming experience through the aesthetic quality.


- 32-bit color
If I am going to have a 2D game, I will push the limits with the graphics that I can use. Plus it looks great.



Multiplayer Features
- 2 Player Fighting
This is the main aspect and selling point of the game, something that can bring a social spin on the game. I want more than just the game to be remembered, I also want the occasion to be remembered too.


- Easy to play (Controls)
The controls should be really easy to pick up and understand, bringing in the basics of a fighting game and streamlining the experience as much as I can.


- "Keylock"
"Keylocking" is a mechanism that comes with keyboards on the market today which prevent a certain combination of multiple keys being pressed simultaneously. The fact that my game will be a flash multiplayer game that works on the keyboard, I have to find arrangements that avoid keylock combinations so that one players actions isn't completely jammed by another players actions.


- Replayability
The game should be easy to play again, both wanting to rematch the player with the same characters should be a considered option, as well as being able to replay the game with different characters. If I realise my game well enough, I may end up creating an addictive experience which boosts replayabilty.


Gameplay
A list of actions I want my characters to perform are as follows:


Punching
Kicking
Blocking
Aerial Attack
Special Attack


Right now these are basic requirements for me, but if there are more actions I can then add, I will continue to add those.
Animations should be clean and easy to understand. Since my character model is simple, I should be able to incorporate simple gestures to match the model. I want to nail the fighting experience first before I continue on areas such as facial expressions and emotions, getting the physics right is important for me too such as gravity and collision detection.
Health tracking is also important in terms of functionality, but also in the gameplay itself, I want the game to be fair in all of its diverse qualities. Not losing too much or too little health when damage is inflicted is going to have to be worked on with user-testing, and the way the game plays will also have to be managed somehow.


Overview
So, I have a lot to do especially that the game will be developed in flash. I will try to continue furthering my knowledge of flash and getting some of the key aspects done and completed. More updates following...