🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Thoughts on designing games for incremental implementation?

Started by
6 comments, last by DvDmanDT 5 years, 9 months ago

So we've all encountered the countless people who have their idea of the perfect game they want to develop, while just starting out in development. We've all told someone to start with something smaller that they can actually complete and work their way up etc. We've all also seen that advice be completely ignored only for the person/team to dive head first into an impossible project, simply because that's their dream. Making another Tetris clone just isn't fun for them, they want to work on that next generation MMORPG with 2EVERYTHING!!!!!!!1111oneone". And honestly, I'm basically one of them.

What about designing games in steps or rings that can be incrementally implemented? So that you can implement a small portion of your dream game, and it would still be a playable game on its own.. What are your thoughts on this? Does anyone have experience with this? If yes, was it a small project that grew or did you actually have a grand vision in the beginning? 

Advertisement

What you describe is kind of how games (and software in general) are made. You start with the simplest thing that works and then start adding things one at a time. You try to make sure that after every iteration you have something functioning. Then at some point, usually when time or money runs out :), you end up with a product that can be called "done".

The important thing is to know how to separate things, and how to ignore some things until later. This is what most of the "mmorpg with everything" people don't do, and it makes their projects go nowhere. For example, if your dream is an mmorpg, the first step on the way is to have a single player running around empty space. If you don't know how to do that, then the first step could be a Tetris clone :) or a programming tutorial. Anything that you can do, and is smaller than the step that you can't do :) 

Once you have your player running around, the next step is to give them a sword and a monster to kill. Don't think about multiplayer, don't think about loot, don't think about classes. That comes later. Do something small that you know how to do. When you do that, look at what it looks like and think about the next step. Maybe add more monsters. Maybe add another player. Maybe add more swords :) But you do only one of those things and forget about everything else.

Of course, the first steps will not be games by themselves, but they will be "complete". After enough steps you will end up with a game. Or you will find out that the idea is not that good and you will change it. Or you will give up on it and use what you have so far for your next, better idea. In any case, you will have something completed.

I don't think I communicated my point well enough. Hmm. You should of course implement your game in steps, component after component in some way, and in a way so that you can incrementally test stuff and not have to wait until everything is done before you can even compile (been there, done that ?). But that's not really what I was referring to.

1 hour ago, 1024 said:

For example, if your dream is an mmorpg, the first step on the way is to have a single player running around empty space.

What you are describing here sound like some form of tech demo. That can be fun and cool and all, but I was more interested in making sure that it's a game on its own. So that the design document is basically "tiered" according to implementation phases, and that each tier/phase should be a complete game on its own. I'm sure many plans and design documents have some form of wishlist of features with some form of priority or similar. That's a related, but slightly different concept. This is a bit of a different mind set I guess. Does anything I say make sense here?

That still sounds like what I said, except that your "tiers" are made up of several of my "steps". Again it's all about separating features to "required" and "optional" ("now" and "later" :) ) Many games are made using that principle, you just don't notice it because you only see the finished game. The game itself is made out of as many tiers, and some tiers become DLC, expansions or sequels. Or cut features, if things don't go so well.

You can see the tiered development in many Early Access games. Often each update to an EAccess title is another tier over the previous game.

I don't know. Maybe. To me, it sounds like you are still talking about milestones and optional features. About releasing a 1.0 and expanding on that. Like iteration, where I think I might be more like recursion.

Like designing and implementing a game, and then using that game as a mini game or component in a bigger game. The first game may need to add extra elements to make sense on its own, that may not be necessary or at all desirable in the complete game. 

For example, in the MMO. Let's say the world has lots of mountains that you need to climb to get around. You have some ideas for interesting game mechanics that would make this climbing fun, and it's an important and big part of the travelling aspects of the MMO. Now, you implement it and release a tech demo/alpha version. Your players say "this is cool and all, but what is the point? Where are the monsters? Where's the loot?". They've entered a very incomplete MMO world that just feels empty, despite the cool climbing mechanics. What if you instead designed the climbing experience as a game, and added some time keeping and/or scoring, etc. That way, you have something small to show off and perhaps build some hype around, and if you grow tired of your full project and/or run out of funds or whatever, you at least have something to show for all your hard work, and not just that "empty, incomplete world" that tends to be the effect of Early access games running out of funds or similar.

Ah, now I understand what you're saying. Kind of reminds me of Star Citizen and their "modular" approach. Also Gwent that came out of the Witcher 3, but that is the reverse of what you're asking :) 

But that raises a business question: If you have multiple standalone games, why not sell them separately as regular games. What is the benefit of combining them into one large game? Especially if the game mechanics are different. I don't play MMOs, but from what I understand everyone is playing them for the core mechanics, and their minigames are too "mini" to be standalone.

When someone wants to play a climbing game, they will play the climbing game. When they want to raid, they play the MMO. Minigames are there for people to kill time until the raid is up, I don't think they should be as complex as standalone games.

Well, the idea is basically to trade one huge pre-alpha against several more or less complete pieces. It can be about not losing motivation. If you make a small game, it's an achievement and you can pat yourself on the back and all that. You probably should set out to do that in the first place, but for many people that doesn't seem fun. They want to work on some huge dream project that they will realistically never be able to complete, at least without help. This way, you'll get something to show earlier on and perhaps be able to attract attention and/or funding. Hopefully, at least that's the idea i guess. Honestly, I'm looking at it mostly from a hobbyist perspective where time and motivation are my primary concerns. 

From the business perspective, the complete game would be worth more than the parts, but the risk of investment etc would be smaller as you'd have something to show even if you have to abandon the project haft way. With a classic milestone based approach, you can track progress and make incremental investments etc to reduce risk, but unless the project reaches the critical 1.0 stage, it's likely all investments would have been for nothing anyway. With an modular approach, perhaps you could sell at least some of the modules and make something from it. 

My idea is a bit fuzzy, but it's not really modules either. It's a bit of a mix. In my MMO and climbing example, perhaps the next "stage" would be to add a town with villagers and shops. This is a natural progression towards my full MMO. But what can the shops sell? Swords? Armors? What's the use for those in the climbing game? We once again end up in some incomplete state. Perhaps you can find gems or valuable bird eggs while climbing that you can sell, and perhaps you can buy new climbing equipment instead of swords. Perhaps the town organizes competition, and you can climb in ranks and help promote your town? Now we've expanded on the mini game in the general direction of the full MMO idea, while adding some extra elements that may or may not fit with the full MMO idea, just to make sure we are in a "complete" state. 

This topic is closed to new replies.

Advertisement