runhello.com

Mac build (r59)
Windows build (r59)

Status: Only had a little bit of time to work on this today. Spent it on trying to implement motion blur. It isn’t going well.

Mac build (r56)
Windows build (r56)

Status: Trying something that may be a dead end.

I adapted some code from my other project and added a shader postprocessing step where I can apply an arbitrary amount of blur to the screen at every pixel. I’m eventually going to try to use this to add motion blur and some other effects. For now, to test it, I set it up where it’s applying waves of blurring that sort of march across the screen. To make the effect more obvious I turned the “blur” up to a cartoonish level, but you can adjust the blur factor by pressing F5 and mouse-wheeling over the little control that appears. When you turn it down to -32 or -40 you get an aesthetically pleasing wavy effect that actually looks like a proper blur.

I’m not even totally sure if I can get away with using this effect. It slows my mac to a crawl whenever the window/screen is bigger than 1024×768 (though, there’s a reason for this, and maybe I can work around it) and it seems like maybe overkill for a game where literally everything is a single-color rectangle. Hopefully I’ll be able to adapt it into something interesting though…

Mac build (r51)
Windows build (r51)

Status: Collision detection improved. You can shoot “past selves”, and they can shoot you. Being shot has no meaningful effect yet, but you can do it.

You still can’t collide with other players or copies of yourself, players just pass through each other. I’m really not sure what should happen when you do that. Clearly if you’re just sitting there and a “past self” player runs into you, you should be pushed out of the way. And something should happen if a snap causes another player to spawn on top of you. (Telefragging? Cuz telefragging sounds lame to me.) I’m not sure there’s a sensible way of dealing with this, other than either turning Chipmunk back on or reimplementing large chunks of Chipmunk in an ad hoc fashion.

Mac build (r50)
Windows build (r50)

Status: The snap works. Press space bar to jump 5 seconds back in time. (When I’m playing with the gamepad, I map this to right trigger.) Bullet physics also work now, or at least, bullets can collide with things.

Limitations: You can coexist with the past but you can’t change it. You can shoot “past selves”, but (1) they can’t shoot you, their bullets just pass through you right now and (2) shooting them really has no effect since bullets don’t do damage yet. There’s no kind of visual effect associated with the snap right now so squares just kind of appear and disappear jarringly and it looks “wrong”.

Is the sound effect on “shooting” too annoying?

Mac build (r46)
Windows build (r46)

Status: Time loops now! Every ten seconds a copy of you will spawn on the screen and begin replaying your actions from game start. Also, there is sound.

Things are still pretty primitive. You cannot interact with the copies. Chipmunk physics is now disabled so there’s nothing stopping either you or your bullets from going off the screen. There may be a problem now where framerate chugs every few seconds while lots of bullets are being fired. And you can’t time travel yet. Still, this is the first demo where you can see a sense of what the eventual game might be like.

This update includes what I think may be my favorite line of code I have ever written:

forever now;

Mac build (r39)
Windows build (r39)

Status: Fixed the problems with the controller code I discovered after posting last night. Analog stick setup is less stupid sensitive now and the 360 controller is now fully supported.

I also changed a whole bunch of stuff you can’t see.

Mac build (r36)
Windows build (r36)

Status: Gamepad support is now complete and controls are now configurable. To set the controls for a player, click “Set p#1 Controls” or “Set p#2 Controls” at the main screen and follow the instructions. Controls are not saved when you quit the program yet. I recommend using a gamepad’s dual analog sticks to move and fire if you can.

So far I’ve tested the controller code with: Keyboard; a Sony Dual Shock 3 (on a mac, using the tattieboogie driver); and a vintage “Gravis Gamepad Pro”. But I haven’t yet tested anything on Windows, and also different brands of gamepads behave very different in SDL so the fact that I know these two gamepads work doesn’t say much about whether other gamepads work.

