The Snap, development log: Day 1
So Tigsource is running a 1-month game competition with the theme of “versus” play. I think I’m going to use this as an excuse to quickly knock out a prototype on an idea I had a long time ago, and while I do so I am going to try a Thing. Every day I work on this project, I am going to come back here at the end of the day and post my current build and a screenshot, so that you can see a record of the project developing day by day (the first build can be found at the end of this post). I will also be posting these logs in my project thread at Tigsource.
The project is this:
The Snap
(A first person shooter)
This is an idea that sprung out of two conversations: One years ago with my friend Chris about how you could make a game with four-dimensional gameplay; and an argument a bit more recently with some people I know about my opinion that first person shooters all feel the same to me, because they seem to me to just provide the same gameplay from game to game while changing only superficial tweaks to mechanics. After this argument I started trying to think about whether I could come up with a mechanic you could introduce into an FPS that would alter gameplay fundamentally rather than just presenting a more refined version of that same gameplay mode.
Here’s the basic idea:
- Deathmatch FPS. Machine guns. Scattered ammo packs. Health canisters.
- Gameplay takes place in a room or building where time is occurring in a loop, say 60 seconds long. All players materialize in places throughout the building at time 0. At time 60 copies of the players rematerialize in their starting positions and the game “replays” their actions from that point.
- In addition to their weapons, each player has the ability at any time to perform a “Snap”. When they do this, they jump back 10 seconds in time. (If you jump back before time 0 you loop back around to time 50-something.)
- A multi-track timeline at the top of the screen shows where each player is “now”. Because the snaps only move you a fixed amount, at any one moment in “real time” there will only be (say) six points in the in-game timeline each player could be at.
- Changes to the timeline propagate. So if you shoot someone 10 seconds in the past, they lose 10 health throughout the timeline after that. If someone grabs an ammo pack, and then you jump back in time and grab it before they do, then they lose 10 bullets throughout the timeline after that. If you fire a bullet, and kill someone, and then someone goes back and retroactively steals all your ammo so that you did not in fact have any bullets at the time you killed the other player, then your bullet fire is undone and the player springs back to life.
- The hope is that the game will thus be about strategically managing the timeline and trying to cause, or retroactively prevent, certain events, rather than just about shooting and cover.
The plan I had originally was:
- 4 players, on 2 teams. This allows for the interesting “resurrection” mechanic of trying to bring your teammates back to life by preventing their deaths.
- Actually a first person shooter
- Some sort of networked multiplayer
- Physics of some sort– you can push people’s “past selves” out of the way as you run past them, for example, and physics would “rubberband” so that the past selves simply run a little faster around you to get to the point they were supposed to be at for the next “event” (like getting hit by or firing a bullet). The game would attempt to present an illusion that small changes to the timeline (like shoving people two feet) correct themselves but large changes (like killing someone) alter the timeline and propagate.
But I didn’t think I’d ever actually find the time to do this, so at some point I mapped out a simpler, “mockup” version I thought I could do in a month. This is what I’m doing for the compo:
- Overhead Robotron 2084 style shooter, Apple // graphics, maps like Atari “Combat”. All players are colored squares. The game will still be prominently labeled “a first person shooter” as a joke and/or commentary along the lines that “FPS” is a type of gameplay rather than a camera angle. The game will make as few acknowledgements as possible it is anything other than a 1990s cliche FPS. For example the blue square will be “Biff, the grizzled space marine” and the red square will be “Sophia, the beautiful and brilliant scientist”
- No physics, no networking. In order to make multiplayer still possible, maps are probably no bigger than one screen and players probably need to use gamepads.
- Also to accommodate the above, probably only 2 players.
- Z axis and jumping [i]might[/i] be included.
The mockup should be enough to at least try to identify where the “exploits” in this type of gameplay are (i.e.: do players just repeatedly jump back to time 0 and try to pump bullets into the helpless past selves? And if someone tries to play this way, are there countermeasures the other player(s) can take?) or determine if the game concept is workable at all. I intend to write the mockup in a way I can move it forward to the “full” concept if the opportunity ever presents itself while maximizing code reuse.
Pitfalls:
- It’s been a long time since I’ve actually played any FPS type games, so I may wind up reinventing some gameplay wheels
- The “mockup” version seems like just an arena shooter. I think there have been a lot of these in indie-world lately; I haven’t really been playing them. I may wind up again reinventing some wheels or producing something not terribly different from existing arena shooters
- Will continually having to re-adjust the “timeline” be excessively computationally expensive? I think I know how to do it such that the answer is “no”, but I’ll have to watch out for this.
I started coding this morning, and as promised here’s my progress so far:
Day One
Mac build (r19)
Windows build (r19)
Status: It draws a black screen with a green square. If you use the WASD keys the green square moves around.