As many of you requested, I’m not going to document every feature that goes into this thing. This means we’re going to jump ahead and start talking about stuff I’m dealing with now-ish. A side effect of this is that you’re going to see unexplained features appear and be tempted to ask, “But, what is this feature and how does it work?” Understand that the answer to that question would take a post. A post which would have precluded the writing of this one.
You can’t trick me into writing twice as much by asking me to write about current stuff and then asking me to fill in the blanks in the comments. Well, you CAN, but it’s going to make for a less interesting series for everyone. So just get yourself into some sort of zen state where you’re okay with seeing unexplained mystery content.
So on Friday I talked about the line-of-sight system I came up with. A few people suggested a completely different way of doing it that would be many, many times faster. And now we come to the part of the project where we have to make the hard choices.
See, there’s one thing I didn’t mention on Friday. That’s this:
The visibility system I devised had this side-effect where it was super-easy to implement this “flashlight mode”. Actually, “implement” is sort of overstating it. It implicitly WAS flashlight mode, and I’ve just been setting the beam to be 360 degrees wide.
It’s really cool, and you kind of need to see it in motion to appreciate just how suddenly panicky and claustrophobic the game feels like this. This was an accidental discovery while working on the LOS system, and it was so interesting I began toying with the idea of making it part of the game.
(The foes depicted are these spinning sawblades that try to swarm you and chop you to bits. They look strange to me in freeze-frame like this, since in-game they’re always spinning.)
On the other hand, it’s friggin’ HARD. Hard enough that it changes the entire feel of the game. Foes are really good at approaching from all angles and in flashlight mode you can’t dodge their attacks because you can’t see them coming. If I went this route I’d be leaving behind the fast-paced dogfighting of my original concept and sliding into something with the pacing of survival horror: Edge forward, fire some shots, back off and check behind you. Move slow, flush enemies out, and try to keep your back to a wall.
It’s a totally different game.
The typical gutless design approach is, “Make it an option!” That was my first instinct. But really, these are two very different games we’re talking about here. They each demand different and mutually exclusive approaches to AI, art, weapon balance, and enemy design. Heck, even non-gameplay stuff like music needs to change. You don’t want the jaws theme creeping along in the background of the burly brawl and it doesn’t make sense to have Keep Hope Alive thumping away while the characters search the haunted house with the dodgy flashlight, whispering to each other and jumping at shadows.
When you’ve got two divergent gameplay modes like this you can:
- Neglect one mode in favor of the other. (Try our game! It comes with a tacked-on second game that’s not worth playing!)
- Build two different and mutually exclusive games. (Because time and money are no object!)
- Split the difference and make two crappy games instead of one good one. (Because we don’t have a clear vision!)
This problem should sound familiar to any developer forced to add mutiplayer deathmatch to their single-player game.
As much as I hate to kill this flashlight mode idea, it’s too far from my original concept to be added on and it’s too different to coexist.
I spent all day Friday thinking about the wall-extrusion idea that was proposed. It was eating at me, so I decided to try it out. Here is how it works:
You look at the area directly around the player and find all the line segments that form the walls.
For every wall, you take the endpoints and draw a line from the player to those points.
Now give those points a big ol’ shove along the direction of that line.
Now use the new and old points to form a polygon. Draw it.
Do this for all the walls in the area and you get shadows. No line of sight checking. No fussing with collision.
Now, the game runs plenty fast and I didn’t need to do this for performance reasons. But this wasn’t really about performance. This is just a better way to do this.
- This new system creates pixel-perfect shadows. The old system still had a little bit of wibble-wobble when looking around corners. This way is flawless and smooth.
- This new system is about 50 lines of code smaller. Somewhat counter-inuitively, programmers love it when they get to delete code. (Well, deleting recent code stings a little.) Less code means less text to wade through, less to document, less to worry about and less to examine when things go wrong. Making something with less lines of code is like making an airplane with less metal. It’s just good engineering. (Assuming, of course, you’re genuinely getting rid of lines of code and not just packing the lines together using tight spacing and “clever” formatting tricks. Don’t get me started.)
- And if you DO happen to care about performance: Old system did 1,000 to 2,000 checks, depending on local topography, and always drew 180 polygons. This new system does 25 checks (looking for walls) and draws between zero and thirty polygons. That is, my worst-case rendering situation with the new system is still way, way better than the best-case situation with the old system.
With this new system I would no longer have this cool flashlight mode. Oh sure, I could ADD it with some tricky stencil operations. But that would be adding a feature, instead of having the feature be sort of a byproduct of how you’re already doing things.
Is it worth fussing with the stencil buffer to restore flashlight mode? I guess I sort of spoiled that conclusion earlier in the post. It’s not. It’s a fun gimmick but it doesn’t work in this particular game.
Now, there are a bunch more optimizations I could do here to trim those polygons down even further. For example, some of these walls face AWAY from me and therefore aren’t needed for the purposes of blocking sight.
If I ignored the walls that faced away from the player I could come close to cutting the poly count in half. But right now that would feel like cutting coupons after you won the lottery. Look, I’m as frugal as they come, but we’re talking about an optimization that would – under maximal circumstances – save us ~16 polygons a frame. That’s not even worth thinking about right now.
Well, that worked out as well as could be hoped. Let’s try another community suggestion. Way back in part 2 I talked about having the camera chase you around and some people suggested having the camera fly ahead of you.
It’s pretty easy to look at which way the player is going and just have the camera try to stay out in front of them. The old 2D Grand Theft Auto games did this. As you accelerated, the camera would pull back and move ahead of you, letting you see more of the world. It was facilitating fast movement and rewarding high-risk travel. Let’s give that a try in this game.
OH MY GOSH WHO RUINED MY VIDEOGAME!?!?!
We have many layers of things going wrong here. While I can see right away that this is a disastrous idea, it takes me a few minutes of play to figure out why.
In Grand Theft Auto, you were traveling in a slowly accelerating vehicle with a turning radius. Even the best cars in the game took a few seconds to reach top speed and required half the screen (or more) to perform a U-turn at speed. But in this game we’re controlling a flying robot that accelerates in about two seconds (and most of the acceleration happens in the first half second) and can reverse direction almost instantly. This means that in GTA you would get these wide, sweeping turns, and in this game you get abrupt cutbacks. In GTA you reverse direction rarely. In Good Robot, you spend most of your time zig-zagging through enemy fire.
The result is that the camera has to make huge movements to stay ahead of you. When you reverse direction it suddenly needs to be on the opposite side of you. These swinging camera movements are a roadmap to getting puke on your keyboard. It’s that bad.
The other problem is that you spend a lot of time fighting while moving backwards. Having the camera fly ahead of you will turn this view:
Into this one:
So the camera is often shoving the important projectiles and robots off the screen so it can show you empty space. This is a textbook example of “fighting the camera”, where the challenge of the game comes from trying to get the camera into a useful position without dying in the process.
Well, one idea worked out and the other didn’t. Both were interesting experiments.
DM of the Rings
Both a celebration and an evisceration of tabletop roleplaying games, by twisting the Lord of the Rings films into a D&D game.
Top 64 Videogames
Lists of 'best games ever' are dumb and annoying. But like a self-loathing hipster I made one anyway.
Diablo III Retrospective
We were so upset by the server problems and real money auction that we overlooked just how terrible everything else is.
Good to be the King?
Which would you rather be: A king in the middle ages, or a lower-income laborer in the 21st century?
Batman: Arkham Origins
A breakdown of how this game faltered when the franchise was given to a different studio.
89 thoughts on “Project Good Robot 8: Suggestion Box”
The flashlight thing could potentially get really interesting if you go with the whole “stuff changes as you gets deeper” idea. You could start the game with an open space, full visibility, and then have it decrease as you leave the “civilized” areas.
And then following the survival horror wisdom, there’d be well-lit areas from time to time to give you a breather.
But well, I see you’re not doing it. Good choice. But could be something to base a sequel about, he he. (Not that I’m implying you would be having one, let alone finish the game.)
It made me think of Doom 3 – you regularly entered dark areas where you had to go around waving a small flashlight.
The reason that it made you think of Doom 3 is a big part of reason that he decided not to implement it.
Well if it’s any consolation, it put me in mind of the levels in the Half Life games where the devs say “Hey, you have a flashlight! Let’s turn off all the other light sources and fill the room with monsters! You’ll be fine: you have a flashlight and only just enough bullets!”. IS THE ELEVATOR HERE YET!?!?!
Or, an even better idea, he could have had some levels randomly include that as an element, Spelunky-style (I don’t mean levels randomly adding it, but rather just sprinkling the “darkness” on maybe one level out of every seven). Similarly, other gameplay modifiers like that could be sprinkled throughout.
That’s option 2: Write two games.
Shamus! I can’t believe you forgot to tell us that the little robot guy is now blue instead of red.
Maybe you could file away this flashlight-mode idea for later? You’re bound to get Programming Fever a few more times in your life. Focusing on both at the same time is counterproductive, but if you finish (such as it is) the game-as-is now and find the time and/or money to do the other variant later, you could have them both. Or maybe you could make an entirely different game just around that concept, and optimize it that way.
You know. In the future.
Looks like Good Robot (or, as I call it, WALL-EVE) can be either red, blue or green. (Maybe it’s a major, plot-critical choice that the player makes at some point…)
Currently your character color is set based on the power level of your laser, which goes through the rainbow from red to violet. So at any given time color is based on how much I’ve upgraded my laser. It’s useful for testing.
Your robot wouldn’t happen to be based on Friend Computer, would it?
Ha. I forgot about the paranoia color-coding.
No, this is based on Descent, where your lasers would upgrade as the game progressed. Different color, different sound. Always felt good to get the next laser upgrade.
I’m really digging the “2d Descent” vibe. Even the look of the robots works for it, and yet it’s stylized differently in a way that looks good for the 2d perspective.
Besides the cosmetic effect, are the laser upgrades purely numeric (more damage) or do they also behave differently (eg. broader or longer-lasting beams), similar to how you mentioned upgraded bullets go faster?
As you could guess, I hope it’s the latter. One thing I really appreciate in games is when upgrades bring actual changes in gameplay, rather than just keeping up the lazy treadmill of giving you a +2 sword to beat the new enemies’ +2 armor.
Sorry for being unclear, but bullets = lasers. Internally I called the lasers “bullets” and sometimes that slips out.
Yeah, upgraded bullets are larger, faster, hit harder, look brighter, have more satisfying sound, etc. Both mechanical and cosmetic improvements.
As for the problem of “her’s a +2 sword, not fight foes with +2 armor” problem – I have a big post on that coming up, so I’ll wait until then.
You don’t have clearance to know about any Good Robots that may or may not have been based off Friend Computer, citizen.
(…Duh. Of *course* you don’t have clearance! You really should have seen that coming. :-P )
I’m going to assume it’s a side effect of the lighting system; the old system had light exploding from the character in all directions, causing it to glow from the heat. Now that it’s not a constant omnidirectional light source it’s cooled.
I kind of wonder if the flashlight mode could keep enemies and their projectiles on screen after you see them. Then you’d have initial tension of trying to find them all without the frustration of not being able to see and dodge everything at once.
…black-body radiation with a blue tint is higher-energy(and therefore hotter) than black-body radiation with a red tint.
Maybe the reason it can’t do the flashlight thing anymore is that it’s too hot, and focusing the light would prevent sufficient radiation of excess heat.
Maybe you could use the flashlight with some, but not a lot, of global vision? So the flashlight sees further, but you get to see a shorter way off behind you.
Maybe the environments are too small for that to make much of a difference to normal play though…
What if the computationally cheap 360 method mapped the region in which you can see glowing bits in the dark (enemy eyes, running lights, contrails, missile exhaust, plasma bolts, etc.), and the flashlight is used to see enemy silhouettes?
A fun enemy then might be an angler fish analog, something with a glowing lure held well away from its hitbox. Another could be a wall-crawler that looks like a bit of stone while in the flashlight, opens its eye(s) and attacks when your back is turned, and then is rendered inert when the light returns (Crying Angel style).
I’ve always been more on the gameplay design side of game development, even if I am far too lame to actually make anything. I can’t tell you how many times I am playing with an idea and soon enough I really have two ideas. That is why I pretty much follow the old school rule of making one part fun before moving on and complicating everything.
Granted I can’t tell how much playtesting goes into each idea but it does appear you are tending to follow that rule.
Now, as it is now it looks like the game will be pretty cool, but I have learned that modern gamers are too used to incentives in video games. People like the feeling of accomplishing something. It is why MMOs exsist, it is why “upgrade” systems are so prevalent even in games where it makes no sense. I am not saying these things are inherently good ideas, but rather playing on the carrot on a stick premise isn’t a bad one.
I am not going to suggest “add upgrades, and stuff” but rather to consider that, if you plan on ever taking this to market, consider the carrot. So far we have no backdrop or lore, but given the name and enemies, going to go out on a limb of something like “Good robot is being chased by the bad robots into the dark depths as they search out X to do Y”.
While I am not sure any one of these ideas would facilitate what you are going for I’ll throw them your way anyways and you can call me silly later.
1) Differing Depths: People like finding new areas with new things, to keep people going deeper have the design of the areas change as you go deeper. Sure this means developing more time on art assets but as long as you play it right, it doesn’t have to be massive sweeping changes, and even if it is with this art style and procedurally generating terrain, small tweaks make big differences.
2) Events: Part of what keeps people moving forward is having the next objective in their sights. Saying simply “Get to the end” will make some people giddy, but if that distance is a ways off some people will be put off. I know that this is kinda designing for the lowest common denominator but most people like getting things done.
Include small mini objectives along the way “reactors” or “building plants” to be destroyed, maybe even small sub maps. Or maybe even fellow good robots that need rescuing (people like to feel like the good guy, especially when the title implies it).
Running off with the “savior” idea, you could have a sub passage that while the player is floating on by they get a sound effect from off screen in the direction of the side tunnel. The sound could be the same kind of noise when your character gets damaged. No text, no speech windows, no long explanations and people will probably take the audio cue as “Things are happening over there and they don’t sound like things I want to happen.” You go down that way, kill some baddies, and rescue good robot.
These two are just two of many ways to help incentive driven gameplay, and will add variety and prevent stagnation, without altering gameplay; just giving it a new meaning.
3) Upgrades: You could go in a lot of different ways with upgrades obviously. Metroid style pick-em-ups, “money” driven with stores, without stores. They all have benefit of mini-accomplishments. The “I GOT THE THING” feeling definitely helps.
4) Collectables: Not inherently the same thing as Upgrades, as they generally tend to effect gameplay heavily. These are things like trinkets in VVVVVV. They don’t necessarily change how one plays the game, but rather gives them a quick short term objective. They see it and go “hm… how would I…”. Not only does this help mix it up, it allows you to make challenges that most players wouldn’t be capable of; but simply by making it optional some people will go “Challenge accepted” and others will give it a shot or two before saying “hmm… no”.
5) Bosses: This is a long standing method, but frequently doesn’t fit the games it is put in (As seen in… you know what screw it, the list would go on forever with modern games) but in this old school style of shooting things, a decently made boss could help display progress to the player nicely. The feeling of “Yeah I beat the dude” goes well with the “I am getting further in this game!” feeling.
Alright well I am running a bit long, and I understand it is your project; don’t mean to armchair design, just want to provide avenues if you haven’t thought of or considered them. In my opinion, failing to properly give incentives can really harm a game.
I’d like to see the game go Descent on this one. Namely with regards to “Destroy the reactor in the base and then use the exit.” gameplay that game had.
It and Major Havoc both did this, although the latter didn’t make the exit different from the entrance, which added a whole new level of exploration in that game.
Either way, some sort of that type of element would be fun to see – not sure if Shamus would change it to something more specific to this scenario, but that’s the type of thing I’d in regards to the game.
Wooo! I made a difference! :)
Also, can’t you draw with both “colors” on the stencil buffer? So couldn’t adding a flashlight work like this? :
1. start initialized to all “shadow”
2. draw a triangle of light on it for the flashlight
3. draw the shadows the same way
But the 360Â° vision sounds more like my kind of game so I vote for that :)
Well technically, a stencil buffer value is only a single value (ie: a grayscale). The interesting things you can do with a stencil buffer come from the fact that you can both decide which values in the buffer allow drawing operations to change pixels, as well as interesting ways to affect the stencil values. One interesting operation is that you can set/clear/test individual bits in the stencil buffer.
Thus a flashlight could be done as:
0. Clear all stencil bits.
1. Draw visibility (in this case draw wall shadows) by setting bit 0.
2. Draw flashlight beam by setting bit 1.
3. Everything lit has a value of exactly 2 (bit 0 clear, bit 1 set).
Also with this scheme the flashlight beam can be any actual shape. The obvious cone centered on your character, could be as wide as the robot when leaving the robot. You could also add a circle of light around your character, so that an enemy that sneaks up on you is visible for the last second, giving a nice jump-scare before the actual pain happens. In essence, the shape that is merged with the visibility set is pac-man with ice-cream cone stuffed in his mouth.
Then again, that’s probably an idea for a different game.
Another fun thing you could do is gradient mapping on the stencils, and draw negative maps with the back-faces. Add them all up and it would give you an accurate “through the ground” depth. Then you could use the “flashlight” as a ground-penetrating radar thing, allowing you to “see” through the walls. Then jitter (or blur?) the pixels by the relative depth, and you end up with a noisy x-ray vision! Good enough to tell gross position, but not good enough to identify specifics unless the barrier is very thin.
So many fun possibilities. So little time.
That would change “Flashlight Mode” from being a really obnoxious mood killer into being a totally awesome powerup. I like it.
Also, for implementation of “Flashlight Mode,” it would be easy enough to simply draw another set of shadows on the stencil buffer on top of the already-present shadow-casting code.
I like the new shadow system, too. It’s even faster than my suggestion.(Probably by 2-4x)
Ooo… I like that idea.
Isn’t it awesome, making a comment then seeing it made?
I know I feel awesome, even though like three other people had the same idea as me at the same time, and my path to getting to the solution was so convoluted it lead to a “cutting coupons after you won the lottery” burn.
To be fair, I needed to cull those edges in my first thinking because at first I was stuck on fans using the facing edges as vertices after reading the article. Also dang it, I was PROUD of that math-that-was-solved-twenty-years-ago-by-3D-Programmers. :p
One idea for how the camera could work:
Make it extend in the direction your crosshair is pointing. It could center on a point somewhere between your avatar and the crosshair, about 1/2 to 2/3
the length should do fine, would be my guess. This way you get the feeling you’re looking around, focusing on targets etc.
It has it’s drawbacks of course, let’s say you’re fighting two enemies on both of your sides, if you aim at one of them, the other one will most likely end up off screen. But, you could make it a part of gameplay this way.
So in the aforementioned situation, instead of moving the crosshair all the way towards one of the enemies, you could keep it close to your avatar. Aiming would be harder and less precise (you could say it would be the equivalent of firing your weapon from the hip), but you’d keep a fairly even view distance, allowing you to see and dodge shots from all directions.
There’s plenty of games that use this setup, and personally I think it works pretty well. Thought I’d throw it out here in case you’d feel like tinkering with the camera a bit more =)
Sounds like it would run into the same problem of “this game is too fast-paced for the camera to shift whenever you do something routine” and “the real enemy is the camera” that the last feature had.
Also, somewhat unrelated, I don’t like when the crosshair can be moved in and out; my hand always moves forward and the darn thing always ends up somewhere I don’t want it.
Bloodline Champions does it like this, and it’s a great PVP game to boot. I highly recommend installing it for research purposes, as it’s F2P anyway.
I suspect Shamus has plenty of things to fix that are, in fact, broke.
The camera actually seems to be working fine the way he has it now, so . . .
It kinda feels like dude’s staring right at me when he should be looking where he’s going
Good-Robot looks like he’s flying sideways and winking at me. Which is kind of a neat personality quirk -half Chow-Yun Fat and half Keanu Reeves.
Does the robot always keep the missile launcher on the right, or does the robot turn around when you change directions?
RE: Flashlight mode:
I could see that being very very useful for certain levels – or caverns – as opposed to the majority of the game.
If you want a hero’s journey type progression, it’s a perfect way to set up The Ordeal section – tension and fear replace power-curve progression for a bit, as you have to deal with elements and emotions completely out of your depth or experience.
Or even to break up normal play – even fun gameplay gets repetitive after a while.
Yeah, sounds like something for a particular boss or zone to me. A break in all the action pew-pew type gameplay.
Of course, when those sections get designed wrong they can completely ruin a game. Maybe a secret Easter-egg bonus level?
Or mayme jus go full mechwsrrior with it:
1 you have two “radars” passive (all around you) and active (cone of light in front of you, it can even shine through walls)
2. if you want to / have to (enemy missiels targeting active radar, blind suicide enemies drawn to active radar?) you can switch off Your active (passive to? That would leave you blind though) radar maybe it can ba damsged / upgraded / have differend modes (you have missiels targetet with longer range narrower active radar? )
Like Halo had the tunnel sections, kinda, or how the parts with the flood feel totally different than the parts with the Covenant.
I think you can have the camera in front of the player without abrupt changes in velocity. Attach it to the player with a ‘rubber band’, so it lags behind, if you make sudden movements and then catches up, but then tries to overtake you when you fly in roughly the same direction for a long-ish amount of time.
Fire Fight, a 1996 top-down futuristic shooter with a similar feel, had the camera stay slightly in front of you at rest, but it only starts moving if you’re outside the dead zone in the center of the screen, and it accelerates slightly slower than you do. So if you’re constantly bobbing and weaving, it will stay stationary, nudging here and there if you make sudden movements. If you punch the afterburners, you’ll be slightly ahead of the camera for a few seconds, to give the feeling of speed.
I can think of one way of combining the 360Ëš vision and the more narrow (90Ëš, I think, in the image) flashlight. Simply allow for a cone of “longer vision”, but I suspect it doesn’t actually make sense and/or make the game better. But, if there’s screen outside maximum player visibility, having a power-up that gives you a small wedge of longer vision is a time-honoured thing in computer games (the long, narrow scans and short, omni-directional scans in the Star Trek game, back in the age of the cave bears, eh, I mean text terminals, definitely had it).
So the results of the camera experiment are an accurate reproduction of the first few BioShock episodes? Awesome!
And why did the image for a secret room with funky music, disco lighting and several robots, dancing and blinking through the color spectrum, form in my head?
I vote the flashlight be level based. One or two missions have you sneaking around a different area. Music changes, and the game has a slightly more claustrophobic feel for a bit.
Or… a temporary negative power up. Or set it as an enemy attack- get hit by a certain bad guy, and it lasts for like ten to thirty seconds.
Or something like that.
Maybe some levels are dark (moving through dark narrow tunnels perhaps) so you need to use the flashlight for that?
You could also play around with line of sight for the enemies too, make it so that in some areas like that the enemies are like boos that only move at you when you aren’t looking at them, or have enemies with their own visible flashlight line of sights that you can stealth around to avoid fighting? Not sure if something like that would fit with the rest of the game, maybe if you had a level where you lost your weapons (or maybe haven’t gotten them yet).
That last screenshot appears to have a shield.
What I’d like to see is a trade-off between shields and armour. The idea is to let the player choose either to focus their attention and concentration on either mooks or bosses.
Shields would regenerate, and a good shield with reasonable piloting should be able to last forever against moderate swarms of enemies. However, it would risk sudden ignominious death against bosses or large swarms.
Armour would not regenerate, and good armour would be able to survive not only bursts, but bursts of bursts, such as three direct hits from a boss. However, even a series of lone enemies would eventually wear it away without perfect piloting.
It would also serve as auto-balancing. If the game is heavy on bees, the players can all pick shields, and if it’s heavy on powerhouses they can all pick armour, mitigating the imbalance.
Yeah! It certainly does look like shields.
Of course it could very well be something else. Maybe “heat” that has to be dissipated by moving quickly (forced convection). Maybe a visual indicator of threat level, or proximity to some objective.
There are lots of novel options for shields as well. How about using shields as ammunition? Shooting drains your shield, so you can choose between killing foes and racing through. Different kinds of shields that are strong versus various kinds of attacks. Shields that block your vision, so turning shields up to full isn’t always ideal. Etc.
I think you’re completely right that switching to flashlight mode slows the game to a crawl and turns it into a survival horror game. If you DO want to keep the flashlight though, how about this:
Vision within the flashlight beam is normal. Anything else nearby, but not in the flashlight beam, becomes like a radar screen. You see “blips” and know where an enemy is and how they’re moving, but not what kind. Slower moving projectiles (e.g. missiles) would also appear, but not necessarily lasers?
Trying this would, I think, keep you in a “frantic move and shoot” style of game, but add even more panic/paranoia when you constantly have to swing the flashlight all over the place to see who/what is after you.
Perhaps you can even fire at “radar objects” with your lasers… but to use missiles you need flashlight LOS?
You could also have a circular region right around good-robot that is “full view” as well. Just in case one of the bad guys in the distance fires at you with lasers, you still see the laser before it hits you… giving you time to dodge. Can’t tell what speed things are moving at from the screen shot, so maybe not seeing lasers until they’re really close won’t help. :)
Something I have to ask, because it’s always been a pet peeve of mine in shooters, is:
Do the player’s bullets travel at a speed comparable to the player?
And if so, does the player’s speed add to the bullet’s speed in accordance with Galilean invariance?
It always bugs me when velocity addition isn’t implemented in ways that are obvious. In games where the bullets travel much faster than the player, it’s hard to tell and it doesn’t matter much. But when I’m moving and firing in the same direction, and the bullets bunch up in front of me, well, it bothers me. Like if dropped objects in an FPS bounced higher on each impact. It’s just not how things work!
Unless, of course, it’s because the bullets travel at light speed, but then you’d have to account for special relativity, as I’ve mentioned earlier. Since then, I’ve found that there is a “game” that implements special relativity, A Slower Speed of Light, by MIT Game Lab. There’s even an open source engine for it.
Have you considered adding special relativity as a feature?
I’m still on the fence about what to do with bullet velocity. In this game, your bullets speed up as you level up your shot power. So if you put all your points into movement speed and nothing into stronger bullets, then you’ll actually be able to outrun your own shots. This would be true even if I added Galilean invariance, since you could fire at a standstill and then overtake the shot.
I COULD add your speed to the speed of the bullets, but that would mean your aiming reticle would be flat-out WRONG. And if you’re using a controller, that reticle is based on the position of the right analog stick, so “correcting” its position would be a no-no.
I’ve played around with bullets having both absolute and relative speed, and absolute FEELS more correct right now, even if it isn’t accurate to how physics ought to work.
But we’ll see how it feels as gameplay develops.
Well, now that you bring of leveling shot power, where bullets get faster as you level your shot power, what if it worked both ways, and you can deal more damage by giving your shots a higher impact speed by moving in the direction you’re firing?
As for the reticule being wrong, I think it depends on how you look at it, because I disagree. To me, it’s actually absolute speed that makes the reticule wrong, because it means that your shots won’t pass thru your reticule when you’re moving at a constant velocity, except for the special case in which your velocity is constantly zero, and which also completely removes the need to account for your own velocity when leading your shots, which seems to me like a strictly less-interesting gameplay mechanic.
Though, I suspect that dealing with velocity addition is easiest if the camera is locked to the player’s position, rather than having it bounce around as you change velocity.
and which also completely removes the need to account for your own velocity when leading your shots, which seems to me like a strictly less-interesting gameplay mechanic.
Less interesting but more fun. I want the crosshair to tell me what I’ll hit, not what I would have hit if I’d fired a second ago.
(Although you could add some text about how the computer automatically corrects for Galilean invariance when firing. It sounds like it wouldn’t apply as much if your shots were fired with variable amounts of force.)
It could even be an option for hardcore people, like turning off MacGuffin highlighting DX:HR. “Disable Galilean invariance compensation algorithm” or something. Then all the problems of leading your shots and being able to overtake them become an active choice for the player, so they can deal with the consequences of their choice.
In fact, the “problem” of projectiles moving slower than an accelerating player reminds me of this article on procedural generation of guns for an fps. Here’s the relevant quote:
“Another interesting weapon had a projectile speed slower than the running speed of a player's avatar. This initially made us dismiss the weapon… however, after a few evolutionary iterations we accidentally uncovered a weapon that combined slow projectiles with a low gravity effect on them, high damage, and a very high magazine capacity. This turned out to be a nearly perfect defensive weapon, since a player could use it to blanket a hallway with slow moving projectiles.”
If, say, you tended to be chased by a lot of buzzsaw enemies in a particular area, turning off the compensator algorithm could let you lay down a wall of death while standing still for you to carefully slip around at speed and thus cover your retreat so you can focus your guns ahead of you. Though it’d be a hell of a lot more intuitive to just let you drop mines, letting the player do something cheeky and clever is always a plus in my book. Though this does rather depend on it not (utterly) breaking the level design, AI, challenge, etc and not being a lot more work to implement both options with a switch.
Hmmm . . . retreat aside, if you were careful, you could fire a bunch of those things forward and follow them in to a dangerous spot, giving you a nice swept space to maneuver in when you got there.
As long as the bullets travel at a fixed velocity from a turret you can pretty easily tweak the turret angle to hit the target. Other 2d space shooters do this. I don’t remember the math off hand, but it’s just a little vector math that you can probably find online if you can’t remember first year physics either.
Hmm… this could be corrected by putting the crosshair at the position you’re pointing the gun to plus your current velocity vector times the time it’ll take a bullet to reach that point.
These days you need to lead a moving target and also account for your own movement. But couldn’t we assume that in the future a computer would be able to account for this?
You’re looking straight down, you’re shooting straight down. But if you’re moving right at the same time, your bullets will also go right even if you still look straight down. So the aiming cursor would need to be shifted right accordingly, and all’s well. The bullets will go through the point on the screen the cursor was on when you fired the shot.
The question is: Should your shot hit where your reticule is now, or should your shot hit where your reticule will be when your shot hits, provided you change neither velocity nor reticule settings? I think that it’s pretty clear that your shot should hit the location where your reticule is now.
In real-world conditions, you need to lead your target based on their relative movement from you. Firing from a train out at someone on the ground, or from the ground onto a train requires leading the target, but firing from one train to another at the same velocity on a parallel track does not.
Or, put another way : Is your reticule aiming at a point on the screen? Or a point on the environment?
What about having two reticules? One for “This is where your gun’s pointed” and a corrected “This is where your shot will hit” one in different colours? Or even a couple for different weapons with different physics? Kinda like how some snooker games will show trajectory lines for newbies.
You could try adding the dot product of velocity and the unit vector of the aiming reticle wrt the robots position. That is adding only your speed in the direction of the aiming reticle. That would give you Galilean Invariance, but you could still overtake your bullets.
To me, it seems like the math is so trivial (add the velocity vector of the robot to the velocity vector of the projectile) you could just make it an option. It’s an extra edge for player that want to turn it on, because their projectiles will move faster, but it’s easier to aim with the option off.
Seems like an ideal situation for an “optional feature” to me, like aim correction in shooters.
Looks like fun already. Can’t wait to play it Shamus.
If you’re looking for suggestions, well, since you started blogging about this game I’ve been feeling strong nostalgia for the old BBC Micro game Thrust.
Perhaps one idea you could toy with is adding a tractor beam along the same lines as that in the game. Things always got interesting when you tethered yourself to the weird orb you had to rescue, as the physics involved started to make maneuvering more difficult. At any rate, some non-direct-combat objectives might break things up a bit.
But….but….survival horror….From someone who actually knows how survival horror can(and should) be improved….Im sad now.
survival horror bullet-hell game… odd combination, I think. And like he said it wasn’t really what he was going for.
That can be a different project. One that can include the old ideas of “no health bars but bullets only have an x% chance to kill” and…
…well there were probably some other ideas too.
I keep thinking it would be cool to have a survival horror game with some of the controls from Receiver. Running requires that you mash the forward key, guns as fully-fleshed out things that must be checked for operational integrity.
You walk into a dark room, there’s a body on the floor with a pistol inches away from its hand. Does the gun work fine and this guy just didn’t react fast/well enough, or is the gun jammed or beyond your ability to repair? And while you’re trying to figure all this out, noises in the dark keep you on edge.
I’ve downloaded the Receiver source, but I’m pretty sure the full project is well beyond me. If I stole this idea from Shamus or anyone else here, I apologize.
The only worthwhile suggestion I have is for an ingame object.
Make a little barrier that when shot, charges. When charged enough, it sends out a (high damage,slow moving?) wave that sweeps a certain direction.
What about Sniper lasers? Stealth?
Man, it’s always hard cutting out interesting features. It’s tempting to think “it would have been better if I had followed the other branch.” In the end though, I’d guess you made the right choice.
But it WOULD be interesting to go back and build another game around the flashlight game-play. It’s not like money and time are an object here right?
Cool to see the projectile icons. I love the “iconic” style, instead of “realistic” missiles and such. Very cool!
Also, I love the background super-huggy-much. I’m not sure how you’re doing it, but it’s almost the same seed as the level geometry so it corresponds well, but not so similar that you can use it to “see ahead” exactly. Brilliant!
>> “When you've got two divergent gameplay modes like this you can:”
There’s a fourth option: make the game mod-friendly and let the players who want them develop alternate gameplay modes.
Or s/mod-friendly/open-source/, which would accomplish mostly the same thing without having to build a bunch of modding tools. It does mean that the people doing “mods” have to know how to code, as well as replace all the other bits, but eh, that can’t be too bad.
Because a mod would have to change more than just the way the stencil-buffer rendering works. It’d also have to change the AI, the music, etc., everything Shamus posted in the original article. At that point it feels to me like a totally different game — one that could benefit from a lot of Shamus’s work if he does release the source for what he’s doing, and would stand on the shoulders of at least one giant, but would nevertheless be quite a bit different.
Making a game “Mod Friendly” is probably a whole other project in and of itself if you haven’t built one before, and would require probably more effort than the game-play aspect of the project. Open-sourcing it is an option, but if he wanted to monetize it then having a whole bunch of people making clones of his game would be…unwise. I’d love to see the code myself afterwards, but I don’t think it’s a good idea for Shamus in the long run.
Regarding the camera, this video may be useful. I know it’s a different genre and not what you had in mind, but there’s nothing you can’t learn from Super Mario World.
Is that the one that’s critiquing the oddities of the camera? If so I’m pretty sure I saw that on one of the earlier posts… Indeed it is.
It’s not really critiquing the camera, more as it is analyzing it. Observing it, more like. The tone isn’t really trying to convince the audience that it works or doesn’t work, but HOW it works.
You know, simulating the flashlight would be easy:
If the stencil is a surface, just make another one with the angle of the flashlight and multiply them.
This flashlight mode has “new game plus” written all over it.
Not that you’re implementing it but wouldn’t the flashlight mode still be as simple as another fan of polys covering everything not in your flashlight in shadow?
Sorry if this has been answered in the comments of any of the previous posts, I don’t really have the time to look through them all:
Any chance of this being released once you feel you’re done with the project? The more updates I see, the more interested I am in playing it, the game looks like a really interesting way to spend some time without requiring hours of commitment.
Does anybody else think Good Robot looks super huggable? I’m seriously tempted to try making a plushie version of him.
I say this: Go with the new optimized vision, and save the flashlight vision for a different version, if you feel like making that its own project.
regarding the light (I know you don’t want feature requests but you posted this thing so now people are having ideas and they want to come ot, so there you go):
With such a cheap way of doing lighting and visibility, wouldn’t it be possible fo other robots to have lights, to have “radar” bullets that will allow you to see around corners, or to have bullets give off light?
You may have a completely different twist for your game in mind, but this seems like a fun mechanic to build a game around. Sometimes you have an empty and dark corridor, little light just your own flashlight (or omnidirectional thing). But you may even decide to turn it off or it might attract …things. But then you’re attacked, you turn the light on, all shots fired give off light as well and suddenly all is light and the action unwinds. A game could have different parts where these different moods are produced by the level design: Few small enemies, or many large ones, opportunities to sneak through or a large shooting gallery, and everything in between. Might make for some changes of mood within the game and thus more “interesting” gameplay, with at least some of those mood changes under the control of the player.
Wouldn’t flashlight mode be trivial to implement by creating a polygon that extends e.g. from +30 degrees from the center of the beam clockwise to -30 degrees from the center of the beam, and adding that to the polygons created by the walls to block vision?
It would be better if you could create both ‘invisible’ and ‘visible’ masks, and only areas within the visible zone and not within an invisible zone would be visible (like security permissions). That way you could have both a flashlight and a lantern, and each could be upgraded separately (The flashlight getting wider and longer, and the lantern getting larger, but remaining smaller than the flashlight.) You could also have other light sources, like some monsters and most projectiles.
Side note: It’s now really important that there are zero gaps between walls, to prevent a ray of light from creeping through a corner.
I would imagine the major issue with Flashlight Mode is a lack of feedback. Unless you have some crazy 3D speaker setup that’s supported by the game, you’d literally have no clue where you’re being shot at, and then next thing you know a flying sawblade has given your robot a new buttcrack.
I wonder what the aesthetic would be like if you had flashlight mode, but it had less effect on gameplay? What I mean is, still have darkness around the flashlight, but continue to render projectiles and robot eyes in the shadows, maybe with a little bloom on them.
Done this way, it wouldn’t make much of a difference in a pure gameplay manner (though I suppose you could find new ways in integrate the flashlight into the gameplay that don’t involve visibility, like slowing down enemies by blinding them or something), but it might look neat–all these faceless horrors shooting stuff at you in the dark until you shine the light on them and shoot back.
Now THAT is a great idea!
Seriously considering this. The world looks much more striking in darkness, but playable in light.
I can imagine a hybrid vision mode, where you can only see in the cone and in a small radius illuminated by projectiles. That way you’d get enemies who can sneak up on you, but you’d be warned about attacks.
However, my tingling game dev senses say “it’s not worth fixing the stencil buffer to add”.
I think an additional game is order, but you could easily start with the base of this one and tweak the art style (scary instead of silly, basically). Limited ammo, maybe…. you know, all that stuff.
But the thing I was thinking that made me come post started with the idea of vision distance vs vision width… and then it led to a larger idea.
Ever play Xwing and/or Tie Fighter? You had a certain amount of energy, and you divided it between blaster recharge, shield recharge, and speed.
If you ever wanted to go survival/horror with a descent-like game like this, you could do something similar: a certain amount of energy charging per minute (or maybe even NO charging, or only charging at certain stations, or the like), and shielding takes energy (perhaps just having the shields up could continually bleed energy, which seems realistic and survival/horror-y), blaster-charging takes energy, and light takes energy – general lighting and flash-lighting both available, with angular width of flashlight adjustable as well (for more energy, of course!). Heck, even movement could require a little, if you wanted.
I think you could use the exact same engine, just with different and different numbers of foes. Art style might need a bit of a change, as well, of course.
> “The result is that the camera has to make huge movements to stay ahead of you. When you reverse direction it suddenly needs to be on the opposite side of you. These swinging camera movements are a roadmap to getting puke on your keyboard. It's that bad.”
When the camera pans out is there a reason you just can’t have the camera “lerp” to its new destination? That would prevent the puking-reverse symptom. The camera should always be interpolating to a position anyways (even if the player stops moving — it gives time for the camera to “de-lag”.)
I notice you have a do it or not approach. But I think you can have your flashlight mode and still get the game you like. You wouldn’t use it for practical purposes, but more of just a nice visual effect to emphasize that the player is in a dark environment. Have the flashlight brighten up the robots where it shines on them, and rather than have robots vanish totally, you could simply have dark shadowy silhouettes of the robots in the unlit areas (no eyes etc), but the player still knows there are there. It would make it more ominous, almost scarey, but you know they are there. Just something to add to the atmosphere.
Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*
You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>
You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?
You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.
You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!
You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>