Here’s a question: how long does it take for a new game project to add a way to win or lose?
I ask because I noticed in my finished 48-hour competition projects, I typically wait until the last hours to add a way to end the game, and I wonder if waiting this long is a common occurrence for other game developers.
In the last day or so, my efforts focused on providing Stop That Hero! with a way to know if the game has ended in victory or defeat for the player.
If the Hero has conquered the castle, the game knows that the player lost and ends the game with a message informing the player. If the Hero has run out of lives and is currently dead, then the game knows that the player won, and a different message is presented.
End game conditions are obvious things for a game to have, but early in a project, when you’re trying to figure out game play, it’s easy to forget that the player is going to wonder what his/her goals are. Or not. Maybe end goals are the first things game developers should implement? Maybe they should come last? See the questions at the end of this post.
Now, recognizing and handling defeat was relatively easy. I already had a way to clear towers, and I merely check if the castle is specifically cleared. Clearing is kind of hacked together, though. All clearing does is deactivate the target for a tower/castle, so my defeat condition monitor is checking whether the castle’s target is active.
I’m not happy with the abuse of targeting components in tower clearing, but it functions for now, and it is easy to change once clearing becomes a more involved. When the Hero reaches the castle, a message pops up to inform the player that the game was lost, and a button is presented. Clicking that button takes the player to a yet-to-be-implemented stats screen.
Victory was almost as easy, but there’s no combat mechanics in the game yet, and until I started worked on victory conditions, there was no concept of “lives” for an entity like the Hero. So I had to do a little more work, such as implementing entity lives and a command to kill an entity.
And in the end, the way I test that it all works correctly involves mapping the “K” key on the keyboard to the “kill entity” command. I’m keeping this one around because it seems like it would be useful for general testing.
Still, even without key parts implemented, Stop That Hero! has ways to end, and I was surprised at how quickly they came together considering all the moving parts I had to create. Ideally the victory and defeat conditions could be scripted objectives, but what I have is good enough for me to get to an initial, playable release.
Now, some questions for the veteran game developers. Is it ever too early in a project to have a way to end a game? Does it limit the possibilities for a game’s design too early, or is it a good way to keep a game project focused? Does it depend on how open-ended or specific the project is?
8 replies on “Adding Victory and Defeat Conditions to a Game”
I normally code at least rough endings in as early as possible. For me, getting those types of game framing necessities in gives me something to frame the continued development against as well as just making my game “feel” like a game as early as possible. I often find that is critical for my morale and motivation to keep moving ahead in the development. These days I have a framework I’ve been using, modifying, and improving for over two years now so a lot of that stuff is far easier now which is nice. I try to have the first playable prototype within the first 10% of my expected development scope. A lot of the games I develop average around 100 hours of effort. That means I like to have something the is playable and roughs in the “sketch” of the game’s boundaries in about 10 hours. I know that depending on the game this can be more difficult but I’ve found it has held pretty true over the last 5 games I’ve worked on so far since I started really striving for this type of rapid prototyping and development. I think a lot of my motivation is driven by the type of game studio business I’m trying to do which is small scope Flash games right now as I hone my game design chops. I can’t afford to wait too long to know if the game is fun or to get feedback from actual players. So much changes as soon as you let the players in. That’s when it seems the real work begins…
Thanks for the insight, HybridMind! It’s common knowledge that getting playtester feedback early and often is important, and I guess it didn’t occur to me that it means having a game that can end or at least has some goals for them to play with. Otherwise, I’m sure a lot of the feedback would be “So, uh, what’s the point?” B-)
I always try to have a solid plan for what the end conditions will be. Trying to reach victory and avoid defeat is a specific part of the fun that the player has, so it must be a core part of the design. However, as I program, I do leave the implementation to the end. I put in all of the data that needs to be there to test it, but I leave out the tests until the end. They’re typically simple to implement. I also really love timed testing of conditions, where the game is over, but still continues for a few seconds before the game over screen comes up.
My long-term project has more complicated end conditions. I use a tree of objectives, connected by operator nodes (and, or, not). Each objective can be asked whether it’s complete or not, which recurses down the tree.
Honestly, I usually do the win/ loss stuff as the very last of the core development, putting it after all the other game mechanics but before much tweaking and polishing. I try to focus on making the gameplay work and be engaging, then throw the ending on after.
I want to play the game. Also, do you need graphics made (not that yours aren’t amazing). I may know a couple UI designers who are looking to cut their teeth on a project for fame and/or money.
Oh, I will definitely need art created. While I believe I could eventually make good art, I’d rather pay an expert to art this game up for me. B-)
[…] Adding Victory and Defeat Conditions to a Game […]
[…] Stop That Hero!, I already knew that things were going much more slowly than I would have liked, but the importance […]