Blog Covering the Past 3 Weeks

Okay so I haven't posted in a couple of weeks, this has been the basic run down.

I have changed my game idea from the 2 previous ideas. Project Asteroid Escape is now in development.

Story:
P:AE sits the player in the seat of a spacecraft which, in a rather cliché way, is fleeing an enemy fleet en route to warn the rest of the Human Space Navy. Knowing you'll less likely be followed you make the daring move into an asteroid field. You mission, get as far through the asteroid field as possible, or be blown to pieces trying.

Aim:
The aim of the game is to get the highest score, you won't ever be able to reach the human navy but the game will have a difficulty curve fitting to that of a high score game.

February 19th Session:

During this session we pitched this idea. Since this pitch some things have changed, however during the pitch I proposed the following:

Controls - Two Sliders, one along the bottom of the screen, and one along the side (side depending whether the user is left or right handed), which will control the ship on an axis like schematic. So whatever the x position of the side scrollbar is will be the same as the x position of the ship, and same for the y position with the bottom slider.

Aim - get there in the most efficient manner - Have other in game objects like fuel cells and boosters, either get to the destination the quickest, or in the least amount of time, each will score points.

Platform - starting on PC and working its way into tablet once the pc version was finished.

Suggestions from Dan included having different paths, one maybe easier but takes longer, another maybe even, and a third that takes less time and fuel, but is a lot harder.

We were also shown Pivotal Tracker, a site designed for Time Management, where you split the project down into sections and then those sections down into tasks.

The week following this session I built a basic Cube that would travel continuously down a tunnel of 4 cubes and had the main cube collide with the 4 boundary cubes so that they actually acted like boundaries.

February 26th Session:

In this session I trying to sort out my time management using pivotal tracker, I split the project down into individual tasks and continued working on the project.

By this point I kind began to ignore the ideal of putting it onto tablet soon after the pc version was finished, instead I decided to change the controls to the arrow keys for now. And instead of implementing the tablet controls along with the pc controls, focus on the pc version as that's what I'm going to be delivering first. I figured it would be best to have a working polished game for the PC, than a not so polished game that works on both tablet and PC.

The following week I had other assignments that took priority so this project was put to the side for a week.

March 5th: Having not progressed much from the week before, I spent this session readjusting to the project and working on what I already had.

The following week just gone however I made some changes. Firstly I took away the barrier cubes, as my collision with them was all position based and they were rendered useless. Decided that the dame was definitely going to be high score based and you won't be able to reach the fleet, however pushing so hard to try and beat the top score!

By the time I got to todays session I had code and a project that has most of the main core mechanics functioning but not properly. By the end of todays sessions I had all these mechanics fully functional with just one or two more to put in, then it's onto the looks of the game.

Currently the game generates random asteroid fields as you progress through it, the player must use the arrow keys to avoid the asteroids and if you do collide with one it gets destroyed, the player loses life and also slows down. When player health reaches 0 the player is destroyed and the game ends.

From here I need to implement a HUD, a title and menu screen, a pause menu, maybe some options. Also I would like for the player to speed up as the game progresses to counter when the player gets slowed down.

After that it's all about making it look nice, and messing around with 3d models...

Here's a screenshot depicting how the screen is going to look roughly:

Unity 3D Project 1. Initial Ideas.

Hey Guys

For my 2nd term game development project I'm using the Unity 4 game engine to produce a game which contains standard game play mechanics with a new personal innovative twist!

I've had several ideas which I would like to implement but the development process is what'll define what I can get done. Being a newcomer to unity I don't want to take on anything too challenging but at the same time having a challenge will make me learn more. Much like the stencyl project going into this project without knowing quite how much unity can do, or how well I'm going to be able to use unity. Is going to make choosing a game to build a challenge.

