I love prototyping a new game. However the prototype is not where the development of the game really started. Heck I don't start coding till I already have a good idea of how all the gameplay and fun will be attained. So the prototyping in reality is the realization of the fun gameplay ideal I have in my head, or on paper. It is more the proof of concept than the idea itself, it is also not a full game.
So once I have the idea of the game in my head I tend to put it down onto paper. This is not always a set regimen either, it varies how much I write on the type of the game and most importantly my familiarity with the genre. Shooters for example I tend to write less, but platform games I will write more.
Once on paper I start deciding how I will code the game if I go ahead. This always leads me to start actually coding the game and therefore the prototype. The prototype can be simple as well, as I only really need to prove to myself that the game is viable. Sometimes the control will simply not come along nicely and I will then abandon the prototype. If as is usual the control scheme feels good, then I get all excited and need to move along as fast as possible.
This is when it is exciting as I code in the details of the game to expand the prototype and start in on making it a complete game.
Laters
Da Voodoochief
Showing posts with label layout. Show all posts
Showing posts with label layout. Show all posts
Wednesday, November 14, 2012
Tuesday, November 30, 2010
Levels, Scenes or just layouts?
I have been calling these things all of those things and more, like maps for example. Though all they are in reality is a level layout made up of walls. See the problem, haha.
Below is several of what i am talking about.
The Red blob is the starting spot for the level.
The Yellow blobs are the 10 spots where Civilians might be (depending on how many are required for your current stage)
The first one also has some images of the battle taking place along with some lines that depict where some of the enemy movement will be.
So now i have all 10 of the SCENES or MAPS created. I have also done the data tables for the teleport spot and where all the civilians might be. So next up is to actually start designing real enemies for the individual levels. As it so happens there will be two scenes to an enemy type, and luckily for me i have chosen 5 distinctly different enemy types. Check them out below....
So, my next job is in fact to decide which of my scenes best fit the gameplay styles of the enemies. I have to choose two scenes per enemy type. should be easy right ?
Time will tell.
G'night
Below is several of what i am talking about.
The Yellow blobs are the 10 spots where Civilians might be (depending on how many are required for your current stage)
The first one also has some images of the battle taking place along with some lines that depict where some of the enemy movement will be.
So now i have all 10 of the SCENES or MAPS created. I have also done the data tables for the teleport spot and where all the civilians might be. So next up is to actually start designing real enemies for the individual levels. As it so happens there will be two scenes to an enemy type, and luckily for me i have chosen 5 distinctly different enemy types. Check them out below....
- Ninjas (fast and throw fast shurikens at ya)
- Aliens (classic egg shaped head, technologically advanced)
- Pirates (slow moving but fire exploding cannonballs at ya, and maybe boomerang parrots no less, YAR!)
- Zombies (yup a players favorite. These guys are dumb as they come, they throw limbs at ya)
- Robots (one of my personal favourites)
So, my next job is in fact to decide which of my scenes best fit the gameplay styles of the enemies. I have to choose two scenes per enemy type. should be easy right ?
Time will tell.
G'night
Wednesday, July 14, 2010
Simulation = gameplay?
I would disagree with that statement above. Most programmers want to really simulate parts of their games like they are real world things. Mostly i find this to be a great starting point, but not usualy an end point. There are various reasons for that of course and i am sure i won't cover them all here, at least not in this post. Let me start by talking about one of the most obvious forms of simulation tried in a game, and then i will talk about it's effect on a player etc.
Jumping. Yup something as simple as jumping used to be the number one simulated physics type item. A programmer would start out with the usual gravity ad then input a vertical velocity for making them jump. The issues with this tended to be that in 60fps land that your initial jump would be quite a lot of pixels if you wanted to to jump anything useful. Now lets talk about useful. In games the layout of a level is a very important aspect, and making a real world jump severely restricts what kind of layouts you will see. Just imagine if you will how a platform game level would look if you had to get to the top of the screen, but could only jump about 3 feet at a time. There would have to be a very large number of platforms to jump upon to get to the top of the screen. It could could also be called boring as well as you have to make so many jumps. Oh dang, i forget what point i was working on making as my mind is filling up will all the other issues that this simulation represents. argh!
Also using gravity as a fall mechanic tends to make the falling speed rdiculous and then there are real bad collision isues. So we cap max velocity and know that will fix the issues of collision. It does not then lok like a simulation, as max faling velocity is usually way way less than real world terminal velocity. 60fps was a real handicap, snapshotting movement is always going to be an issue for fast moving objects. Now of course we can say that 30fps is much worse. In a way it is, but in another it is not. Fast moving objects do not realy need a cap of max velocity. The reason is that was can multi-sample the movement and therefore know that collision will still work. This is simply done by making the logical frame happen more often than the physical drawing frame. So by doing a double logical frame then you will get a movement distance of half what it was. The down side to this technique is that it
uses more processing power. One technique added to this in the past was to see how far you had travelled and then know how many movement control/detection logicals to chop it into to make it work accuratley. This again is great, epsecially when you have enough processor power to handle it.
But back to my original isue which is gameplay and desgn. If you restrict the designer to only have a mediocre jump at al times, then you are restricting what the designer can give you as far as challenges. For example if you can only jump a distance of say 5 feet across. Then to make that jump easy should be about a 4 foot gap. To make it hard it should be the maximum. But wth only 5 feet to work with it is hard to make a nice variety. Usually though the design issues become more apparent from the curve/arc of the jump than from the actual distances. The curve of a real jumper is very straight forward and really does not vary much (unless maybe you are an international class athlete). So it is again harder to get variety in gameplay.
Ok, i am done for now saying it is bad to simulate. In fact it is an excellent way to start, but know when you start what kind of layout you realy want. Don't let the simulation control your game. Control the simulation y your gameplay parameters. If you already have a level you want to make a character jump around, then go for it. Then once you have something you are happy with as fare as control and feel. Then go ahead and tweak the level to match what should be a great platform control.
Parting shot.. I do not think i have ever used real gravity for my platform games player control. I have sed it for lots of effects and enemy creatures however. The shaprness of the movement suits them much better.
I hope you fond this interesting, and as usual i invite comments to dicuss this.
Laters
Please check out my Kickstrarter project.Those rewards are coolio.
Jumping. Yup something as simple as jumping used to be the number one simulated physics type item. A programmer would start out with the usual gravity ad then input a vertical velocity for making them jump. The issues with this tended to be that in 60fps land that your initial jump would be quite a lot of pixels if you wanted to to jump anything useful. Now lets talk about useful. In games the layout of a level is a very important aspect, and making a real world jump severely restricts what kind of layouts you will see. Just imagine if you will how a platform game level would look if you had to get to the top of the screen, but could only jump about 3 feet at a time. There would have to be a very large number of platforms to jump upon to get to the top of the screen. It could could also be called boring as well as you have to make so many jumps. Oh dang, i forget what point i was working on making as my mind is filling up will all the other issues that this simulation represents. argh!
Also using gravity as a fall mechanic tends to make the falling speed rdiculous and then there are real bad collision isues. So we cap max velocity and know that will fix the issues of collision. It does not then lok like a simulation, as max faling velocity is usually way way less than real world terminal velocity. 60fps was a real handicap, snapshotting movement is always going to be an issue for fast moving objects. Now of course we can say that 30fps is much worse. In a way it is, but in another it is not. Fast moving objects do not realy need a cap of max velocity. The reason is that was can multi-sample the movement and therefore know that collision will still work. This is simply done by making the logical frame happen more often than the physical drawing frame. So by doing a double logical frame then you will get a movement distance of half what it was. The down side to this technique is that it
uses more processing power. One technique added to this in the past was to see how far you had travelled and then know how many movement control/detection logicals to chop it into to make it work accuratley. This again is great, epsecially when you have enough processor power to handle it.
But back to my original isue which is gameplay and desgn. If you restrict the designer to only have a mediocre jump at al times, then you are restricting what the designer can give you as far as challenges. For example if you can only jump a distance of say 5 feet across. Then to make that jump easy should be about a 4 foot gap. To make it hard it should be the maximum. But wth only 5 feet to work with it is hard to make a nice variety. Usually though the design issues become more apparent from the curve/arc of the jump than from the actual distances. The curve of a real jumper is very straight forward and really does not vary much (unless maybe you are an international class athlete). So it is again harder to get variety in gameplay.
Ok, i am done for now saying it is bad to simulate. In fact it is an excellent way to start, but know when you start what kind of layout you realy want. Don't let the simulation control your game. Control the simulation y your gameplay parameters. If you already have a level you want to make a character jump around, then go for it. Then once you have something you are happy with as fare as control and feel. Then go ahead and tweak the level to match what should be a great platform control.
Parting shot.. I do not think i have ever used real gravity for my platform games player control. I have sed it for lots of effects and enemy creatures however. The shaprness of the movement suits them much better.
I hope you fond this interesting, and as usual i invite comments to dicuss this.
Laters
Please check out my Kickstrarter project.Those rewards are coolio.
Subscribe to:
Posts (Atom)
Posts
