Like many people here, my ultimate goal is to design and create a first person perspective computer role-playing game using an existing 3D game engine. However, unlike some, I wish to work my way up to this by creating smaller/simpler games first with the same engine. In other words, rather than immediately attempting to eat an elephant one bite at a time, I would prefer to consume several more manageable meals first. Can anyone suggest some games that would require a smaller number of the same features or provide a link to a site listing such a progression? I have been thinking of creating a simple FPS and then an action RPG before the "full blown" CRPG, but can't help feeling that there should more/smaller steps to the final goal.

Well, can you make a number guessing game? Tetris? Breakout? 2D platformer? Can you show a simple spinning cube on the screen? Those are some of the first games most people recommend for beginners. If you can do all of that, then you can start learning how to do a more involved game.

I will be using an existing commercial 3D game engine, so creating those games wouldn't be as useful as if I were using a 2D engine or coding everything from scratch.

I have worked my way through a few simple tutorials showing how to create terrain, items, a human player character etc. in a simple game world, plus I have several example games to use as references.

Quote:

Original post by Wysardry I will be using an existing commercial 3D game engine, so creating those games wouldn't be as useful as if I were using a 2D engine or coding everything from scratch.

Yes, but those games will still help you learn basic concepts that apply to ANY type of game programming.

Possibly, but in a 3D engine (other than the number guessing game) they would also introduce several new problems to solve that wouldn't be present in the game I ultimately wish to create.

Are you working with a 3D game graphics engine, or a full-scale game engine?

Why are you worried about creating a game? Why not a demo instead? A demo has the advantage of not needing a goal, not needing to be perfect, and never needing finished once it is no longer useful. You can always turn a demo into a game. But turning a game into a demo may feel like a failure.

It's a complete game engine.

I have several reasons for wanting to create complete games rather than demos. First of all, I need to learn the entire design and production process. Secondly, others would be more willing to help me with the final project if I can show that I have completed fully functional games in the past. It would also help my own confidence.

Maybe "a smaller number of the same features" was a poor way to phrase it. A better way might be "a subset of the features required".

For example, an FPS would have the same first person viewpoint and character movement, coupled with simplified combat and interaction with items. However, it would not need complex NPC interaction, inventory manipulation, skill/level advancement etc.

The potential to recycle code and assets from the earlier games is one of the main reasons why I am looking for a reasonably linear path to increasing the complexity level.

Quote:

Original post by Wysardry It's a complete game engine. I have several reasons for wanting to create complete games rather than demos. First of all, I need to learn the entire design and production process. Secondly, others would be more willing to help me with the final project if I can show that I have completed fully functional games in the past. It would also help my own confidence.

Are you looking for ideas for a simple 3D-FPS type game, or do you literally need to see retail games that have limited functionality?

If you don't mind subtracting the S from FPS, you could try a Shadowgate clone. A game where you simply walk about and interact with scripted objects. A complex puzzle solver. No jumping, shooting, or other action sequencing would be necessary, which will subtract a lot of complexity. There will be added complexity in the scripting, but getting comfortable with complex scripting will do you a heck of lot of good in any type of future titles you want to work on.

Quote:

Maybe "a smaller number of the same features" was a poor way to phrase it. A better way might be "a subset of the features required".

That was my bad; I missunderstood. I must have edited my post right after you read it.

Trying to think of a simple first person shooter is pretty difficult. I don't think they've really advanced much in any respect other than graphics and physics; the two primary things that are probably fed from your game engine.

There are still very good reasons to make demos. I just made a demo a few weeks ago to experiment with destructable walls. My main project would be a mess if I hadn't moved that testing elsewhere. But that functionality is now in my game with a very clean underlying structure. Using a demo allowed me to throw global variables everywhere (programmers), toss random assets in the release folder (artists), and to just make a total mess (everyone). The simple controlled environment made testing go much faster and with far fewer consequences for failure.

I would start with the game "Tag" (you might know it as Tips, Red Rover, etc). The game has been common in school yards for many generations, so it should be familiar to most people.

I would make a version of this game in your 3D engine. The rules are simple to impliment and it will use many of the techniques needed in any more complex game.

The basic game would use these rules:
1) All player move at the same speed, have the same rate of turniong, etc
2) One player is designated as "IT".
3) If the player who is designated as "IT" moves within a certain distance of another player and presses the "Tag" button then the target player is tipped and the status of "IT" is transfered to the target player, with the taggin player loosing the status of "IT".

Now once you have the basic game you can start expanding it so that it more resembles an RPG. This will entail giving the players Attributes. My suggestion would be to include these attributes:
Endurance: If a player is running around, then their stamina will be reduced. Once their stamina is reduced to 0 then they can not run untill their stamina rises aboe 50%. Wehn a player is not running their stamina will recover.
Recovery: This is the rate that a player's stamina will recover. The more points spent in this Attribute the faster the player's stamina will recover when they are not running.
Speed: This is the speed that the player can run at. The faster a player runs the faster their stamina will be drained.

Players would have a set number of points to destribute between these Attributes.

Next you could impliment skills. These would be special manouvers and abilities that the player can use to avoid being tipped (like a burst of speed, quick dodge, etc).

Then you can impliment health. Now that you can tip someone, you can create an attribute (health/resistance/consitution/etc) that must first be reduce to 0 before the player can become tipped. So the act of tipping, does not automatically transfer the status of being "IT", but instead, lowers their health attribute and once that reaches 0 the status of "IT" is transfered.

Lastly you can impliment items that give certain bonuses, or are nessesary in Tipping the other player, and remove the nessesity of the "IT" status before a player can "Attack" another.

Now you have a basis for a RPG or even FPS game.

Just be careful of "enginitius". It's an aflection many developers have had at one point or another, where the engine is the focus a game never gets done.

As you said, the engine is really just a bunch of code that can be reused in other projects.

It seems you want to evolve your engine making little games on the way, which is def one way of avoiding enginitius.

Start off with something with very simple physics, input and visualistion (pong, whatever) and go up through the arcade classics.

Try not to make everything too generic as you go along... allowing for x in the future or y scripting system in the distant future. Only do stuff with an immediate need. Over-engineering is a sure way to not get anything done. It is "software" after all, it will change over time. Always choose the simpliest way of getting something done, without breaking any good practices (eg copying and pasting chunks of code is simple but bad). When you feel pain of the simple way, then and only then go to the next less simple way.

Also it is very important that you think each time from the end user perspective - code from the game using the game client point of view rather then the other way around. Doesn't matter how pretty the engine code is if it's really hard to remember how to call in to or takes several obscure steps to use. Otherwise you will come to code your game after creating great big chunks of your engine, and realise, actually, that's not so good from the game programmers point of view.