|
billyak has asked for the wisdom of the Perl Monks concerning the following question:
As an on-the-side project, I'm working on a command-line based game. Of course, always wanting to push myself into learning and using new concepts, I've been trying to abstract the game--separating actual elements of gameplay from the display and state storage.
I am stumped. I have no idea where to go or how to separate game elements from the rest of the code (using OOP, of course.) I try to lay out what I want to happen and work from there, but I always come up with a clumsy and haphazard solution. Having the game have multiple environments with different objects, having the objects interact with the user, and still remain separate from the "engine" is something I'm having difficulty implementing. If having a working game is all that I was after, I could do it using my poor techniques without a problem. I'm just sick of churning out code that is fully operational but poor in style :-/
Please help point me in the right direction. How should abstraction work with something like this?
Thanks,
-billyak |
Re: Difficulty Abstracting
by vladb (Vicar) on Jan 12, 2002 at 07:05 UTC
|
Great stuff! ;-)
What immediately comes to my mind is the POL game scripting language for Ultima Online. The scripting language itself looks much like Pascal, however, if you go and read some of their design documentation etc. you might find a lot of useful stuff that you could borrow or learn from. Here's a link to their online documentation. You might find their Object model in particular interesting: view POL Object Class reference
Of course, i should admit that their documentation will leave you desiring for more as it's a little bit scarce =/. On my part, I'd suggest you build conceptual models of your in-game elements first. Think of what your game is all about and build around that. You are right about splitting your display logic from storage and primary computation (or AI ;-). However, you'll also have to think of how various game elements would interact (again, I can't speak of anything more not knowing much about your game).
Hope this helps ;-)
|
"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
|
| [reply] |
Re: Difficulty Abstracting
by peschkaj (Pilgrim) on Jan 12, 2002 at 11:07 UTC
|
One possible approach to take to this issue is similar to what I am doing right now on my own side project. Although I am not implementing it in perl, the theory is the same.
I am creating a web engine to host a large number of sites, and I sat down and looked at the various features I wanted to include (news feeds, user sectios, online users, etc). I then thought about what each feature was comprised of; what calls would be made to the DB, what would the engine need to do to the data. Once I had the feature set compartmentalized as much as I could, I compared all my information and set everything down as a series of components/functions.
I figure you could do something similar with this. Create a module for navigation, one for description, one for inventory, one for...
This approach makes sense to me. Obviously, you need to be careful not to over compartmentalize your code and make it a collection of 2,000 10-line scripts. | [reply] |
Re: Difficulty Abstracting
by Marcello (Hermit) on Jan 13, 2002 at 02:56 UTC
|
A good programming practice is always to keep to user interface (UI) separated from the program itself. Try developing the game with a minimal UI, and use a separated UI-class. When you want to change the UI, all you need to do is rewrite a new UI-class and leave the rest untouched.
Hope this helps.
| [reply] |
Re: Difficulty Abstracting
by synapse0 (Pilgrim) on Jan 13, 2002 at 03:41 UTC
|
Probably a good source of info on this would be a place where MUD coding is discussed. Back when I was coding MUDs there were several interesting discussions on game abstraction that could be found in the rec.games.mud.admin usenet forum.
--SynZero | [reply] |
Try lpc
by nufsaid (Beadle) on Jan 13, 2002 at 05:40 UTC
|
lpc is a coding language specifically designed for multiuser
dungeon (MUD) programming. You can check it and other options out at:
MUD FAQ
Joe.
| [reply] |
Re: Difficulty Abstracting
by dragonchild (Archbishop) on Jan 14, 2002 at 20:58 UTC
|
Every game can be played on a (sufficiently complex) table. Ok, so what's on the table? That's the "Board", or "representation of the game's state". This could be a map, actual board, or how the galaxy looks at a given point in time. Everything that changes the game's state goes through the Board's interface.
Now, within the Board, you have some number of "Piece"s. These are the things that are moved around on the Board. The only hierarchy allowed to touch a Piece is the Board.
Now that you have your gamestate, you need things that change the gamestate. Generally, this is either humans or computers. So, create a connection to some person and, if needed, a connection to some AI "process". These connections will have the same basic interface. Something along the lines of a SetupConnection(), GetMove(), DisplayBoard(), and EndConnection().
After that, it's just data structures to help you make your life easier. For example, if you were building a MUD, you'd have a Thing class. Then, Thing::Alive and Thing::Inanimate would be its children. Then, Thing::Inanimate::Weapon vs. Thing::Inanimate::Armor, and so on. These would be examples of a Piece hierarchy.
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. | [reply] |
Re: Difficulty Abstracting
by toma (Vicar) on Jan 14, 2002 at 11:49 UTC
|
| [reply] |
|
|
