One bite at a time...

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.

He's not making an engine.

Quote:

Original post by Kest 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?

I have ideas and examples to refer to for the FPS, action RPG and the final CRPG. Coming up with the same for the "inbetween" games is the part I'm having problems with.

Quote:

If you don't mind subtracting the S from FPS, you could try a Shadowgate clone.

That's an interesting idea. I hadn't heard of Shadowgate before now, but it looks similar to a couple of other games I have played (more than a few years ago).

Quote:

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.

That depends on how far back you look for inspiration. If you compare Wolfenstein 3D or Doom with something like Tribes 2, you'll find that the latter includes a wide range of additional features (flying vehicles, multiple mission types, teams etc.).

Adding features is probably easier than subtracting them. I would like to be able to remove one or more features from something as simple as Doom so that it was no longer an FPS, but could still be thought of as a game.

Quote:

There are still very good reasons to make demos. I just made a demo a few weeks ago to experiment with destructable walls.

I don't have a problem with experimenting and/or creating prototypes, but I do want to finish several simpler projects before tackling the final one. There are some things you just have to learn from doing.

Quote:

Original post by Edtharan 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.

That sounds like it that could work, and is something I probably wouldn't have thought of.

In the initial version you mention I would add some sort of restriction to the playing area though, or players with a head start could avoid being tagged by continuously running in a straight line.

Including a simplified representation of an actual school yard could provide additional obstacles.

Quote:

Original post by paulecoyote 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.

I have licensed an existing (completed) commercial engine and hope to avoid modifying its source code until the final project. The original creators add new features and/or release addons on a fairly regular basis.

It should be possible to create the simpler games using the built-in scripting language rather than modifying the core C++ code.

Quote:

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.

That is the part I'm having trouble with. Coming up with designs that only include features that can be reused later is proving to be harder than I initially thought.

If anyone else is looking for inspiration, I found this page at Wikipedia, which describes dozens of variants of "tag". They also have a section on children's games.