My first idea is called Project Mini Racers.
The player assumes the role of a "micro machine" type vehicle racing other vehicles to the end of the level. It'll be a side scroller 3D environment moving from left to right. The player will have to avoid obstacles and debris as they race across the level and will be able to gain powerups that allow them to do more than just race. For example there will be a point where the racers will have to go through some water, now if the player picked up the boat power up they won't have a problem going across the water, for those who didn't pick up the boat power up they'll be slowed down by the water.
The art style wouldn't be serious but would be visually appealing with lots of "sparkle" as it were. The game would be easy but attractive on the eyes and look and feel playful and playable.

My second idea is quite simple yet I believe it could be effective.
As a kid I would become more and more furious whilst playing Zelda OoT when it came to kikori forest. Where I'd randomly run around the maze like set up until I managed to get to where I wanted to go. Until I realized if you followed the music you'd get there no problem. I would get a piece of paper and write down which way I've gone.
This inspired this next idea. it's plain and simple. You've been dropped into the middle of a maze, a massive maze, with no idea where to go, but some reward at the end, and the whole idea is you'll need a pen and paper next to you to get to the end. The player would be put into some scenario where you've ended up in this maze and you need to get out. The game would use only a mouse click, where you'd get to a junction you'd be presented with the options of where to go next. For example if you came to a t-junction you'd have either left right or back.
There would have to be some sort of threat or timer for the user to get out in time otherwise the user could just get lost forever. Perhaps the game could also have multiple floors and when you reach the floor above/below it gets more and more difficult.

These are just two prototype ideas and I'm not entirely sure what I'm going to go for yet. The first idea would be more time and resource consuming having to learn a whole new load of physics for racing games and then create all of the different assets, whereas a maze game could be made rather simply and not have too much too it.

Game Design Document

Hey all.

For my course I had to attach my game design document to my blog. Well... HERE IT IS!

Game Design Document


Thanks!!!

Ryan

Post 9... ON KONGREGATE!!

HEY ALL!

Games been published on kongregate, so if you'd all fancy going over and taking a play, would be greatly appreciated!!! http://www.kongregate.com/games/Hothead1993/dr-doctor-demo

It's only a demo so creative feedback and constructive criticism would be great :)

post number 8...

Well since it's due in on Monday, probably about time I make a decent blog post and detailed explanation about my game demo.

My Game is called Dr Doctor. In which the player assumes the role of an army medic shrunk down to the size of a virus and injected into the human body in order to fight off the virus threat.

The player uses the wasd keys along with . and / to control the Doctor. He can run left and right, jump, duck, shoot bullets and vacuum the enemies up. When an enemy is vacuumed up it is converted into a bullet, these bullets can be used to shoot the enemies and eventually the boss of that level.

Normal

Left

Vacuuming Right

Vacuuming Left

Shooting Right

shooting left

 Vacuum enemy left

Vacuum Enemy Right

Walk Left

 Walk Right

Jump Left

 Jump Right

Duck Left

 Duck Right

The Normal Enemy Moves left and right and only damages the player on contact, depending on the level depends on whether they can fall of platforms or not. They do 25 damage to the player when they touch him.






The Demo has 3 levels, each with something a little different to the others, the idea is the levels get more oddly coloured throughout to represent how infected the area is as you get closer to the end. The first level has a red colour scheme, level 2 is browny yellow, and level 3 is green.

Each level has it's own boss but shares the same basic enemy. The bosses on each level do different things but currently are all killed just by being shot a set amount of times depending on which level you're on.

Boss 1:
Takes 25 bullets to kill it. Gives an unknown added incentive to the first level to save bullets. Fires 2 bullets at a time one going straight across which will definitely hit the player unless ducked under or jumped over, then the other one shoots down at the player and has 3 possible lines of travel.

Boss 2:
Takes 30 bullets to kill. The tank currently goes back and fourth across the screen and if the player is hit by the front of it the player takes 25 health and is pushed back, the player can jump ontop of the tank but wont be able to kill it that way.

Boss 3:
This is currently the final boss, which takes 50 bullets to kill. It has 4 guns that shoot down at the player at a rapid pace and the player has to dodge all of the bullets, the "factory" also produces an enemy that comes out of its doors every 2 seconds that will come at the player. Once this boss is defeated the player has completed the game.

           

