Project Good Robot 14: Outtakes

By Shamus
on Sep 16, 2013
Filed under:
Good Robot

At the beginning of a project there’s always a big burst of progress. Every ten minutes you’ve got another feature or another improvement, and it’s easy to delude yourself into thinking you’re John Carmack. But then you enter the middle phase of the project and suddenly it’s time to tidy things up, get your interfaces in order, and work on some of the boring, non-sexy stuff.

So that’s where I am right now. Sooner or later I need to do the Great Big Post About Gameplay Mechanics, but I keep putting that one off. Up until now this game has been all things to all people. Everyone can look at these screenshots and fantasize about all the ways it could be exactly what they wish. Everyone can look at it an scream, “Shut up and take my money!” because so far they haven’t seen anything that indicates it’s not something they would like. When I finally get around to nailing things down I’ll end up breaking some hearts, and I’m not quite ready for that trial yet.

So let’s dig through funny screenshots.

I LOVE being the center of attention!

This one was from last week when I was trying to get a sense of just how many objects were in play. How many robots were usually active? How many bullets? How many particles? So I set up a few tests.

What I learned was that I was greatly over-estimating the number of bullets in play. Even in this extreme scenario, we’re looking at less than 200 bullets. At the same time, I’ve been under-estimating the number of particles I was using. This scene has over 4,000 active particles.

It’s not really time to optimize just yet, but having a clear picture of which systems are doing the most work can help guide my decisions about how I ought to design things.

No really, I LOVE being the center of attention.

This one is technically a re-enactment. Way back in the first few days of the project (long before I designed the main character or settled on lumpy cave walls) I was working on making homing missiles. I wanted missiles that could be avoided with quick lateral cuts, or shot down with gunfire. I wanted just the right mix of speed and turning radius. If they moved too fast, then the player wouldn’t have time to react. If they moved too slow, they wouldn’t feel dangerous. If they turned too fast, the player wouldn’t be able to dodge them. If they turned too slow they wouldn’t be enough of a threat.

Rather than having robots shoot missiles at me, I just made my own missiles home in on me. When I shot one, it immediately began turning to come back around. Because they are my own missiles, they can’t actually hit the avatar. They sail right through me. So these poor missiles live a doomed existence, forever pursuing the player but never catching them. They form this great spinning, undulating cloud that changes shape as I move.

So THAT’S how you leg!

As with testing missiles, it’s way easier to test things if they’re attached to my avatar as opposed to being part of some capricious AI. Otherwise you end up doing this:

Hm. Looks like the legs move a little funny when moving left. Or was that my imagination? Get back here you little bastard, I need to see you walk left. Arg. Now it’s holding still to attack. Or is it? Is this a bug in the AI, or is it supposed to be doing that? Should I stop working on these legs and crawl down into the guts of the AI to see what’s what?

It’s just better to have direct control of the thing I’m testing. Once I’m sure the legs work just right, THEN I can attach them to an enemy robot and let it run wild.

This is more fun that it has any right to be.

Halfway through designing the legs I realized they felt really, really cool. (For the record, the legs aren’t actually involved in locomotion. I’m just flying around and the legs automatically span the distance from where I am to the floor.) I wanted to jump, climb walls, and hang from the ceiling. I wanted to drop everything and start making a game built around spider-type activity.

Apparently making one videogame means passing up the chance to make a dozen others.

Hey baby, do those legs go all the way up? They do? I guess that makes sense.

When giving the spider-legs to the robots, I mistakenly gave legs to ALL robots, even ones that fly.

Wow. I know I’m a hack artist, but this was bad even by my own standards.

While writing this post I randomly found this screenshot in my archives. This must be from really early in the project. Don’t know why I took a picture of this, but it’s kind of interesting. I’d totally forgotten about the phase where the avatar had one eye and one really clunky arm.

I’m the map, I’m the map, I’m the map, I’m the map, I’m the map, I’m the map, I’m the map, I’m the map, I’M THE MAP!

