RPG structuring

Started by
6 comments, last by GameDev.net 17 years, 6 months ago
Hey Iam planning to try to do a small RPG as practice.. I started to write some definations and have a hard time to decide the system. I will make a very common styled RPG. A battle mode and a "Walking around in the world"-mode some dialogues and an inventory system. What I want is just to ask for a few structuring advices. like what classes I should have and what they should do. of course its hard to tell.. but just some ideas would be great after that I would be able to figuring out things myself. thanks
Problems every where
Advertisement
What do you have so far? I would suggest starting with a window class. It should handle creating a window and all the messages it should receive from the OS. Also a character class would be good, it should include references to the character's geometry, an instance of an inventory system, and a location in the world. The 3 above characteristics of a character are suitable places to use classes. The geometry class should handle loading and drawing, the inventory should handle adding and dropping objects, and the location should handle crossing areas of the map.

Hope that helps. Basicaly you're on square one of 200,000. Good luck!
Well I started to wrote.. I came up with an engine that made it possible to cross different areas and talk to people but the structure wasnt good.. hard to implement new stuff so I decided to restart. And ive decided to just start with the definations this time=)

About the main states I came up with only 2!:
GameWorld - the state where you walk around, talk to people and enter battles
GameBattle - Battles
I want to break it down further! ideas?

honayboyz: your reply helped.. I'll start to write some kind of InventoryManager
Problems every where
Well, you might also want a Menu Mode. Other than that, just the two should be fine, if its just going to be a simple RPG.
God is not all-powerful, as he cannot build a wall he cannot jump.Stelimar Website: eddy999999.ed.funpic.org/Stelimar/index.html
Call me a UNIX kid, but I like a clean seperation between "UI" and "Engine".

Not nessicarlly all the way to using seperate proccesses and a text communication medium, but a nice thick barrier between the two can be really nice.

Lastly, serialization is important -- being able to save the game engine state (and maybe the UI state) gives you alot of debugging tools and some rather nice in-game tools. For example, your battle engine can be passed a serialized copy of the data about the battle it is about to run -- and all of a sudden your battle engine is a removable and seperately testable module!
Quote:Original post by ProblemBaby

What I want is just to ask for a few structuring advices. like what classes I should have and what they should do. of course its hard to tell.. but just some ideas would be great after that I would be able to figuring out things myself.


Prototype it yourself, it's the most enjoyable part of it. Then there would be that ugly part where you'd be attempting to finish all these classes.

You'd need a class item. And possibly a class character.
Take a look at the Gamedev C++ Workshop projects (basically a small RPG) - even if you're not using C++ you might find some useful ideas in the threads:

Project 1
Project 2

The projects are for a text based RPG, depending on how comfortable you are with programming and graphics you might want to consider trying to implement it. Plus if you have good design and later want to make it graphical you'll be able to reuse most of the game logic from them.
Start off with two classes. A render class and an update class, with interfaces between the two. Ideally, treat them as two threads.

Within each of these, have a state engine (search google if you don't know what it is). You could start off with two states, wandering, and fighting. It would be very easy to add other states with this, such as front-end and inventory screens.

Going a bit deeper, you will need classes for locations, objects and characters. Define a base class for each of these from which you will derive your other game objects (e.g, player characters and NPCs from character class)

This topic is closed to new replies.

Advertisement