Whilst using the macs in the lab I found I liked a font called Chalkduster, I found it kinda fitted with the childish look of my game, and also looked like an old blackboard type look to the game which fitted with the tenuous world war 2 theme. The only problem I have with this is that I can't make it consistent if I work on it at home unless I download the font off the internet, it's not an issue just a resource thought.


Problems I encountered along the way...

I encountered a problem that was causing the enemies to not rebound on side collision with a tile, instead it was causing all of the enemies to just freeze up and start shaking. In order to resolve this James in the lab implemented a new actor called barrier, and instead of creating collision detection between the tiles and the enemy there is a collision between the barrier and the enemy. This solved that problem.

Stencyl itself just sometimes does things for no apparent reason. For example I had just finished the 3rd level, and played a test level just to make sure it was working, and suddenly none of my animations for my character would work, and it wouldn't vacuum or shoot because of that. For some reason it changed the "self" when you change animations to a "self" that wasn't the "self" for that actor, so I had to change each "self" on each of the animations to what seemed to be the same "self" but apparently was a different "self" <-- is the "self" getting annoying yet?

When implementing the 2nd boss I set the physics to cannot be pushed, because I wanted the tank to be "heavier" than the player so if the player ran into the back of the tank it wouldn't increase the speed of the tank, however doing this meant that the 2nd boss just didn't move, so after faffing about in the blocks for a good half an hour I found out that the only problem was one radio button that said that the tank could move...

Stencyl also has a weird way of turning things off without your permission and just not functioning the way it should, which is restored normally by closing it and opening it again, which caused me to waste quite a bit of time because I didn't just think to restart stencyl at the beginning, so learn your lesson from me, RESTART STENCYL FIRST IF ANYTHING GOES WRONG. If that doesn't work then feel free to waste as much time as you want trying to fix whatevers wrong :')

I should be putting Dr Doctor onto Kongregate later, just have to sort some sound out for it, I'll post a link later that goes to my game on Kongregate :)

Been a long week

hey guys, been working a lot all week, here's a few shots of what I've done, will update more later tonight.

Post 5 - mid development

So my game is in full swing with 2 full levels almost complete and the majority of the mechanics working. Here's a brief run down of what goes on.

When the game comes up it opens with the opening screen. (funnily enough.)

From here pressing enter will take you to the story slides which give a brief overview of what's happening and give the game some context.

The game then enters a small tutorial level where the controls are taught. Simply gives the player a chance to learn the controls and once they've defeated both enemies on that level they're then dropped into level 1. Which starts of looking like this (Still using placeholder art):

Here the user fights their way through the viruses having to jump over gaps and up steps in the normal platformer fashion until the end when you meet the boss of the level. 

This four eyed virus monster shoots lasers out of it's eyes in a straight line that the player must duck or jump over, or in a random angle in the direction of the player. Each laser does 20 damage points to the player when they're hit and the boss needs to be shot 20 times for it to die. When the boss dies the screen fades out and goes onto the next level. Which has been developed just isn't being shown at the moment.

The player starts off with 100 health and on contact with a virus they loose 25 points. However there are health packs the player can pick up that revitalise the player by 50 health points, and the player can have a maximum of 200 health. This has been implemented for the 2nd level. Where I have implemented a falling mechanic where by the user takes damage when they fall too far, and having a maximum of 200 health gives them a bit more of a chance to complete the level.

One feature of the first level is teaching the user than bullets can be scarce, and having the boss health so high  means that the user is forced to use the vacuum mechanic more than the shoot mechanic, which increases the uniqueness of the game.

Due to the military background of the character I'm going to have the music have a very militaristic theme, whilst the player plays through the levels they will have a simple military beat in the background and then when they approach the boss the music will change into a different beat and instrument depending on the boss.

I have 2 types of enemy so far, the virus and the boss.

The virus doesn't attack but colliding with it damages the player, they have 2 way movement and rebound when they collide with walls. When the player collides with the virus the virus dies.

The boss changes with each levels, they will generally have a high health count (around 25) and depending on the boss there will be different methods of defeating him.

Dropped midflow here but I will finish it tomorrow :)