So I’d be extremely curious, if anyone out there has a gamepad, if you could test and see (1) could you configure your controls without incident (2) could you then play the game (…to the extent it can be played right now) and have it work. I am particularly curious whether this code works with the XBox 360 gamepad, and in particular, I’m curious whether the 360 d-pad works. The 360 gamepad does its d-pad in a weird way that requires an entire code path to itself to handle, but I don’t have one to test with.

A little amusing thing: I don’t impose any rule that different players each have to have their own gamepad, so I realized it was possible to set player 1 to control with the analog sticks on the Dual Shock and set player 2 to control with the d-pad and face buttons on the same controller. Despite my jokes about Twister before, I’m actually sort of considering encouraging people to play this way with two people! I attempted the 2 players, 1 controller thing with my spouse and it was actually weirdly workable and fun in a silly way (the configuration we settled on was player 1 had d-pad to move and right analog to fire, and player 2 had left analog to move and face buttons to fire).

Update: I found someone with a 360 gamepad. It works, but the d-pad does nothing. Oh well. Another thing I’m noticing is when you’re setting controls it’s way too sensitive about when it goes ahead and sets an analog stick axis, so it’s really easy to accidentally set your controls “sideways” if you accidentally push up a little and then left a little when you first touch the stick. I’ll fix this tomorrow.

Mac build (r23)
Windows build (r23)

Status: Same as yesterday but now there is rudimentary gamepad support. Player one is still controlled with WASD+IJKL. Player two is controlled using the dual analog sticks of the first HID gamepad found. In my tests I used a Sony Dual Shock 3 using the tattiebogle driver and it worked; I wouldn’t especially expect it to work on anyone else’s system until I’ve added the ability to actually configure controls.

There are buttons in the main menu for setting the controls. They don’t work yet.

Doing the geometry wars thing and controlling my little square shooting its little bullets using the dual analog sticks was actually startlingly fun considering the game doesn’t actually do anything yet. I’m feeling better about the whole top-down shooter plan than I was yesterday.

Mac build (r21)
Windows build (r21)

Status: Option of 1 or 2 players; in 2 player mode there is a blue and a green player. Each player can now fire bullets (the small squares). Player 1 moves with WASD and fires with IJKL; player 2 moves with FXCV and fires with HBNM.

But there’s no collision logic on the bullets yet, so they just bounce around and accumulate in the corners of the screen.

Thoughts:

• I cannot help but think. What if I just stopped here? Like, maybe added damage from bullets and said, okay, here’s my 2p arena shooter. How on earth would anyone play this? The WASD/FXCV scheme would require the players to configure themselves in extremely odd ways to reach the keys; Player 2 would basically have to be sitting in Player 1’s lap. Perhaps we can think of this as an activity for couples.
• These controls can’t stay even if the Twister problem is fixed. Firing diagonally is really difficult with the IJKL aiming.
• Maybe I’ll have to rethink my position on physics. The more I start moving toward actually implementing the time/replay mechanic, the more it starts to seem like implementing physics would be really, really easy. (In fact it may be easier to implement full physics than not implement it– the current build has some really weird behavior due to the fact I’m using Chipmunk for collision detection but then in my first-pass way of doing movement I’m treating it in ways a physics engine does not expect to be treated.) The big problem with physics though is that the world I present– 1 black screen, 2 autonomous squares, bullets that are destroyed on impact, unmoving walls– gives very little opportunity for a physics engine to show off its presence. Of course I chose this gameplay idiom specifically because it imposed simple physics and made the mockup easy to finish, but it means if I try to think of “what are cool flourishes a physics engine could add?” I don’t have a lot of room to maneuver.

  I’m increasingly starting to wonder what this game would be like if instead of a top-down/Combat! sort of thing it were a vs. 2D platformer where the players had free-shooting guns (like in All Of Our Friends Are Dead, or something) and were free to run around and jump and fire at each other. That would give the physics engine a lot of neat stuff to do and might simplify things like how to present the controls. I have doubts I could get this done for the competition deadline though so maybe that will have to be something to consider later.

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.