Before I get to far I want to say that all games are accomplishable, for on this site ive notices some big projects come to life, but im not talking about other people with super human abilities to create a huge game,, im talking about myself So, Anyone out there ever set there minds on creating a small, but fun, (Not a flash game or the likes, (Ya know a good 3d game) And found ways to keep the design rather simple and small, Right now im designing a small game with hopes to bring it into being, but even my hardest I cant seem to keep the design small, its so easy to create that mega scale game. Right now ive estimated 25 3d character models for players, 5 races and 5 different sets of armor apease. As well as 7 or so monster models and mayby 10 or more NPC characters.. (Probebly 15) and this is the smallest I can go. (With out comprimising the overall game design) I know its kind of a wierd and hard to understand question. but any input would help. Like techniques others have used, or ect thank you.

first you'll have to ask if you really want to go 3D, I don't see why people equate 3D with good, I can show you LOTS of bad 3D games.

Does it actually being 3D and requiring YOU to make a 3D engine from scratch make or break your design?

How easy can you break up your software design into little pieces? The more chunks that just 'plug' into everything else like little digital Lego bricks that can be upgraded over time the better things can be. (your renderer starting as unshaded, untextured polies, but allowing full gameplay to be finished before you can go back and do very simple changes to the rendering parts could help you if you don't want to take the time to fully debug something as MINOR as the graphics)

I've never really 'finished' a 'game' before, so maybe I shouldn't talk too much about it. :P just small programs that are really just custom calculators for the most part. but I've toyed with code a lot, just find designs and writing more fun than coding.

Quote:

...but even my hardest I cant seem to keep the design small, its so easy to create that mega scale game.

Quote:

Right now ive estimated 25 3d character models for players, 5 races and 5 different sets of armor apease. As well as 7 or so monster models and mayby 10 or more NPC characters.. (Probebly 15) and this is the smallest I can go. (With out comprimising the overall game design)

Well, there's your problem. It sounds like you are stuck in "n00b RPG Mode (TM)". Small and fun games aren't about big worlds and NPCs and monsters, they are about simple and fun game mechanics. Think Tetris or N.

If you absolutely insist on doing an RPG (which I'm almost certain this idea is), here are some tips.

- Does the game have to be 3D? With 3D comes some major headaches that can be avoided if the gameplay doesn't require it.

- What makes an RPG fun? If you say "the number of races and story" then you need to reconsider your design. Role Playing is about getting lost in a personal gaming experience. Role Playing isn't about leveling up, or exploring a huge world, or any of that. These are just things that designers often use to create the experience. You can remove all of these things and still have a wonderful role playing game (see Deus Ex).

The biggest problem with doing an RPG is that people focus so much on a story. Commercial games have a big complex story because they have writers and artists and animators and so forth. If you want to write a story on the cheap, write a book. If you want to make a game, sacrifice some story and make a great user experience.

- Races? What gameplay will be added by having different races? Are you just adding them for story? If so, story should always come secondary to gameplay. If you are sacrificing time that you could spend on making a better game just to have these extra races, you are wasting it. The reason commercial games have all of these "extras" is because they have the resources to do so.

- 5 sets of armor? Again, why? Is having different armor visible going to change the game more then, say, just changing the color of it, or adding an aura-like effect to the character? Or (IMO) getting rid of "armor" altogether and instead creating a more interactive way to increase your defense, such as gaining enhanced block and parry moves? Note: enhanced moves don't have to mean more animations if done clevery... a block can be a projected aura of different opacities/colors to show it's strength and still look really good.

- Monster models. Play Ico, it's monsters are simple shadowy creatures that look damn good and required very little art to pull off. With some creativity, your game doesn't need monster models.

- 10 or more NPC characters... are these adding to gameplay in some way, or are they story driven? What if the game takes place inside the players mind, and when the "story" is told it is through the voices in his head? Or check out Shadows of the Colossus, a game that managed a huge epic experience with only a man, a horse, and a dead woman lying on a pedestal.


Some of my assumptions may be way off the mark. To me, it sounds like an "RPG" (whatever the hell that means) : Armor, Races, Monsters, NPCs... I can say right now that I'm infuriated by the closed-mindedness of many game designers when it comes to "Role Playing". They don't all have to be gaining levels and talking to NPCs in a fantasy or futuristic world! Fight the conventions, avoid the cliches, and make something new and different. By doing that, you will not only customize the experience to your own resources (your "smaller" game) but make an experience that the user has never seen before!

The reason most game designs get out of hand is because of feature and content creep. Generally you have a lot of "cool" ideas that you keep adding on to the game until with in a vary short time it becomes even to big for most professional game companies to handle.

One simple trick you can try to keep things on track is to diagram your design on track is to diagram how all the ideas and features fit together.

Most of the most successful games over the years have focused almost entirely around a single core concept. So ask yourself what is your core concept? Secondly, those successful games also tend to not have more then three other concepts connected to them. Try creating a branching pyramid from your core concept and seeing how things fit together now.

If you can't connect an idea to the pyramid then leave it out since it isn't relevant to you core concept.

To try and keep your game manageable follow the rule of 3. Keep the pyramid no more then 3 levels deep, and have no more then three concepts connected to another. If you follow this then your game will consist of no more then 13 ideas that you have to develop. Which you'll find will be more then enough.

For example:

Pokemon- Collect Them   o Capture in Battle   o Trading     o Exploration- Battle Them   o Battle Items   o Multiplayer   o Different Attacks- Train Them  o Gain Levels in Battle  o Evolution Items  o Learn new Attacks

Well, The game im designing has no story (Or mayby a breif background) and its also a Action Game, With RPG Elements set in a Fantasy Envirnment. The idea for the game is simple, I was playing Zelda 64, for the old N64 and I thought, Man wouldnt it be awsome to have a zelda Multiplayer mode with different classes and races.
But As I got designing it, a few things poped in my head, (Im a partial noobie, Never created a game befor but been doing alot of game editing for 10 years), A Few things would be, Is it going to be All vrs All, or would there be teams, If there where teams how many would there be, and ect. But anyway as I begin designing the game I just go off into all these extra stuff , things that would make this supposidly simple design "Multi player zelda with different classes and races" into a rather large and complex game.

And technogoth thanks for that comment.. im going to create that pyrimade when im done typing. I think it will be very helpful to me, And my design.

BTW. one reason behind my madness is that I want each player to have there own unique character, different then anyone elses, and to allow each player to be able to play there own hero. like some would love playing a wizard type. like gandolf. and still some would like to play a Armored warrior and then to some a mangy rogue or thief.

One reason that I want to do a 3d game is.. well Zelda 64 was 3d and thats the basic insperation. and #2. I do 3d graphics and am not good at 2d graphics.. what would I contribute to the game im designing. if 2d.. then nothing.. Ive tried to teach myself programing but my mind just doesnt function that way, im not to academic but over the years ive learned some of the basic princibles of how games are created..

Quote:

...With RPG Elements...

I just cringed, and anybody who doesn't know me has no idea why :)

Quote:

Man wouldnt it be awsome to have a zelda Multiplayer mode with different classes and races.

Four swords, and they did a wonderful job without the different classes and races. Though I do see where you're coming from.

Quote:

But As I got designing it, a few things poped in my head, (Im a partial noobie, Never created a game befor but been doing alot of game editing for 10 years), A Few things would be, Is it going to be All vrs All, or would there be teams, If there where teams how many would there be, and ect. But anyway as I begin designing the game I just go off into all these extra stuff , things that would make this supposidly simple design "Multi player zelda with different classes and races" into a rather large and complex game.

Yep, that's usually how it starts. Now you have to look at all of that and say "what out of this is actually worth pursuing?"... I can guarantee you that it's a fraction of the stuff you have written down.

Quote:

BTW. one reason behind my madness is that I want each player to have there own unique character, different then anyone elses, and to allow each player to be able to play there own hero. like some would love playing a wizard type. like gandolf. and still some would like to play a Armored warrior and then to some a mangy rogue or thief.

Then it's not a small game, and trying to make it small will (IMO) make it come out a bit half-assed. The reason is that it is a very content-driven experience, and content is big. To create enough content as an indie to compete with commercial content-driven games is nearly impossible... that's why we have to be more creative with how we approach games :)

Quote:

One reason that I want to do a 3d game is.. well Zelda 64 was 3d and thats the basic insperation. and #2.

Many of my 3D concepts come from 2D games, and many 2D concepts come from 3D games (and some from board/card games, etc). Can the experience be captured in 2D?

Quote:

I do 3d graphics and am not good at 2d graphics.. what would I contribute to the game im designing. if 2d.. then nothing..

Do you have a team? If so, if you were to go with 2D art it can still be made in 3D and pre-rendered with much less hassle then going actual 3D (once again, it depends on whether or not 3D will add enough to the gameplay to be worth it).


I'm trying my damndest to get the message out to n00b designers that content driven games are inherently too-big for the average small indie team. Whether or not anybody listens to me... who knows. I wonder what the space baby has to say about this?
...
...
...
...
...
...
..
..
.
.
I got nuthin.

For anyone that is starting with game design, I think the best option is to learn basic programing, and then sit down and design a game, as big as you want, just design it, write down every detail you can, keep going, pour as many ideas as you can into it. Then wait a week or so, sit down again, and rewrite your design, after locking away the first one.

After you finish it a second time, sit down and try to work out (without code!) how you would actually DO the things you want in your game.

Then, once you have found you don't have a clue how to do most of your ideas, you will want to go back to your design and figure out what you CAN do, and start your desgin process over again.

Wash, rinse, repeat.

Keep looking at code, understanding how it works, experiment with making tech demos. Don't make a game! Make something to display sprites, load a simple map and render Red, Green, or blue squares. PLAY with code.

And if "MASSIVE" comes up ANYWHERE in your design,... burn it! even if it is Massive sword or something. That plow blade from FinalFantasy isn't a sword, or a weapon, it is something used to level dirt on roads!!!

To curb feature creep, I usually use a seperate document (or as an apendix to the design doc) where I keep all these feature creep ideas. If I find that after the full design has been implimented I can then go back through the feature creep document and select ideas that can be implimented. I only ever impliment 1 at a time.

Because I am documenting all these ideas and keeping them seperate from the core design, I can manage the feature creep that occures. If I ever encounter an ide in the core design that could be removed without effecting the game I will place this in the feature creep document as I remove it form the core design.

To develop a core design I will write down the principle of the game in 1 or 2 sentances. If this statement is clear and consise and the rest of the design seems to flow on from it, then I considder this a good starting point. If I have to explain a lot of tings that occure in this statement, then I know that it will probably be too big of a game for a small team.

If I have trouble forming this statment, then I know that I have not yet settled on a design and that the coming desing will be riddled with feature creep.

As an example of this kind of statement:
You are a Dragon that has had their Gold stolen. You must fly through levels and defeat bosses to reclaim your gold gaining experence with which you can upgrade your powers.

This is the statement that I used for a recent game design competition. In this statement many of the details were left out (its an above view, 2D, vertical scroller shootemup). One of the feature creep ideas was that you were not the dragon but a dragon rider and could have different dragons that had differnet abilities. This was not feasable for the comp as we only needed 3 levels and the player would not have been able to explore this aspect.

Alother example of the use of the feature creep document was with the weapons. The core concept (as presented in the statement) does not state "more than one weapon", however I had come up with several posable weapons. We implimented the easiest wapon (a fireball shot) and left the others in the feature creep document. Thes included a flame thrower type weapon, a chain lighting bolt weapon (it was suposed to arc between enemies) and a wind weapon that pushed enemies and their weapon shots away from the player.

At one point we realised that we had time to include other weapons besides the fireball weapon. We chose the flame thrower weapon to impliment as it was next easiest to impliment (it was just a modification of the fireball weapon). We only implimented 1 of these feature creep weapons at a time and only had enough time for one of them before the competition ended.

So this system allowed us to develop a large amount of feature creep, but still retain the core design. WHen we had extra time, we were able to impliment some of the feature creep ideas to improve the game, but by keeping a tight reign in the way we implimented the feature creep ideas, we were able to add them to the design when we had time and in an organised way that didn't disrupt the core development.

Another feature creep we enedup implimenting was to move all the hard coded definitions of things like monsters, weapons, powerup, and upgrades to definition files that could easily be edited in a text editor. This allowed up to impliment other features like the extra weapon and a few others easily (though this was an ongoing process as we developed the game).