Notes about what I do
I have to explain some things about the text RPG thingy I'm doing right now. First, this is an exercise in software design, not a exercise in game programming. It means that the real goal of this stuff is to show how to decide what solution to use, not to show that I always use the best available solution. While I'm trying to develop a semi-realistic solution (the games rules are rather complex: some of the rules are actually inspired by the D20 system (skills, for instance)), it is obvious that this solution can't be used in a production evironment.
Of course, the right way to go should be to incorporate a scripting system into the game rule engine. This way, the engine will be very open.
I won't do this, for at least 3 reasons:
- adding a scripting system only increase the number of solutions that might be choosen to answer a particular problem. It don't change how we need to think in order to answer this problem.
- a scripting system may add some unneeded complexity into the game engine (object and function binding?)
- in the end, I'll have to write scripting code, which is rather similar to non-scripting code. For teaching purpose, I'm going to stick to C++ :)
This is why i'm going to hardcode nearly everything. It means that each time you'll want to add a room to the game, or a new creature/npc, a new object then you'll have to build the game again.
Fortunately, I'm not (totally) dumb. Adding a scripting system (and changing some design solutions I took) will be the next step of this teaching session - once we'll have a working version of our text-based game :)
I still have a lot of ideas ;)
Rooms and Doors
Now, a (very) small update about the project itself: since we are going to handle rooms, I finally added the Sector classe: which represent a "room". I used this name because I'd wanted to add more than just rooms to the game: forests and their glades are pretty good setups too :) Sectors handle pairs of Path+Sector (using std::pair
This is subject to change. I originally did this because I didn't want to introduce yet another cyclic dependency between Path and Room. using std::pair<> I break the dependency between Path and Sector (the dependency between Sector and Path still exists) and I allow myself to reuse a Path that don't have any intrisic data in another room. One of the consequence of this is that I am not able to say from which room the player comes - meaning that I can't create one-way doors using this system.
Another solution would be to reintroduce the cyclic dependency (the path knows to which sectors it belongs). I loose the possibility to reuse a path that don't have intrisic data (because now, all pathes have these intrisic datas) but I gain some other possibilities.
Another possibility is to introduce a base class for Sector. Sector inherit BaseSector, Path knows BaseSector, and Sector knows Path. The solution might be good, but it introduces a fake class (BaseSector) whose role is to be known by another class (Path). This design is rather artificial :/
Some pretty useless thoughts
- A nation at war releases a lot of war-related games. Strangely enough, these games are supposed to be fun to play. I still don't see what makes war so fun.
- I should stop irc. It eats too much time, and is not really good for productivity.
- working with a terrible headache is really difficult
- as I stated on irc yesterday evening, I'd like to work for a game company in UK - as a consultant. If you believe someone can be interested, please, drop me a word :)
See ya laters, dudz!!!11twelve