Good Robot #34: Guns, Guns, Guns

By Shamus Posted Wednesday Sep 30, 2015

Filed under: Good Robot 82 comments

Way back in July, I said the plan was to have the game “feature complete” by September. I think we sort of met that goal. We’ve completed all of the features planned so far, but I think everyone expects to add a few new features between now and the planned February 2016 release. We do have a mild case of Feature Creep, which can probably be managed through medication and therapy.

What we’ve done since July:

  1. The interface has solidified. Actually, it’s not so much “solidified” as “been entirely replaced with something else, which has then solidified”.
  2. The gameplay still has a few remaining question marks, but the core rhythm of the game is there.
  3. The art style has taken shape.
  4. The story hasn’t exactly been written yet, but we’ve stopped re-inventing the setting every time we have a meeting. We’ve settled on a single idea that everyone seems comfortable with.

Last week I talked about Good Robot going to EGX. As of this writing, I don’t have the feedback from the public on the game. Although by the time I post this the show will be long over.

When Killing Things Gets Boring…

Do you like being the center of attention? If yes, then you'll love Good Robot because EVERYONE IS ALWAYS TRYING TO KILL YOU.
Do you like being the center of attention? If yes, then you'll love Good Robot because EVERYONE IS ALWAYS TRYING TO KILL YOU.

It was almost two years ago that I said the game lacked interesting-ness. When I joined up with Pyrodactyl, the rest of the team agreed: The game needs “something else”. At least one more gameplay layer: A meta-game. Something to collect. A story to drive the action. A skinner-box mechanic. A mystery. Some humor. Something.

The robots kind of all felt the same. Some of them shot faster, some moved faster, and some were larger or smaller or had more hitpoints, but these variations were only enough to keep the player amused for about half an hour. Beyond that it just felt repetitive.

We were planning on adding some humorous story beats. That would help, but it probably wasn’t something to bank on. Yes, Borderlands gets away with this exact thing, but I think that game is the exception rather than the rule, and I wouldn’t want to bet on us being able to bolster lackluster gameplay with gag voiceovers. That sort of hope is the kind of thing that creates situations like The Writer Will Do Something. “Bah. We can make a shit game and then the writer will add a story to make it good. And if people don’t like the game, we can blame the writer.”

After a while we arrived at the idea that the current enemies didn’t have enough variety in their attacks. The weapons system had evolved over time in an ad-hoc way. There were a couple of different, independent weapons systems (lasers and missiles) that each had their own limitations and quirks and which had totally different interfaces. There were lots of options for the designer to worry about, but not a lot of interesting choices to make.


Those machines stuck to the walls? We'll talk about those in a later entry.
Those machines stuck to the walls? We'll talk about those in a later entry.

So I tore out the various enemy weapons systems and replaced them with with a new unified system of projectiles. The designer could control number of projectiles, the rate at which they fired, their color, appearance, sound, how much they scattered, and numerous other things. You could make anything from a shotgun to a railgun to a missile launcher.

For the purposes of testing, I changed it so that the player could fire these new weapons, simply because it’s easier to launch the game and push the fire button than it is to launch the game and then fly around for thirty seconds looking for a robot carrying the weapon you’re trying to test.

What we discovered in the process of testing was that this made the game a lot more interesting. These weapons were supposed to be for enemy robots, but the real fun was when we put them in the hands of the player.

This also fits in nicely with something I really enjoy, which is making open-ended systems where other creative people can discover possibilities I’d never considered. You give them lots of options with potentially emergent outcomes, and see what happens. If you’re curious, here is what a weapon definition looks like in the game files:

#First is the name of the projectile, in brackets. This is the name used to assign the weapon to a robot in robots.ini.
#This is the name of the weapon shown to the player.
Title=Plasma Repeater
#This is the description for the shopping interface.
Description=Start a conga line of bouncing chaos.
#Type can be bolt or beam.
#Slot is either primary, secondary, or "robot". (Robot weapons won't be available for the player. Default is robot.)
#Size is the width and length. (Beams only use width.)
Size=0.6 0.6
#The color of the projectile. Also the color of any residual particles and explosions. (Three-digit RGB hex.)
#The name of the sprite from sprite.ini
#The name of the sprite that will be used as a pickup icon.
#The name of the sprite that will be the player's hand when this is equipped.
#How the hand will move. Values are: Fixed, Aim, Spin.
#If true, the sprite will glow, like lasers. False means opaque, like a robot.
#If true, the weapon can hurt the user with splash / reflections.
#The brightness of the comet-tail effect. 1=full. 0=disabled. 
#If true, the projectile will chase the target. (Doesn't work for beams.)
#If true, this projectile can be shot down by others. (Good for missiles.)
#The size of the glowing aura around the projectile. 0=no aura.
#The color of the glowing aura.
#Movement speed, in units per frame.
#How long it takes for the projectile to reach full speed. Zero will disable acceleration.
#The starting speed. ONLY used if AccelerationTime is not zero.
#How much the player is pushed back when firing. (Also pushes robots, but only cosmetically.). 0.0 = none. 1.0f = very strong.
#How much the trajectory is changed by gravity. Warning: Robots can't correct for this.
#Makes the projectile spin as it flies. Degrees per frame, so 1.0 = 60 degrees per second. 
#If this projectile is a homing projectile, this controls how fast it will turn. Degrees per second.
#If this is greater than zero, then it will explode on impact with this damage radius.
#This controls the accuracy of the shots. 0.0 = precise. 1.0 = totally random. 
#This is how fast the weapon can fire. Higher=slower. 
#The sound effect when fired.
#How much damage is inflicted on impact.
#How long the projectile will live. No effect on beams.
#How long it takes for the glowing to fade after the projectile expires. (Important for beams.)
#How often (milliseconds) to emit sparks. CAREFUL! Low values can create insane numbers of FPS-killing particles. 0 to disable. 
#How long (milliseconds) between pressing the button and the weapon firing. (Applies only to player.)
#How many projectiles do we get out of a single shot?
#If true, the weapon must be re-triggered and warmup before firing again. (Applies only to player.)
#How long in milliseconds does it take the weapon to become ready to fire again?  (Applies only to player.)
#When the projectile hits something, it can bounce off and keep going. This is how many bounces are allowed.
#How many little bits of rock particles you get when this projectile hits the wall.
#The cost to buy this weapon in the store

