Over the past week we began writing the game in XNA, with the primary target being Windows PCs. The initial goal was to get something up and running which looks like the prototype but has a real framework behind it. What we actually did was start creating the level editor for the game, which implements a lot of the same functionality the prototype had.
XNA is surprisingly nice to work in; I was wary about working in a system which is designed more for 3d games, but creating and using sprites is really not a big deal. We started by basically cloning some ideas from Flixel's architecture: we're using groups for sprite layering/organization and we have our game 'screens' split into States, of which only one is enabled at a time.
One thing we're going to have to think about is the actual interface for doing level-editing. We have to strike a balance between ease-of-use and, honestly, development time. I mean, our target audience for the editor at this point is five people. The focus will be more on speed of use for an expert user than reducing the learning curve.
We're making good progress, anyway. I'll post screenshots of the editor in the near future, maybe when it looks a bit prettier :)
Tuesday, September 21, 2010
Monday, September 6, 2010
Prototype V.1
Here's a prototype which more accurately presents a simple puzzle in the game. The player is shown the end result of a car accident, and can reverse time to see what caused it. By finding the right place in the timeline, the player can get to the top of the cliff or the hole in the cliff by jumping on the falling rocks/car. There's several bugs and weird movement things (like infinite jumping.) Just ignore that stuff for now.
Prototype
We made a bunch of progress on figuring out storyline and art style during our meeting, which we think will make the beginning of the game quite compelling. That stuff is a secret for now, though.
Prototype
We made a bunch of progress on figuring out storyline and art style during our meeting, which we think will make the beginning of the game quite compelling. That stuff is a secret for now, though.
Wednesday, September 1, 2010
Time Game - Design, Challenges
Design
The game we're currently considering is an interesting puzzle/platformer where the player must travel forwards and backwards through time to be able to explore the world. The premise is that you're witnessing the end of the world, and you want to discover what's caused the apocalypse. Time around you is paused, but you have the ability to essentially "fast-forward" or "rewind" from where you are. The player is unable to move if the world is in motion, and is free to walk around when the rest of the world is frozen. In this way the player is isolated from everything and everyone else.
The main gameplay involves the fact that the positions of objects change over time. A simple example is that there might be a bunch of toppled rocks which disallow entrance to a building. The player can reverse time and find out that the rocks were the result of a landslide, and by reversing enough the entrance into the building will become unblocked.
A more interesting gameplay situation: There is an exploding car and the various windows, sheets of metal, engine parts, etc are all flying through the air. By pausing at the right time, the player can jump between the bits of the car to reach a higher ledge. A more morbic/comical example that we like to mention involves jumping between dead bodies being thrown from an exploding bus.
Challenges
There's a couple potential pitfalls here.
1. Differentiate this game from Braid or other time-based puzzle platformers. The gameplay would actually be quite different from these games; it's more about exploring in 3 dimensions (with the third being time) than finding a single solution to a puzzle. The fact that the player is independent from time is really what makes it different. But still, the obvious first reaction to this game is "that sounds like Braid!"
We can combat this in several ways. The most important is coming up with a tagline/pitch which makes it sound totally different - we should highlight the premise more than the puzzle mechanics. "Play with time!!" is old hat. The game is more about the exploration and isolation (at least to me.)
The next thing we should ensure is that we have an art style that goes along with this. If we decided to do a painterly whimsical art style, we'd be screwed. We need to come up with two or three cohesive but different styles, for when the world is frozen vs. when the world is playing forward/reverse.
Finally, we just need a solid story that presents the game as a unique work. We have many different ideas for this, and we'll be figuring this out soon.
2. Make sure the game mechanics stay interesting!
It's very difficult to tell, so far, if the game is going to be fun for more than 5 minutes. The puzzle/platform mechanic might work well for a while, or it might become easy and obvious quickly. We have many options for how to extend the mechanic or add new ones, but this is something we're going to have to figure out. The solution to this is testing and prototyping, over and over.
I guess those are the two main challenges for now. First real prototype coming soon.
The game we're currently considering is an interesting puzzle/platformer where the player must travel forwards and backwards through time to be able to explore the world. The premise is that you're witnessing the end of the world, and you want to discover what's caused the apocalypse. Time around you is paused, but you have the ability to essentially "fast-forward" or "rewind" from where you are. The player is unable to move if the world is in motion, and is free to walk around when the rest of the world is frozen. In this way the player is isolated from everything and everyone else.
The main gameplay involves the fact that the positions of objects change over time. A simple example is that there might be a bunch of toppled rocks which disallow entrance to a building. The player can reverse time and find out that the rocks were the result of a landslide, and by reversing enough the entrance into the building will become unblocked.
A more interesting gameplay situation: There is an exploding car and the various windows, sheets of metal, engine parts, etc are all flying through the air. By pausing at the right time, the player can jump between the bits of the car to reach a higher ledge. A more morbic/comical example that we like to mention involves jumping between dead bodies being thrown from an exploding bus.
Challenges
There's a couple potential pitfalls here.
1. Differentiate this game from Braid or other time-based puzzle platformers. The gameplay would actually be quite different from these games; it's more about exploring in 3 dimensions (with the third being time) than finding a single solution to a puzzle. The fact that the player is independent from time is really what makes it different. But still, the obvious first reaction to this game is "that sounds like Braid!"
We can combat this in several ways. The most important is coming up with a tagline/pitch which makes it sound totally different - we should highlight the premise more than the puzzle mechanics. "Play with time!!" is old hat. The game is more about the exploration and isolation (at least to me.)
The next thing we should ensure is that we have an art style that goes along with this. If we decided to do a painterly whimsical art style, we'd be screwed. We need to come up with two or three cohesive but different styles, for when the world is frozen vs. when the world is playing forward/reverse.
Finally, we just need a solid story that presents the game as a unique work. We have many different ideas for this, and we'll be figuring this out soon.
2. Make sure the game mechanics stay interesting!
It's very difficult to tell, so far, if the game is going to be fun for more than 5 minutes. The puzzle/platform mechanic might work well for a while, or it might become easy and obvious quickly. We have many options for how to extend the mechanic or add new ones, but this is something we're going to have to figure out. The solution to this is testing and prototyping, over and over.
I guess those are the two main challenges for now. First real prototype coming soon.
Time Game - Tech Demo
We're taking a rapid-prototyping approach to game design. I'll post the old fire game prototypes here later. For now, here's the most recent tech demo:
Demo
The demo is in two parts. In part one, a physics simulation runs with randomized objects. It executes for ten seconds, then goes to part two. In part two, you control a character who is put in the world at the end of the ten-second simulation. The player can move around with the arrow keys and control the passage of time with X (play in reverse) and C (play forward). This second part does not simulate physics at all, other than collision detection with the player! This means we can make enormous simulations and precompute everything, and the game will still run at really high FPS.
Coming soon: A prototype and brief design description of the actual game.
Demo
The demo is in two parts. In part one, a physics simulation runs with randomized objects. It executes for ten seconds, then goes to part two. In part two, you control a character who is put in the world at the end of the ten-second simulation. The player can move around with the arrow keys and control the passage of time with X (play in reverse) and C (play forward). This second part does not simulate physics at all, other than collision detection with the player! This means we can make enormous simulations and precompute everything, and the game will still run at really high FPS.
Coming soon: A prototype and brief design description of the actual game.
Subscribe to:
Comments (Atom)