Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
Hi, In this post we will be talking about some of the thoughts we went over while deciding to add enemies as an obstacle to our game.
Hi and welcome,
This blog was orininally posted at our website www.touchscreendev.com as "Our Game, Part Four". We blog about the game we are creating at the moment, but also discuss game design in general and write iPhone tutorials.
In this post we will be going over some thoughts on enemies in our game.
If you have been following this series on our website, you saw the early winter world screenshot in part four, and probably noticed, that so far there were only a player in there.
In order for the game to be any kind of challenge to our players, we will need some kind of obstacles to be overcome.
As promised this post will be focused on the kind of obstacles made up by enemies.
So first of, we needed to look at the purpose of enemies in platform games in very genera termsl.
With small variations, enemy characters/creatures usually walks a set path in the level, and if the player comes in contact with an enemy he dies or if he jumps on it or shoots it, he kills the enemy.
There is just one small problem with enemies working this way. One of our main design goals is that the player should feel good while playing and generally have a good time and hopefully put a smile on his or hers face.
But when something has the ability to kill you and you have the power to kill. That somewhat contradicts the feeling of happiness that we want to achieve.
So the challenge here was: How do we implement enemies that adds to the game in a way that compliments the gameplay and does not serve as an object of frustration to the player, but rather serves as an object that adds to the fun of the game.
This decision to want to add fun with everything we implement, has been one of the main reasons that we chose to have a timer instead of a healthbar for the player.
That being said, the timer acts as sort of a health bar, because if time runs out, the game is over.
But this does give us some more flexibility in our design. We can now choose that everytime the player hits an enemy, a set amount of seconds is deducted from the timer.
This may seem the same as deducting life from a health bar, but it is actually a very different thing.
Allow me to explain:
If we had chosen a seperate life and timer bar, the player could be making record speed through the level, but then die and have to start over because he came in contact with an enemy. We believe this would leave to frustration because the main gameplay feature is the timed run, and if you are good at that, it makes no sense to punish the player for touching an enemy, by making him start over all the way at the bottom.
Instead with a single timer that co-acts as a health bar, we compliment the main gameplay in a better way.
This means that if you are making a good time up the level and touch an enemy, your time is ofcourse reduced, but you still have the possiblity to complete the level.
This point was very important for us, because then you have more control as the player to choose if you want to move on to the next level or stay and try for a record time.
This is also a way of making the game more accessible to the average player, but rewarding the dedicated players who put in the time to be both good at getting to the top fast, and avoid hitting a single enemy.
This is also a key point since we will be implementing online leaderboards, and therefore need to tweak the gameplay to compliment both casual and hardcore playstyles.
So in conclusion to this rather long explanation, we did end up choosing to implement enemies as an obstacle in our game. As of now we are both looking at “stuck in place” enemies (think flesh eating plants in other platformers) and moving enemies.
Actually the title picture for this post is a concept piece for our moving enemy.
Both enemy types should then work in a way where they deduct time from the player and not life.
At this period of time in the design process we have also decided that the enemies cannot be killed by the player and we have several reasons for this decision.
First off, the point from earlier, if you have the capeability to kill something, it would not logically contribute to our original design goal.
Another point is that we sometimes find it to easy to overcome these enemies if you can just kill them.
We are now in the testing fase with these unkillable enemies and so far it seems the challenge of overcoming them is much more rewarding, if you actually have to bypass them and cant just kill them off.
We will be updating on how this design ends up turning out in a future post.
Thank you once againg for taking an interest in our game and reading along. We are sincerely thankful.
Sincerely
Peter and Jesper
Read more about:
BlogsYou May Also Like