This is often how I document features for the artists. I make an example and cover it in comments. I don’t know how AAA studios handle documenting systems between teams or individuals. It seems like making a document or a wiki would be more organized or professional, but this seems like it would be more convenient to use. Also, it makes the documentation available to the players if they decide to go poking around in the data files and trying to mod things.

But nothing fuels feature creep like adding new features. Once we had new guns, we came up with the idea of giving the player the option to change weapons, which led to having robots drop weapons, which led to adding stores where the player could buy weapons.

“It’s Like 2D Borderlands”

Also, it turns out the game runs like ass on integrated graphics, even though we're drawing less than 20k polygons a frame. I'm really NOT looking forward to figuring THAT out.
Also, it turns out the game runs like ass on integrated graphics, even though we're drawing less than 20k polygons a frame. I'm really NOT looking forward to figuring THAT out.

This is all well and good, but the focus of the game has been dragged away from “dog-fighting and dodging incoming projectiles” to “acquire better guns”. Arvind is seriously considering adding a system to generate random guns, Borderlands-style. For the last several weeks it’s been like there’s this pervasive gravitational pull towards more Borderlands-ish ideas: The story, the foes, the weapons, the humor. Every time there’s a problem it seems like, “We could try doing things the way Borderlands does it” is the answer.

This is good, inasmuch as it’s more entertaining, but we need to be careful about making extreme changes this late in development and introducing massive new systems that will take months to tune and balance properly.

I have this writing gig, and I’d already given up hope of Good Robot seeing the light of day, so if it turns out to make money at some point that’s a bonus. But other members of the team have the more sensible position that we shouldn’t just keep hammering away at a videogame for free, forever, constantly changing the foundational mechanics, and never nailing anything down long enough to ship a game and get paid.

A lot of indie devs say things like, “If I was a millionaire, I’d make the ultimate version of [game that they love]!” But if this experience has taught me anything it’s that if we didn’t have to worry about money, we’d never ship a game at all. There’s just too many possibilities to explore.


From The Archives:

