I’ll never be able to do this. I’m wasting my time. It was stupid to even begin this project. It’s too big for me. It’s too hard. What if people don’t like it? What if nobody buys it? What if I can’t even finish it? What if the game just erases people’s hard drives?
Hey Shamus, you could always finish that book you started!
Ok, so let’s make a videogame.
At this point in the project, there’s not a lot to talk about. Sure, I’m DOING a lot of things, but it’s all fussy polishing, balancing, debugging, and code-cleaning. My change list looks like this:
Made the placeholder graphic do the same job in 1/10th the lines of code. 2 hours ago New game begins with smartbomb NOT ready. 2 hours ago Adjusted the level file to put the new story points in their proper place. 2 hours ago Updated the upgrade menu to reflect the change from missiles to smartbombs. 2 hours ago Ajdusted vertical text display to be less cramped. 4 hours ago Make smartbombs explosion larger, more benefit from leveling the skill. 4 hours ago Version 0.4.0 - Code cleanup. 4 hours ago Hud message for when smartbomb is ready to fire. 5 hours ago Many small balance changes to how smartbombs perform. 5 hours ago Moved the level up tooltips to the message file. 9 hours ago Added frame counter to hud. 9 hours ago Activate key will skip story text, and if pressed again will close dialog. 10 hours ago Particles drawn behind level geometry. Looks much nicer. 10 hours ago Robots will shoot player if they are visible on-screen. 10 hours ago Energy no longer replenishes while charging a shot. 10 hours ago Added new control module to unify inputs and simplify code. 10 hours ago Restored storybox functionality and added Rutskarn's text. 11 hours ago Fixed size & positioning of graphic window in storybox. 13 hours ago Re-enabled story boxes. Made the teletype printing compatible with GCC. 13 hours ago Added message system to load player-facing text from an external file. 13 hours ago Added env variable to scale player explosions. 3 days ago
For the curious, these are specific changes submitted to source control. The idea is that the programmer has a whole bunch of files that hold all the source code. (Over 100, in my case.) You can, if you’re crazy, just make changes all over the place without tracking or documenting your changes, but this eventually leads to chaos and confusion. You have no way of tracking what you’ve done or when, and if you’re trying to work on the same project with another programmer it’s going to be madness.
When you’re using source control, you’re usually expected (or at least, advised) to make discrete periodic changes instead of continuous tiny ones. So I’ll add a feature where the Doom marine can shoot a barrel to make it explode. Then I submit that change with a brief description of what I did, and source control notes the difference between the old files and the new ones. When another programmer comes along in the morning, they can see a list of the files I changed, what lines of code where changed, my description, and when I submitted the changes.
The changes I listed above are all gradual and evolutionary, not radical and transformative. No major technology headaches. No misadventures. No stories of strange crash bugs. I’m releasing builds to my testers about once a week-ish, gathering up their feedback, and then making changes to the game based on that feedback. Once in a while I have a little freak-out of self doubt, but other than that it all feels very steady and predictable. This is the closest I’ve been to having a day-job routine since I went “indie” a few years ago.
So to keep this series going, let’s go back to part 19 when I asked everyone what they wanted to know about the game.
Shamus, how do you intend to structure the game? Are subsequent levels meant to be geographically linked? I mean either depth-wise spelunking, like in roguelikes, or “laterally” linked areas, like in many shmups. Or are they areas linked only by some thin narrative thread, like in many platformers? (“Here’s your lava level!”)
Or do you a hub-and-spoke structure in mind, like in some metroidvania games?
Also, you’ve written about providing some narrative context to the levels. I’m eager to see how you go about it.
For those who joined recently, I answered the first part of this question in part 20. But the short version is that the world is basically a long tunnel running from the entry screen to the final boss fight. Most travel is horizontal, with the occasional downward shaft. Yes, the game does the bog-standard ice/jungle/lava level thing.
I’d LOVE to do some kind of Metroidvania game. That sort of thing is where my heart is, gameplay-wise. But I kind of want to try something less ambitious before I reach for the stars like that. Even working in 2D, a game like that could take a lot of time to prototype and balance, and I don’t think I want to take on a challenge like that for my first commercial project. If this game yields some kind of reasonable return, then I can look to doing something more complex.
The narrative will, basically, be provided via little text popups. Click on a thing, get a dialog that gives you some sort of context and also makes jokes about the crazed robots you’re fighting. Rutskarn is doing most of the heavy lifting when it comes to writing, and I’m just sneaking in the occasional joke here and there. If the player doesn’t care, they can click past the text and get back to the shooting without hassle. I want to allow the player to enjoy the boxes, but I don’t want them to see them as an unwelcome break in flow.
HiEv (and a lot of other peopled) asked:
Have you considered limiting the number of powerups you can have at one time?
I’ve thought about it. The problem is: What happens when you hit the limit?
The player is going to be really pissed if they can’t pick up a favorite powerup because they have a crappy (to them) one. Then players will treat unpopular powerups like a punishment. “Nooo! I accidentally picked up the Air Freshener and now if I find the Nuclear Minigun I won’t be able to pick it up. Shit!”
That’s no good.
We could make the player drop the oldest powerup when they pick up a new one, but then if they accidentally bump into an unwanted powerup they will have to fuss around, picking up the most recently dropped until they get rid of the one they don’t want. That sounds… tedious.
Or we can add some stupid interface screen to let the player pick which ones to equip, and which ones to drop. (Or carry?)
Except, that’s a massive, massive job. We’re talking about an inventory screen that lets you click-and-drag, select things, will show you tooltips so you can see what all this stuff is, and is useful and usable using both a mouse and a controller. You could spend days on something like that.
And when it’s over, the player will have some fussy little inventory juggling to do. It will break the flow of the game and I don’t think it would make the game more fun to play. At least, I don’t think it will justify the time cost.
If this was a game where you had Borderlands-style drops of randomized loot to equip, then an equipment screen would be worth it. But I think equipping powerups would be this worst-of-both-worlds thing where the inventory is complicated enough to break the flow of the gameplay but not interesting enough to be fun in itself.
I could be wrong, but that’s what my instincts are telling me.
I can’t remember who asked, or where, but I’ve seen the question asked a few times:
Have you considered making the game “roguelike”, with perma-death?
I think an optional perma-death mode is going in for sure. The game seems to lend itself well to this sort of thing. When complete, a full play-through of the game ought to take less than three hours. There’s an “emergency teleport” powerup in the game that will teleport you to safety if you’re about to die. (It’s single-use, like the amulet of life-saving in Nethack.) The game is designed to be played a few times and experiment with different builds and powerup combinations, and a perma-death mode seems like a natural way to offer some additional challenge for people who are into that.
So that’s where the project is right now.
Ask more questions!