My first maze designs were really complex and disorienting. But playtesting revealed that being lost and confused was directly at odds with the fast-paced nature of the game I’m trying to make. It’s a complete killjoy to run down a passge, hit a dead-end, and have to backtrack and try again. It’s also no fun to accidentally loop back to where you were a few minutes ago.

Maps that look a little complicated at a distance are bewildering up close, and maps that are confusing at a distance are unplayable up close. It only takes an occasional split or twist in the passage to make it feel like the space is really big and convoluted. A little complexity goes a long way.

Most of my work has been simplifying and streamlining the passage design to give the player a clear sense of progression. As the game goes on, it adds more blinds and side-tunnels for ambushes, but an attentive player should (ideally) always have a sense of which way to go to reach their goal.

Here is yet another of the many, many directions the game COULD have gone:

It’s like a rave for robots.

It is really hard to stay focused on a single design and not get dragged into all these other possibilities.

Enjoyed this post? Please share!


202020161 comments? This post wasn't even all that interesting.

From the Archives:

  1. Csirke says:

    Hi, talking about games you didn’t make :)

    I worked a bit on your project Frontier code lately, because I wanted to see it working. I started off from Bryan’s branch, and I didn’t change too much yet. But I found and fixed the “purple trees” and the “flickering grass” bugs, added a new fog texture to replace the old one, and running animation is working.

    Code is here on Bitbucket:
    https://bitbucket.org/ecsirke/frontier

    And I put a Windows binary up on dropbox:
    https://www.dropbox.com/sh/oriu82803p65wsl/IxZFz7b3FJ

    For anyone wanting to try this, there’s a readme included as well, when you first start a game, you’ll only get a black screen, read the readme :) It ran on 3 computers I had at home, one of them an Intel integrated card, so I hope it works for others too.

    • Volfram says:

      Thank-you so much for putting a binary up. I have wanted to mess around in Project Frontier for a while and see some of the last features that never got into the videos, but when I try to compile somebody else’s code, it usually ends up in a spiral of failure.

    • MichaelG says:

      Anyone else have ridiculously high mouse sensitivity with this? A tiny movement swings the camera completely around for me.

      • Csirke says:

        I’m not sure if you’re still going to read this, but anyway: I wanted to fix it, then realized it was already solved. The parameter “mouse.sensitivity” changes sensitivity. So you can either enter “mouse.sensitivity = 0.1” or something like that into the console, or once you’ve ran the game, you’ll have a file called “user.set”, and you can also change it in there.

    • Bryan says:

      Hmm, I wondered what the purpose of that fork was. :-)

      The purple-trees bug? I don’t remember ever seeing that one. …Yeah, just fired the program up again, and the trees are definitely not purple — except at sunset, when *everything* is tinged purple.

      Also don’t remember ever seeing flickering grass. Although when I just ran it again, I didn’t see grass at all (just a texture mapped over the large grass-mode grid entry), so maybe that’s why.

      The new fog animation, though, is something I should pull back into my tree.

      Looking at the actual changes you made, the WINDOWS -> _WIN32 one seems reasonable at least. But I don’t know if I can pull back in the change that delegates all the GL extension definitions to the header files; my headers, at least, didn’t have these definitions back when I made this branch, and therefore *probably* still don’t.

      • Bryan says:

        Hmm. I seem to have unpublished local changes in this directory. Related to CGrass.cpp, CForest.cpp, and Scene.cpp (though the latter only appears to be extra debug info). I wonder…

        Looks like the change was trying to run CacheUpdatePage() in more of the ZoneCheck functions. Maybe because my CPU used to be slow (it was pretty fast… in 2006…), and is not anymore (just upgraded it a few months ago)? It’s not clear how that would have any effect on the tree or grass rendering though. Hmm again…

        • Csirke says:

          Yeah there was a problem with CGrass, CForest and inheritance. They didn’t work in the committed version, because “CForest::Set (int x, int y, unsigned int distance)” doesn’t override “GridData::Set (int grid_x, int grid_y, int grid_distance)”, so trees and grass didn’t get rendered. But that was a bug introduced by you and not in the original code, so I didn’t mention it :)

          I tried to make all my changes so that if it compiled successfully on linux before, it still does. I did much around a bit with which GL headers to include in which order in StdAfx.h, so that could cause some problems. I use MinGW on Windows myself, so I have no idea if Visual Studio works, but I see no reason why it shouldn’t.

          • Bryan says:

            …Ngaaaaah, now that you point it out, the problem is obvious: an overload instead of an override. Duh. :-/

            (I’m pretty sure newer g++ versions, or maybe the c++0x standard, have either an extension or a new keyword that you can provide to make it warn you about this case. Unfortunately my compiler is still pretty old, from back when I built the rest of this system.)

            The issue with stdafx.h is that VS tries to precompile it (…sigh), which causes no end of issues. At least in my experience. So I try to stay as far away from ever touching it as possible. :-)

            • Csirke says:

              There’s a solution that’ll work with old gcc, that I already used. You just have to have “virtual void Set (int grid_x, int grid_y, int grid_distance) = 0;” in CGrid.h, to make it a pure virtual function. This way it needs to be overridden. It’s not a perfect solution, but in this case it would’ve helped :)

              • Bryan says:

                Hmm, I did something vaguely similar (for Update()), to try to stop creation of new GridData objects. (Since approximately all the constructors of derived classes were creating instances of GridData and then throwing them away, rather than calling the GridData constructor on the current instance.) I never thought about using a pure virtual function to prevent creation of an object whose class didn’t override that function, only in terms of preventing a specific known class from being created.

                But, fixed, either way. :-)

                I also patched in a few of your changesets — though I didn’t directly pull them via hg, since your changes glommed together a bunch of reformatting along with the logic changes. And while the old code did look bad (I think), it wasn’t a showstopper for me, so I figure I should just leave it alone. :-P

                Anyway, I think I’m caught up to what you just committed yesterday, now. The purple tree stuff was definitely visible once I fixed the overload/override problem, and the framebuffer change fixed that. The map crosshair change was also good, as was the change to make the resolution retrievable via the ini file.

                (By the way, I suspect the issues in the ini file parsing that you were seeing in 6b2cf58 are because your mingw build is using windows’s built-in ini handling functions ({Get,Set}PrivateProfileString), not the non-win32 half-emulator that I hacked together. They have different formats in the file, the most obvious being that the hacked-together version doesn’t add brackets to the section headers when writing the file back out, or strip them off when reading it in. The original ini file was formatted the way the win32 API functions need it; the ini file in my fork had been changed to work with the hacked-together half-emulator I wrote.)

                • Csirke says:

                  That’s a good thing to know about the Ini file :)

                  About calling the GridData constructor: Yeah, the original code was redundant, and could create an unnecessary object. (I think the compiler probably optimized it away, so it didn’t really matter much). But your code is also slightly redundant, because the default constructors are called anyway, so there’s no need to write out “GridData()” there if you’re not passing it any parameters. It doesn’t do anything unnecessary, but the code is unnecessary :)

                  I think next I’ll fix the warnings my compiler throws on building, but after that I plan to make some functional changes too, so I guess you won’t need those if you just want to have Shamus’s final state enjoyable on linux :)

                  • Bryan says:

                    Hmm. The code compiles OK with -Wall on gcc-4.4.1 — but on the other hand, that is pretty old. There have almost assuredly been newer warnings added in the last few years.

                    On the constructor — it may not be strictly necessary, but I don’t tend to trust the compiler’s default constructor, copy constructor, operator=, or other automatic bits of classes. In simple cases like this it tends to work, but if there are e.g. pointers (either raw or smart), it tends to break in strange ways. So I like doing explicit sub-constructor invocation, including of superclasses. (This is related to what I do at work as well.) But hey, whatever.

                    What functional changes? It might still be worthwhile; I guess it depends on what they are. :-)

    • Thanks for fixing this – I haven’t downloaded the code yet, so if you don’t mind me asking – what was the problem? (and what was the solution?)

  2. Volfram says:

    I really like the visuals with the Tron lines. Maybe you could make those appear periodically in the levels?

    I remember messing around in Metal Warrior for the SNES. The Spider is one of the more fun mechs to be in.

    • Ninjariffic says:

      Oh my god! That was one of my favourite games! My brother stopped playing that game with me because I’d always brutalize him with the Spider.

      • Volfram says:

        Nitro was overall my favorite, but all of the mechs had their respective tricks and fun gimmicks. My brother hopped out of his at one point while I was playing Ballistic. I charged up a dash and ran him over while he was trying to remember how to jetpack.

        Getting a Prometheus stuck in lava always sucks, though.

  3. Deoxy says:

    As I’ve pointed out several times before, you can use the same engine to make at least most of these games. Different skins on the same game, with just a few changes in balancing and/or enemy swaps, and you have a game that plays and feels VERY different.

  4. Hal says:

    That last screen cap makes me think of Geometry Wars. Come to think of it, I’ll bet that game would make a good comparison to the one you’re crafting.

  5. Drew says:

    The whole spider discussion reminded me of good old Spiderbot.

    http://www.mobygames.com/game/c64/spiderbot

    Man. I played the heck out of that game. Yes, moving like a spider is awesome.

  6. DGM says:

    Shamus,

    Just a heads-up: there’s another one of those games with Evony-style ads floating around. This one’s called Ancient Summoner. I saw the ad on Instapundit, not here, but unless you block it I’m sure it’s only a matter of time.

  7. Abnaxis says:

    Maybe it’s because I spend a lot of time working with statistics, but it sounds very odd to me to not know how many objects are in play. Even if it’s done by RNG fiat, how can you not know how many robots/bullets/ particles might be in play? It doesn’t seem that hard to get some error bars on those numbers just by plugging some calculations, i.e. “99% of the time there will be fewer than 50 enemies firing fewer than 150 bullets”

  8. Phantos says:

    You share a dilemma with artists and writers: Choosing one path means the death of every other outcome.

    Also, am I the only one who’s made fan art of this yet?

  9. anaphysik says:

    A level system?! Ok, you’ve gotta tell us: what’s the requisite ‘useless’ stat in this obviously-an-RPG?

    • Peter H. Coffin says:

      Probably levels as in “worlds” for the Nintendo generation. That is, the slightly harder version of the game after you reach the arbitrary endpoint.

      • anaphysik says:

        Look more closely at some of the screenshots. At their bottom is a small bar, partially filled-up, with ‘Level [##]: [###]/[###] XP’ (except with actual numbers).

  10. Michael Enzweiler says:

    Great piece, Shamus. Thanks for sharing. One question: as cool as the legs are, if the maker of the bad robots can make them fly, why bother making some with legs at all? I’d hate for you to abandon the spider-bots entirely as they really are cool. What if they served a specialized purpose? If they were smaller, much smaller than the regular robots, it might make sense that they couldn’t have the equipment to hover. Serving a specialized purpose might make the legs make sense. Have you envisioned any bots that act as alarm sentinels? Maybe small spider bots camouflaged as part of the rock that only activate when good robot comes near. It would be really creepy if these small spider bots could leap and tried to jump onto good bot and either explode, or attempt to damage him in some way. Has it been done? Yep. Is it cool. Yep.

    • Blake says:

      On the other hand the spider bots could be big clunky things, slightly mobile weapons platforms rather than speedy nimble adversaries.

      Or you could have some that sit on the roof like bats (in ‘sleep’ mode), and when you come near them their lights come on and they drop down and start attacking.

    • Peter H. Coffin says:

      Rule of Cool, perhaps?

      • Volfram says:

        More realistically, as much more complicated as it is to make something with legs instead of wheels or helicopter blades, legs allow for a much longer deployment lifespan. Breaking free of gravity is horrifically expensive, energy-wise.

        • Deoxy says:

          This. Also, failure modes are much better – no flight equals no fall if the locomotion equipment fails, merely a lack of future movement. Also, cost/benefit of flight in a cave system, when there are plenty of surfaces to move on, is iffy.

    • Syal says:

      The legs are drills. The spiders are weaponized drilling equipment.

    • AdmiralCheez says:

      Alternatively, you could think of the spider walkers as older models that were developed and deployed in an era before the hovering flight systems were created.

  11. Michael Enzweiler says:

    Good Robot kept reminding me of something from when I was a wee nipper. Finally put 2 and 2 together. It was the hovering robots from the horrible 1979 Disney movie, The Black Hole. Check it out! http://31.media.tumblr.com/tumblr_lplckiVwnf1qa23bso1_400.jpg

    • Shamus says:

      Yes, that was a horrible movie. It’s actually awful in really, really interesting ways. I’d love to see SFDebris or someone like that cover it.

      But I saw the same similarity. I don’t know if the movie influenced my design or if I was just reminded of the design after I was done.

      • Septyn says:

        Probably the worst thing about THE BLACK HOLE was the unforseen consequences of Wal-Mart. I bought the DVD for five bucks and was suprised to learn that the Wal-Mart receipt printer only supported 12 characters, including spaces….

      • Deoxy says:

        It’s actually awful in really, really interesting ways.

        It had so much potential! The set up, the backdrop, the interesting sciency stuff… and then, it’s like they said to themselves, “Hey, 2001 is cool, let’s copy that!” and threw on some stupid, plot-wasting non-ending that left everyone completely unsatisfied.

        • Paul Spooner says:

          I thought the hovering telepathic robots represented one-upsmanship Re: R2-D2
          It certainly was… interesting? I watched it when I was in my teens and by the end I just kind of shrugged and walked away. Is there anything useful to be gotten out of that pile, or is it pretty much limited to “How do I hate this? Let me count the ways…”?

  12. Ithilanor says:

    I laughed when I saw those legs going all the way up; at least for all the annoying, hard-to-fix bugs, some are amusing.

  13. Daniel says:

    Shut up and take my money!

    This is going to be the best open world, squad based, 3rd person, based on the novel Push by Sapphire, card game rpg I have ever played!!!!!!!!

    But seriously. I look forward to buying this game. It will be the first PC game I have purchased in a long time (except for GOG.com), assuming it runs on my less than stellar system. What type of system should be able to run it?

  14. Nidokoenig says:

    Going down the wrong passageway and hitting a dead end is annoying, but an option to consider instead of removing wrong passageways is to put helpful items like energy tanks, missile expansions, data pods(free exp) and other goodies, so that even if someone gets lost, they don’t waste their time, like in the original Metroid. This does require a method of discerning which passages the player’s been down, either by marking it on the map, letting them drop flares or markers like in Descent or having markers in the level that light up when you go past. Or just expecting the player to get out the graph paper like the original Metroid. Probably not that one.

    The swarm of return to sender homing missiles makes me think of the orbitars in the original Kid Icarus, two little orbs that orbit around Pit dealing damage to anything in melee range. It was always fun manoeuvring into an enemy’s personal space to deal massive damage or sit next to a spawner.

    The spider legs are so cool. Maybe an additional challenge mode, you have to stay within a certain distance of the walls and deal with the implications. Maybe with a super jump with a short cooldown as a failsafe.

  15. Jarenth says:

    Can I give you my money under the explicit condition that you don’t shut up? Because as fun as any hypothetical future of Good Robot will probably be to play, posts like these are pretty much the principal reason I frequent this website so much. Reading you be enthusiastic about game design is… infectious.

    Wait, I guess that’s actually what the Paypal button is for, huh?

Leave a Reply

Comments are moderated and may not be posted immediately. Required fields are marked *

*
*

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun.

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>