RPG Class system

[doggo18]

I think the subject says it all :P I want to write a roleplaying game, but since it is a hobby, I want to do everything right (I stumbled on problems before and getting tired of it :shock:) and since we are blessed with the miracles of OOP, I want to do it the OOP way :D

What I got so far (also after browsing the net and stuff):

TImplementer - Basic class which performs all user interaction. (keypresses, game saving/loading, network play). Keeps an index to the current 'map'.

TGame - Contains all the game data, using arrays like: Map[...], Group[...] and basic game-object manipulation (experience counting etc).

TMap - Structure representing a map. Will perform the walking of characters in the map, and catch


I Dead/Wall etc tiles.

TActor - Basic fella which represents a person.


Problems:

1. Players will have the control over a charactergroup. Where to put this TGroup? As a property of TImplementer, or TGame? Or am I 'missing' a class?

2. There will be different maps. Where should the logic go to decide where to change the map? (All characters have to be on the same map, and will be individually controllable).


I am having alot more questions which I am having problems wording right now. I think something is wrong about my current idea on classes, so input would be appreciated.

Thanks :)

[Sander]

This may just be me, but I think you're making it too complicated. Things that are already universal don't really need classes to be stored in(a good example is the map), so I'd say you should NOT worry about the structuring of classes that much, since it isn't that necessary.

Ofcourse, it can be very handy(especially in the "Actor" case).

Now, to answer your questions, if I get it right, the player will control a group of characters, so you should put that group of characters in the same place as the actors, with the group just being an array of pointers to TActors. But that's just me.

Also, I think that there should be two maps, one which was the base map(probably best if you stored it on the disk somewhere so it doesn't eat memory), and the one which is being changed constantly because of (n)PC interation(doors opening, closing and such), which should be in the implementer section because it is being manipulated by the player and others.

Sorry if I got some ideas here wrong.

Oh, and good luck on your game... :)

[doggo18]

I see what you mean; however, I want to keep my engine as 'dynamic' as possible. For example, at some point, I will get to scripts. How would I let the script influence another map if it isn't loaded? Also I want my maps to be dynamic; if for example an explosion would destroy a wall, the next time you enter that room (map) the wall shouldn't just.. reappear. I tried using directories for my save files and minimize the memory use before, but it made things to complicated I think. (Also, aren't games the only kind of application that 'are allowed' use the memory and computer for 100%? :P)

I see your point on the group idea, but I am still wondering about a few things. First of all, where do I 'keep' my relation to my group? Usual TActors would go in an Actor array in a Map object; but if I would do the same to a Group I would have to duplicate code to reach the groupmembers. Perhaps I should put the Group thing on it's own place. Perhaps I think that I know what I am missing now... I am looking at the group as an 'exception', but perhaps all Actors should belong to a group. A group could be a Player, networkplayer or a computerteam such as a Devil party. Each team would then have it's own class, and with it, it's own priorities. I could make devils prefer to kill angels than human enemies. Now all would perhaps fall in place. The TGame has a list of parties. When initializing maps, the TGroup would check if it has any characters on that map, and create things accordingly. Actors would be at their proper spot, and not be hardcoded in maps.

If I understand your thing about TImplementer correctly, I think you don't understand how I mean it. The TImplementer should be the layer that processes input and such; while a TGame would handle the game itself. The advantage of this would be that I might be able to make a TNetworkGame in the future, which would use a server as it's primary source of data.


By now, I have rewritten each paragraph atleast 5 times, since I keep improving my idea of how I think it should be. Your comments are very helpful, so please keep posting (even though I might go the opposite way) :D:D

[Sander]

Great, nice to see you're getting further :) So I'll just say something more.

Hmm, I think I've been wrong about the map thingie, I think you should just keep one copy of the map(since it's persistant anyway), and keep updating it. Perhaps putting it in a seperate class may be good, but if you don't want that(which I can understand), the TGame class would be the best choice. ANd when you leave a room(and therefore the map) put the map somewhere in an "off" list, meaning they aren't being used, and when there are a certain amount of maps in there, write the newest onto the disk(into a temp dir), and therefore saving memory(although you're allowed to fuly utilise memory, saving memory is always good).

Right, about the groups, I would keep the groups seperate with indeed a few priorities(This can get very complicated to keep up though, since it could mean having an insanely large array to keep trak of all of the likes/dislikes of the group(that was a BIG problem in Neverwinter Nights)), but I wouldn't hardcode their places into maps, instead, I'd still create it as a basic array of pointers to TActors. And then I'd give the TActors their locations, with the maps only having pointers to the actors the map currently has in it's area.

Alright, I DID understand TImplementer wrongly, so I'd suggest putting the groups seperately in a class within TGame. Heh, mazes of classes can bve very irritating though.

[doggo18]

Hell why am I speaking english? We're both dutch :P Well for the other forumpeople I guess ;)


Saving stuff in a temporary spot might be a solution, but then again, it would leave the class system. How would an object about the game know there is something like a filesystem? I know it might be nitpicking, but since it's my hobby I want to try and follow the rules haha :p

We're partially on the same track for as far actors are concerned. I was thinking of extending the Actor object with an array of TMapAppearances or some other goofy name. This would be an object having a FMap field, x and y coords etc. When initializing the appearances the map would be notified as well about this character. It would allow the use of one actor all the time you need a certain character. Hell, let's say there is a rogue who accompanies you while he can use you. Suddenly he'll take off with your stuff. Later on in the game, you might face him, kill him and regain your stuff.

I just realize that action ofcourse will be kept to one room (except for scripts then), so the TGame object will have an ActiveMap identifier. Now I am wondering if this is the right way. I might be wrong, but if I am right a group would have to use the ActiveMap, cycle through it's characters, determine if a person is in it's group, and then do the thinking. Going through it's own array would take ages once the game gets big (Lots of actors, lots of maps, so 2 nested for-loops). I think this can be done more efficient, but how?

[Sander]

NNNNNOOOOOOOOOOOOOOOOOOOOO, I just lost my post :( :(

Alright, then let's go at it again.

If you want other things to know where to find the temporary stuff, all you need to do is create a small array for them and cycle. Simple as that. Ofcourse there are other ways, but it's not hard.

Actor thingie sounds good.

Another thing you could try, is putting a small array of pointers to Actors on each map, so that when you select the activemap, it looks in the array, and automatically lets the actors do their thing. If you want to get them governed by their groups, put a pointer to the group on the actors.


Wow, somehow I just shortened my post when I lost it...

[doggo18]

Yes, I had that idea as well.. I want the actors to be 'controlled' by their group; this way the player can control a TPlayerGroup instance (or something similar, in any case something WITHOUT ai :p) and it would not require any seperate coding. The TImplementer would set properties of the group according to the players actions, which would be executed during the think time of the player.

I know what you mean, I was only wondering if it isn't going to get to memory intensive. But I guess it won't be :p

Now I just am going to have to find a way to implement a 'battle-modus'. I assume I would have to set a flag in TGame, and fill an array with all the fighting actors. Well I'll wonder about that later :twisted:

Thanks for all your help so far :)