Let say I want to make an RTS game, a very simple one ... very simple, but expandable if I want it to be. What makes a game RTS? If you had the game engine, the code, and you wanted to create a small RTS, what would you like to be able to do? It has to be realtime ofcourse. Let say I make a game (like C&C), you can create tanks and soldiers, and a few buildings, and collect a resource of some sort, and be able to command my units around to attack or defend something, and have an AI... What if I asked the above question about FPS and RPG? An FPS could be... like Quake, have a character, be able to move around, pick up a weapon, use weapon, collect power ups of some sort, be able to go into buildings, maybe interact with stuff like open doors An RPG could be a Diablo type game, much the same as an FPS, only that the camera is above the person, and you would be able to adjust character stats, and interact with other NPC like talk, trade, fight, and be able to get and solve quests .... This is just brief, but what should these genre include of different stuff?

It's not important. Personally I think it's better to design the game how you want it and worry about classifying it later. (or better still, let other people worry about it)

These genre categories aren't meant to be too well defined. They're broad and fuzzy and they have a great deal of potential to overlap, and the less well defined they are the better.

I know they are broad and fuzzy ... I was more looking for what others put into it?

There is no one genre really. You can spread a game along as many as you want. But it isn't very smart to make the player do alot of things and have to switch from different views and modes.

The player must feel important but not the best. There must ALWAYS be someone greater, or the player will abandon the game because they will not feel excited. It is the drive that makes players stay at games. They enjoy leveling up and getting stronger rather than being the all-powerful. They might like being all-powerful for a day or so but then forget about the game and move on. Therefore you must CONTAIN the player, but show them a path to getting out.


So, my advice is to keep the game flowing. Let players worry about genre and focus on keeping them entertained.

Quote:

Original post by Sandman It's not important. Personally I think it's better to design the game how you want it and worry about classifying it later. (or better still, let other people worry about it) These genre categories aren't meant to be too well defined. They're broad and fuzzy and they have a great deal of potential to overlap, and the less well defined they are the better.

My thoughts exactly. When you make a game, you concentrate on how your game will play period. You shouldn't think of it as what genre it fits into. If you limit yourself to thinking that way, you may also limit the amount of creativity that goes into the game design.

Genres are usefull for describing your game in words to someone. In a design document if you say its a FPS people will imediatly know that the screen will be looking though the eyes of the hero. Or when your trying to tell your friends about a game your making these broad categories are handy are very good at helping to get your idea across. Saying "well the screen is looking through the eyes of the hero and you shoot lots of stuff and its a 3D world and you pickup weapons and guns and ammo and stuff" will have the same effect as "its a FPS". Geners are not a set of rules which you should follow when making your game, they're a description of the final game.

ok... let me put this differently

If someone wants to create an FPS game, what functionality should I (as an programmer) expect to put into a an engine?
What should the engine be able to do?

Let us assume I one day meet an game designer, and we together create a game, what will be in that game, and what should I be expected to code?

(bad english maybe), not sure if I made myself clear...

Quote:

Original post by DarkSlayer ok... let me put this differently If someone wants to create an FPS game, what functionality should I (as an programmer) expect to put into a an engine? What should the engine be able to do?

Well, it would have to have a first person iew and allow you to shoot. That's all really.

Quote:

Original post by DarkSlayer Let us assume I one day meet an game designer, and we together create a game, what will be in that game, and what should I be expected to code?

Whatever the designer puts in the design document...

Quote:

Original post by mrbastard Quote: Original post by DarkSlayer ok... let me put this differently If someone wants to create an FPS game, what functionality should I (as an programmer) expect to put into a an engine? What should the engine be able to do? Well, it would have to have a first person iew and allow you to shoot. That's all really.

To be a tad more precise, I would expect to be able to shoot stuff. Like having targets or something.

Quote:

Original post by DarkSlayer What should the engine be able to do?

The thing is, trying to specify an engine according to some purely speculatory game is essentially impossible, and is a backwards way of doing things.

The game is generally designed first, and the engine designed to meet the requirements of the game. Alternatively, a third party engine is chosen that most closely meets these requirements - possibly with a bit of tweaking of the game design in order to fit into the engine's capabilities, or rewriting of chunks of the engine where there's a problem.

Now, if you're just developing an engine, with the hope of turning it into a game later, then what features do you need? Well, there's no way of knowing what this hypothetical designer will need, so you just need to keep the engine as generic as possible so it can be relatively easily modified to suit his needs. Go ahead and implement all the fancy graphical features you want, but avoid writing any code which limits the game that can be created with it.