82 thoughts on “Good Robot #34: Guns, Guns, Guns

  1. Zoe M. says:

    I could see room for the game to get kinda bullet-hell-ish. Enough enemies firing enough projectiles == 2D exploration bullet hell, which ain’t something that’s been done all that often, I don’t think.

    1. guy says:

      I feel like that would wind up being a bullet hell game interspersed with being hopelessly lost. And a procedural bullet hell game with terrain would have very good odds of outputting impenetrable fire patterns.

  2. Gunther says:

    “We were planning on adding some humorous story beats. That would help, but it probably wasn't something to bank on. Yes, Borderlands gets away with this exact thing, but I think that game is the exception rather than the rule, and I wouldn't want to bet on us being able to bolster lackluster gameplay with gag voiceovers.”

    …Why not?

    You don’t want to JUST rely on that, but it’s a great way to make an otherwise-generic game stand out. Look at Bastion. Or Thomas Was Alone. Neither of those would be a tenth as interesting if they didn’t have an interesting narrative combined with narration. In the case of TWA, it elevated what would otherwise be a dull, generic puzzle platformer into a successful indie darling.

    You’ve written fiction before, you already know the game back-to-front, go write some apropos narration. And according to Twitter, voice over artists are paid in fun-size snickers bars, so dig around your couch for loose change and hire one before they go on strike.

    1. Shamus says:

      “You don't want to JUST rely on that”

      Yeah. That’s the point was was going for. Gag dialog is good and we should have it, but we shouldn’t assume it can save a dull game.

      1. Alexander The 1st says:

        There’s also the side effect of translating a game to areas where English isn’t the most common language, which is harder when it comes to more dialogue in general, but gets harder when you’re trying to get gag dialogue to still be funny.

        The most prominent example I can think of a joke falling through because of translation is Rock and Roll not being an obvious joke when someone translated Rock to be Megaman for the Megaman series. Or when Blues became Protoman. Which makes the Roll and Bass names stand out, because they’re based on a gag naming theme that didn’t make it past localization.

        1. 4th Dimension says:

          Essentially puns and wordplay are generally untranslatable into other language groups. You might be able to get away with translating in same language group since the base words are probably similar.

  3. The Rocketeer says:

    For a second there, just for a second, it sounded like Good Robot was converging on Einhänder. That was a bizarre sensation that I don’t totally know how to process, so I’m just going to lie down.

  4. Chris says:

    But if this experience has taught me anything it's that if we didn't have to worry about money, we'd never ship a game at all.

    See also: 3D Realms

    1. MadTinkerer says:

      On the one hand you don’t want a x^10c (or whatever Notch was working on was called) Half Life 3 / Last Guardian situation where the game is never good enough to launch.

      On the other hand, you don’t want to Tony Hawk 5 / Assassin’s Creed Unity it either.

      It seems like there’s a fine line between “We can take our time to make it right” and “We’re shipping on Thursday, so as long as the publisher’s logo works, it’s a release candidate”.

      1. Chris says:

        Fully and completely agreed. Knowing when a project is done is a remarkably difficult task that many people in all fields get wrong.

        1. Bropocalypse says:

          “It works and it’s fun, and the amount of fun justifies the price tag that covers our costs given projected sales” seems like a good rule of thumb to me. Though sometimes the first half of that sentence is forgotten.

  5. Dragmire says:

    You comment with the # symbol?

    What language are you writing this in? For some reason I thought you were building it out of C++.

    1. Cybron says:

      That’s a config file (or some other sort of external file), I think. No relation to what language the actual source code is written in.

    2. silver Harloe says:

      That file wasn’t C++, it was a config file – apparently it is based on the .ini file format ( ), but with # for comments instead of ;
      It is most likely answer is that Shamus didn’t even write the config file loader and just got a free one and thus used whatever comment symbol it used (just a guess, though).

      1. Shamus says:

        The long version:

        Yes, it’s an INI file. Internally, we’re moving away from INI files towards XML. (Arvind already had a bunch of XML-parsing code when he joined the project.) Simple data goes in INI files, while complex nested stuff is XML.

        I use Notepad++ to edit the INI files, and its highlighter is (for whatever reason) set to treat # like comments, so I used that. I have no idea what the “proper” ini spec (if there is such a thing) proscribes.

        1. Knul says:

          Have you considered YAML or JSON? XML is just so unreadable and clunky.

          1. Mephane says:

            Heh, yeah. While XML is vastly more powerful as a tool, it is also vastly more unwieldy, while an INI is very straightforward to read and write (both manually and programmatically).

            1. Felblood says:

              Since they already have parser code for both of these, is there any worthwhile reason to bring in a middleground solution?

              I’ve only worked with these two, so I’m curious if I’m missing out on something cool.

          2. Alexander The 1st says:

            As someone who spends a lot of time working with HTML and XML (And even XHTML), JSON always feels more clunky to me.

            Though I’m also kind of biased – Java is a lot easier to get to work with XML than it is with JSON in my experience.

            Though leaving personal preference aside, it sounds like the reason they’re using a mixture of INI/XML is because both groups have tools written for both, so as much as they want to merge into any particular one, it takes a while to decouple old code for one to the other. But the benefit of sticking with any one particular format is that you bug-test your own code to that format much more consistently, instead of having to figure out how to spot parsing errors with every new format.

            1. Retesam says:

              JSON > XML, imo. There’s the obvious gain of less redundancy, but more than that, I like that JSON generally has one obvious correct way of doing something, while XML is murky: Is

                  <bar />
                  <baz />

              equivalent to

                  <bar />
                  <baz />

              ? I can’t tell by the structure. Also, it’s not always obvious where to use an attribute vs. when to add child elements. XML just has this odd mixture of structure and data that I don’t like.

              (Also, embedding XML in this comment was a major pain; so JSON has that going for it.)

              1. AileTheAlien says:

                Down with JSON, up with YAML! :P

                Also, I have no idea what your two examples are supposed to show – they both look identical to me…

                1. Retsam says:

                  Dangit. The second was supposed to be

                      <baz />
                      <bar />

                  i.e. switching bar and baz. In some cases, children of an element are order-sensitive, in other cases they’re not.

                  JSON vs. YAML… I don’t have much experience with YAML to say… but the fact that JSON can be dropped right into a browser console and manipulated is a huge win for me.

          3. Bryan says:

            …Because swapping out the file format at this point (when there’s already something that works) will definitely never add to the feature creep…

            Especially when Shamus has had an INI style format parser ever since he’s been releasing code on this blog… :-)

            Oh well, I guess.

        2. AileTheAlien says:

          For your next project, I’d suggest using something that combines the light-weight-ness of an INI, with the nesting power of XML. YAML. It’s super easy to read, write, and there’s parsers for free.

          I’m pretty sure my bias towards YAML comes from my difficulty in reading long blobs of text. I describe myself to my friends as “partially dislexic?”, but it’s all based on my observations, of what I need to do to make reading easy. Use stuff like Python and YAML that have lots of whitespace, use increased space between lines in my e-book reader, and other stuff like using a good font or two.

        3. Mephane says:

          Since INI parsing often is done by the code looking for specific things, e.g. a section header in rectangular brackets [] or variable followed by an equals sign, it is not uncommon that you can write comments in an INI in any style you wish, as long as it does not match what the parser is looking for, it will simply be ignored.

        4. The closest thing there is to a .ini file standard

        5. evileeyore says:

          I do the same thing coding in XML.

          Being self taught… I also do not know what the “proper” documenting looks like.

        6. Kian says:

          Is anyone in the team familiar with database design? Because that ini file looks like a table record for a relational database, complete with foreign keys for records in other tables.

          Say you had a “Projectiles” table, the ini file would be a row in that table. The [GenericGun] name is the key, each attribute is a column. Sprite, Icon and Hand would be foreign keys, identifying a row in the Sprites, Icons and Sprites (again) tables, etc.

          Not saying or suggesting that you should add a database engine, that would be overkill for what’s mostly static data. But thinking of it that way might be helpful for managing the information. Especially if you do try to make more dynamic systems and need to apply constraints, or performs searches and the like. There’s a lot of thought gone into that area of study.

        7. wheals says:

          People’ve mentioned YAML/JSON as a compromise between readability and expressibility, but personally I’m fond of TOML. It has the advantage of an INI file basically being valid TOML (assuming the file doesn’t mess around with braces), but it has support for booleans, arrays, and nesting basically everything. There are also a couple of MIT-licensed parsers linked there.

          The main issue is that, unlike in INI, strings have to be enclosed in quotation marks, so you can’t quite just switch out the parser and modify the code.

  6. KingJosh says:

    I’m sure it WILL be difficult/unfun to sort out the problems with integrated graphics. But, on behalf of $300 laptop owners everywhere, I really appreciate that you’re going to try. (Side note: The WORST PART of shopping for a low priced laptop is researching the graphics options. I already know I’m not gonna be playing the latest AAA titles, or maxing out the BlingGraphics(tm) setting. But, most of the advise is “triple your budget, if you want to play games.” Yeah, that’s not particularly helpful. Can’t you just give me some idea what older, or indie, games WILL run acceptably on that hardware? Please?!)

    1. Felblood says:

      Buying integrated graphics chips is as much art as science. Reviews are especially useless, because most of them will have been written when the chips were new, and you will be most interested in how well the shader model support has aged.

      Here are my rules of thumb:

      1. Start with Shaders, and figure out which ones actually matter to you personally. Odds are, you don’t need support for the latest DirectX but maybe there is just one game you play that needs it.

      Make a short list of games you might want to run. Currently, I use Civ:Beyond Earth, Darkest Dungeon and Warframe. Look up their shader model requirements, and then check each chipset you are considering for those. Not only will many games be unlaunchable or simply buggy without shader support on your chipset, but running software shaders will devour your CPU cycles and demolish your framerates.

      2. Find out how much virtual graphics memory your chipset will support. A lot of old onboard cards max out at using 216MB of your system memory as graphics memory. In an age where many 3D games will have a 256MB texture pack as the “Low” setting, that can be a deal breaker.

      3. Subtract your maximum emulated graphics memory from your total memory. If the difference isn’t enough that you would be comfortable owning a desktop with only that amount of memory, consider more total RAM.

      4. CPU is the tricky part. Your cheap chipset will probably need a lot of brute force to shore up it’s weak points.

      Guessing how much Ghz of processor you will need to manage your game, it’s rendering and whatever software shaders you need is basically impossible, but when in doubt, remember that more cores is more better.

      A slightly slower quad core machine might give you a lower frame rate than a dual core CPU, but it will be less vulnerable to sudden framerate drops, which can be pretty painful when you’re already struggling to hit 15FPS. If the rate is consistent the brain can compensate surprisingly well, but if it’s okay-ish but suddenly drops by half, it can really throw you.

      Good luck, and remember to enjoy tinkering with your graphics settings. The destination will probably be mildly disappointing, so relish the journey.

  7. RubberBandMan says:

    That post didn’t end up where I thought it would go. The set up seem to lead towards ‘and now you can steal enemy weapons by getting close enough to them and using the new capture thing’.

    It’s something that would let players go ‘ooohhh, shiny!’ everyone now and then to taunt them, and add a skill above and beyond surviving. Enemies with good weapons are clearly going to be harder to get close enough to, making it self balancing. You may also need to actually shoot down enemy missiles or tank shots to leave the enemy alive long enough to jack it.

    It would make it a lot like space invaders actually, where you let your ship get captured and rescued it for a double shot ability.

    1. Primogenitor says:

      Or similarly there have been games where you take over the entire target robot – guns, engines and all.

  8. Cybron says:

    If you didn’t have to worry about money, I imagine your dev process would look a lot like Dwarf Fortress. A never ending public beta with a feature list the length of war and peace, wherein progress is constantly being made but the end is nowhere in sight.

    1. Shamus says:

      In a strange way, I think I would actually really dig that. I mean, that’s kind of how this blog works. It’s always getting new content, but it’s never done.

      1. Felblood says:

        Isn’t that the goal with these Patreon type things? Bay 12 Games just seems to have been ahead of the curve for all these years.

        Even if you finish one game, isn’t it just one of the many features on the list that your fans are supporting you for? Some creators keep adding to a central project like a webcomic or a single massive game, while others produce several small games or an ongoing series of unrelated animations, but they all have an ongoing relationship with their fans and patrons.

        1. Shamus says:

          My dream project:

          A Minecraft-like game with the core game / rendering engine written in super-tight C++, and all the gameplay logic farmed out to some easy, fully sandboxed language. (Something easy to pick up, like Python? Except you can’t sandbox Python, I don’t think.) Ideally the mod-making would be approachable for teens as a kind of “my first programming project”. Mods would be distributed as source, and perhaps compiled when installed / activated, thus forcing all mods to be effectively open source and encouraging a community of sharing and collaboration.

          Something like this could easily become a “Dwarf Fortress” level project. It’s a pipe dream, of course. I don’t have any idea how to do something like the language integration in a sensible way.

          1. Felblood says:

            So the dream is not so much to produce content as to create a superior portal, wherein content can be created, shared and curated?

            Quippier version:

            So you want to develop a voxel block based alternative to Quake, RPG Maker and Unity?

            Actually I can really see that. There is an entire generation of aspiring game designers whose visual language is written not in square sprites or high-poly models, but in cubes.

            I used to be into total conversion mod maps for Warcraft 3, and I’d love to see that kind of community come back with more approachable tools. Minecraft superficially resembled what I’ve been looking for, but it quickly became clear that it would’ve need to have been built from the ground up to accommodate modding, and many mods just couldn’t keep patching to stay compatible as 1.0 drew near. Plus, the cube thing is actually really restrictive for me. I was always the kid using the hinges and stuff to arrange Legos at angles.

            Ultimately, I don’t think the financial or opportunity cost would be the biggest sacrifice for you. A community large enough to support a project like that is simply going to be too large to moderate the way you like, and you’d need to bring in extra manpower in the form of additional moderators. Once that happens, is it really still your dream job?

            More readers and patrons is more money, but at what point does the cost of not being able to give that personal touch (and the actual financial cost of full-time community managers) undercut the gains.

            That tipping point is going to come at a different place for every creator on Patreon, but something like that would just be too big for most people, I think. Being the figurehead of something that big means a lot of weird kinds of media attention. Just look at what happened to Notch, when suddenly he was the head of the biggest thing in media.

            You’d have to delegate somehow, but you could mitigate the damage by building a recommended business model that is more tolerable for you. Your interactions would mainly be with the mod creators and fans of your writing. The creators of different projects would probably need to have their own Patreons to keep the individual mods alive, and manage the fans of their own, specific type of content individually. This would be really good when one of those projects raises the complexity of it’s needs and the skill of it’s programmers to the point that they decide to build a custom engine for their game after all.

            It’s a really tricky hypothetical with a lot of variables, but it’s not like there aren’t similar enough precedents that you could plan for the worst case scenarios.

            1. Bropocalypse says:

              If he hosted it as an entity wholly separate from this site and minimized the connections after initial announcement, moderation wouldn’t really be a concern at all. Let the fans talk amongst themselves, as it were.

              1. Felblood says:

                Once it got off the ground and developed enough momentum for a stable orbit, that would be a good idea.

                He could slowly spin it off into it’s own website, and then have this blog as a bastion to retreat to if things went awry or he simply decided he was ready to move back to smaller projects.

                If he wanted to, he could even release control of the project, and let it live on outside of his sphere of influence. He could incorporate it as Benefit Corporation and establish trustees for the Patreon money, to ensure his lofty ideals are upheld, and then sell it off as stocks.

                I guess the idea of being tied to a single creative project for the rest of your life would be really scary to me, and I have a hard time seeing past that. So if it was me, I’d want to make sure I had a suite of exit strategies. Maybe this just isn’t an issue for other people. Forever is a really long time, but if I knew I could support my family and I could quit whenever I wanted, I have a couple of dream projects I wouldn’t actually mind working on until the end of my days.

          2. Zak McKracken says:

            OMG! WANT!

            *thinks for a second*

            … also want some time to then go and actually do something with it …

          3. Lua is fairly easy to sandbox, and also quite easy to read and write. It’s what a lot of games use as their scripting interface.

          4. Ingvar says:

            Werrrrllll, it should be eminently possible writing something that parses Pythion syntax into an AST, wrap a CPS transformation around that and use that in a way that gives you soft realtime guarantees for “return from sandbox language to game engine” (by implicitly have a “return to game engine at every continuation passes”). Or something that does essentially that to the bytecode, I guess.

            The main problem with any sandboxed language is when what’s running in the sandbox can go into an uninterruptable loop, taht makes everything just stop.

            1. Zak McKracken says:

              I suppose you could make (parts of) your actual game code into python libraries, so there’d need to be a basic set of Python routines that runs the actual game, and then those could be modified or added to by modders. But then it’d become fairly easy to just break the game. That won’t bother people who are a little more familiar with it all (and actually give them way more possibilities) but might scare others away because it’d be too easy to break things, rather than programming errors just leading to silly things happening in-game.

              Then again, wouldn’t it be possible to make only some parts of the game logic this way? That would mean you’d have C++ code calling Python calling C++ code, though in the base game that Python layer would be relatively thin…

              Also, I’m totally in favour of Python, no matter for what :)

          5. evileeyore says:

            If I had it I would pay you all the moneys to see this happen.

          6. Gorthol says:

            How do you define “fully sandboxed”? Civ 4 used python as its language for modders:
            So it might be possible to offer python as the modding language.

          7. Tsi says:

            Shamus, this is a brilliant idea.

            Whatever the scripting language used, the interface could be similar to scratch so that you don’t loose people in language specific quirks. Actually, this is pretty good for people new to programming :

            Anyone familiar with both Minecraft and scratch would get into the game in an instant.

            Imagine having a view of the game world in the preview window and when you click an item, you get it’s item ID and the possibility to edit it’s properties or add a script (if consumed, if used, if thrown, … ).

            New item ? Drop a picture into the game’s data folder or use an editor then provide some basic information so the engine knows how to categorise it for later search.

            Want to add a new block type ? Click a block in the editor and change it’s ID to “new” and either provide a unique ID or let the game choose one. Then define block properties including texture and various engine characteristics (permeability, spawn height, recipe …) and assign a script if you want (on world gen do .. , on spawn do … , on break do …)

            Want a new 3D modeled thing (block, npc, item) ? Copy an existing item and change it or import a 3D model and fill in a form and define it’s recipe if any. Then label any animations it may have and assign one or many scripts depending on the complexity you want.


            Already hyped just by thinking about it : )

          8. Decius says:

            What kind of income stream would be required to do that, and what do you think you could produce to justify the decision of others to create that stream?

  9. Ingvar M says:

    A lot of indie devs say things like, “If I was a millionaire, I'd make the ultimate version of [game that they love]!” But if this experience has taught me anything it's that if we didn't have to worry about money, we'd never ship a game at all. There's just too many possibilities to explore.

    The more you dig into SolutionSpace, the bigger SolutionSpace becomes. This holds true for “ultimate version of ${THING}” as well as “what’s wrong here” (although in the latter case, at least sometimes you can start pruning your search trees and shrink SolutionSpace somewhat).

  10. Thomas says:

    “#Movement speed, in units per frame.”

    Are some things tied to frame rate?

    1. Shamus says:

      All things are bound to frame rate. If the frame rate drops to 30fps, the in-game clock will run at half speed. This is deliberate. It’s one of the shortcuts I chose early in the project to manage complexity.

      I actually wrote about it way back in entry #4:

      (Which is one of my favorites in the series.)

      1. Thomas says:

        Cheers, it was fun to read through that :)

    2. Bropocalypse says:

      As far as I know, ultimately game logic all comes back around to framerate one way or another. It’d be crazy inefficient to ask the GPU to draw things as they happen, so you measure the rate at which things are being rendered and perform speed and other such calculations based on that to get renderings that are based on real time rather than the rate that the GPU runs.

      1. guy says:

        As I understand it, that’s not precisely why. If the rate at which you send things to the GPU isn’t synchronized to the GPU, the GPU will do… something that makes sense. Most likely it will just get the data that was the most recent when it finished the last frame. And you really, really don’t want to have the CPU actively wait on the GPU; the CPU will spend an unacceptable amount of time idle waiting on the GPU and then take a long time to be ready to send the next frame.

        The reason for the CPU to do things by frames is consistency and timing(badly). Each frame, the game calculates what every single thing did in the interval since the last frame. Since the game takes a non-zero amount of time to do calculations, if it did each update by the time since that particular thing last updated, everything would still move in discrete jumps, but they wouldn’t be synchronized, and doubtless there would be various esoteric errors involving spawning new objects.

        Good Robot is also using its framerate as its unit of time, so instead of getting something to move at 1m/s by having each frame call the system clock to find the elapsed time in seconds since the last one and multiplying it by 1, it gives it a speed of 1/60th of a meter per frame and each frame moves it 1/60th of a meter regardless of how much time has actually passed. This is generally not preferred because high CPU load will make everything take more real time, but it’s so much easier to code.

        1. Bropocalypse says:

          Yeah, that’s what I was trying to express.

  11. McGurker says:

    The variety of weapons reminds me of Ratchet and Clank. They tried a lot of different weapon mechanics throughout the hey-day of that series, focusing on weapon upgrades. The player stays the same, and the weapons get stronger and ‘level up’ the more you use them, with a visible experience bar etc.

    The system that excited me the most involved the first X many tiers only providing increased damage/blast radius/whatever stat, but the final tier changed the weapon aesthetically and effectively, gave it a new name, the whole she-bang.

    It feels like your weapon system could accommodate upgrades like that pretty well, just a thought.

  12. ryan says:

    I’ve had a lot of fun over the years by tweaking games with text config files, such as Red Alert and it’s relatives, etc. And I recall you’ve spoken highly of such easily moddable games like that before. And you’ve shown similar config files for Good Robot before.

    So, is it safe to assume that the config files, such as the one in this post, will be user accessible, so we can play around with the weapons settings?

    I’m looking forward to when the game ships, so I can pick up a copy. I’ve wanted to play it since the first post when you talked about the initial concepts.

    1. swenson says:

      This is actually one of the things that got me initially interested in programming (which I now do for a living)–I always was poking around in random files to see what they were and what they did, and I discovered that a ton of data for the game FATE (a very repetitive Diablo clone, but fun) were stored in easily-editable text files.

      I didn’t know the first thing about animation/modeling, so I couldn’t make any appearance changes, but I played around with all kinds of random monsters, spells, screwing with the randomly-generated names… it was fun, just trying different things to see how it worked.

      1. ryan says:

        Oh, I’ve never poked around in Fate’s files. I should take a look at that sometime.

  13. kaljtgg says:

    Just from looking at the screenshots, this looks like it’d be an incredible twin stick shooter, any hints on controller support?

    1. Shamus says:

      Controller support is yes. Only tested with Xbox controller so far. I have no idea how we’ll handle controller prompts. We could do the platform-agnostic thing and refer to the face buttons as 1, 2, 3, 4, etc, or we could do the convenient (for the user) thing and used “Blue X, Green A, Yellow Y, Red B”.

      1. Zak McKracken says:

        I suppose that on PC it’ll be WASD for moving and mouse for aiming?

        can you invert the mouse? ;o)

  14. DGM says:

    >> “And if people don't like the game, we can blame the writer.”

    Blaming Rutskarn should always be an option. I, for one, am still waiting for him to answer for the sacking of Rome.

    1. evileeyore says:

      Why he nuked the Sasquatch village of Tunguska is beyond me. They were peaceful!

  15. It’s always the limitations that drive creativity. If you feel “I can do anything!” what you’ll really do is nothing.

    1. wswordsmen says:

      I feel the same way. If you give someone effectively infinite money to do something, they will make a really polished version of something that already exists (assuming they ever finish), while if you gave someone very limited resources they would come up with cool ways of doing things that you wouldn’t see elsewhere.

    2. Felblood says:

      Being able to know and set your own limitations is one of those skills that we just don’t get enough opportunities to develop, in modern society. When people do finally get that chance to do anything, they often blow it, either through recklessness or indecision.

      Look at all these schmucks who win a six figure jackpot in the lottery, and six weeks later they are destitute. Increasingly, we learn that survival mean spending your income as it comes in, and few people actually know how to manage their resources when they have a surplus.

      A savvy spender would immediately set aside a couple of girthy, tax-exempted retirement funds, for their old age, and invest the remainder into getting the tools and education they need to be self-employed at their dream job.

      Me, I’d budget a generous portion to buy some land and build a real house for my family, and set aside some savings and investments for maintenance and survival, and then I’d take the rest and try to launch my own indie games studio.

      Yeah, even on a modest budget, a couple of duds would mean shuttering the place, but at least I’d have food money for my ensuing job search, managerial experience, a portfolio of published games, and a healthy retirement.

      Plus, I know a couple of indie devs who totally deserve to quit their day jobs and get a real start, so if I could boost one of those guys along their career paths, that would feel like a job well done, even if my actual company failed.

  16. Mephane says:

    I both like the idea of weapon customization and random weapon drops. However, what I would like the most is to have weapon statistics and style (sound, visuals) somewhat separated. I.e. so that you can modify your gun to do more damage per shot or fire faster etc. – and independently of that, you can simply modify it to shoot bolts in a different colour or make a different sound. Sort of like you can choose your lightsaber colour in the various Jedi Knight games purely as a matter of taste, with no bearing on gameplay. :)

  17. After reading the functions of the variables in the code snippet, I would have to wonder what the point of the gravity effect option is, if the enemy AI cannot calculate for it. Surely that would just lead to all the enemy’s with that weapon missing constantly wouldn’t it?

    I am probably not thinking this through alll the way, but wouldn’t it be possible to take the point that the enemy was aiming at, and then take the parabola based on the speed and trojectory of the projectile (which you should know, as we have the gravity and firing direction) and then calculate a trajectory of a third point (possible above the player) to actually aim at?

    1. silver Harloe says:

      The point is probably to give the player gravity-affected weapons?
      That’s what the warning is probably implying: “look, if you use this option, make sure it’s a player-only weapon, because the enemy AI won’t use it well”

      It might also have interesting effects when combined with homing weapons (for which the enemy AI doesn’t really need to take gravity into account and probably already picks from a smaller pool of launch directions than they would use for direct fire weapons) – or it might not. Experimentation is needed. Oh, look! There’s a handy number you can change to experiment.

      The funny thing about gravity is also this: you can simulate it entirely with fast math (a bit of vector addition, and perhaps a divide by 2), because each frame can be treated separately from every other frame. But to *predict* it several frames from now, you have to use parabolas, which are going to be much slower (square roots, aieeeee), and you have to finish doing this slower calculation during the fraction of a frame allocated to the AI picking a fire direction. This is related to (but not identical to) the reason Newton had to invent calculus but nature didn’t.

    2. guy says:

      You could predict the shot paths, but then the aiming code is more complex and slower.

      1. that was probably what I thought. I knew the math in my head, but I didn’t really know how long it takes for the computer to do the calculations.

  18. Felblood says:

    Do all Twine games play as slow as TWWDS or is the slow pacing a stylistic effect to underscore it’s themes of frustration and futility? I’m interested in playing around with it, but I don’t want to waste the time, if this is a central limitation of it’s engine.

    This honestly feels worse, ergonomically, than playing old TADS engine text adventures (Play Spider and Web It is a real classic that most people missed.)

    I especially hate how you have to click in different places to advance each slide. It makes repeated playthroughs to see the other content much less tolerable.

    I was really disappointed that the only decision that matters is the last one, and it has no impact on any of the characters you just spent the last 20 minutes getting to know. I get that these are stereotyped caricatures, but some kind of nod that one of your actions might have at least brought down one of your rivals with you might have been nice.

    1. guy says:

      In a sense, it’s appropriate that you can’t accomplish much; that was set the moment the intro informed you that you were at a meeting to salvage a game that was going to be released in six months.

  19. Shamus you mentioned using Notepad++ I’d like to note (pun intended) that I used to as well but are now using Atom (free and opensource).

    BTW! Don’t worry about Good Robot and feature creep. A lot of the ideas you guys have can probably be used in Good Robot 2 (where you can try different ideas/experiment with the formula vs Good Robot 1)

    1. Zak McKracken says:

      Atom looks nice but I’m a little concerned that it appears to work on magic, i.e. from the demonstration videos I’m not quite sure how the UI would tell me how to get something done. Feature search functions are only good if you know what to search for.

      I just found that it uses the ctrl+F and ctrl+G for some shenanigans which are not “find” and “find again” — so that means the first thing I’d have to do is trawl through the hot keys to see which other standards they’ve broken…

      … nothing that can’t be fixed I guess, maybe there’s an extension to handle that? So far, notepad++ is my favourite. Shame that there’s no equivalent on Linux these days… used TEA for a bit and it’s great but completely non-standard, too.

      Oh, and one question: Can I select a section of text containing line breaks and such, then find/replace them with another section of text also containing line breaks? I used to do that all the time with Nedit before it became outdated and the developers started thinking UTF was irrelevant…

  20. Da Mage says:

    As someone who has been working with software rendering for the past 2 years, I totally understand your problems with integrated graphics. The moment you start asking the CPU to do GPU tasks the whole thing just grinds to a halt. In my work, the biggest problem is resolution….I can handle heaps of triangles, but when it comes to rasterising, the number of pixels to be coloured just makes it take forever.

    My solutions to increasing performance was to do less per-pixel calculations and/or upscale from a smaller resolution. It was also important to draw from front to back so that the depth buffer could quickly skip pixels that were already drawn on.

  21. Dude says:

    2D Borderlands sounds pretty good to me, Shamus!

  22. Diego says:

    Feature-creep is a problem, sure, but in this case I wouldn’t call it feature creep. It doesn’t sound like it. Sounds like you had a lacking design and needed more features. With more features come a little bit of redesigning and tweaking. THEN, if features keep creeping in, you can call it feature-creep. :P

    All in all, you guys seem to know what you’re doing. I have yet to see a single game dev team go through a smooth ride where everything works out the way they planned and never thought of giving up on everything and never rehearsed an alibi in front of a mirror “I don’t know how my partner died, officer, I swear”. So you’re good! I bet this game will come out and will be great.

  23. Adam Phant says:

    It might be neat if randomized weapons could have perks, like “reduces recoil but decreases deceleration.” Firing guns doesn’t move you as much, but stopping takes longer. In effect, the player robot would have more mass. But that’s kind of a boring example, innit? Sure it might be written out to explain what it does, but it’s basically a stat change. A more interesting perk would be something like “does double damage when under half health.” Or “gain a temporary shield when you would otherwise die.”

    Y’know, stuff that needs to be coded.

    I think it’d be neat because +2 damage, -0.2 recoil, +0.1 width is boring. It’s like, yeah, the stats are better, but who cares? I’m still dodging rockets and enemies aren’t taking too long to kill. Stat changes are only interesting when you hit a wall, and enemies are taking significantly longer to kill. But then you just get new stuff from nearby with significantly higher stats and that’s it, you’re done upgrading for awhile (until the next wall).

    It’s how I played Oblivion, World of Warcraft, Borderlands, Borderlands 2, Skyrim, Diablo 3, and now Destiny. Getting new stuff is boring unless it’s a significant change””and a death-averting shield is a signicant change. (But then replacing that perk is something of an issue, huh?)

  24. WJS says:

    Shamus pretty much literally taught me everything I know about graphics programming, so I don’t really feel in a great position to make suggestions, but my money on the integrated graphics slowdown would be all the blending I see. That bottleneck is pretty much totally unrelated to how many triangles you’re forcing through the thing. (I believe I learned that here)

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="">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply

Your email address will not be published.