New guy, foundation feedback

[Hellfish]

Hi. I'm the new guy mentioned in the subject.
For introductions, I'm a mid-twenties swedish programming nerd and I've been gravitating towards roguelikes lately, mostly Dwarf Fortress and DoomRL but also some(little) Nethack.

Now I'm trying my hand at actually programming one, and I could use some feedback on the basic structure of things, seeing as I've never actually completed a larger game than a breakout clone. This project is all done in C# with libtcod.net ,btw.

If you're so inclined, you can check out the source anonymously from SVN at http://hellfishemu.googlecode.com/svn/GuardianRL/Guardian Roguelike/
but here's the gist of things.

The grandmother of all-core of things is the StateManager object, which holds an object that inherits from the StateBase object. Every State can do stuff on entrance, in a mainloop and on exit, or queue up states that are supposed to follow it via static methods. Rendering and input processing are up to the states themselves.

Now, there are MenuStates and a QuitState, as well as the several Game States. The MainGameState is for when the player is in the (somewhat) standard top-down move-the-adventurer around mode. There is also the WorldMapState,  InventoryState(Soon),MagicState(Soon). All the gamestates share their resources through a singleton (which should really be an abstract object with static members,really) that has a Dictionary<string,object> in which all "Inter-State" resources are catalogued. (In the same vein, the statemanager has a Dicitionary of "Persistent States" that should not be new'd)

The World itself is represented in the WorldMap,Map and various Creature-classes (As well as item-objects soon). The WorldMap basically just contains all the Map's and the Map's contain all it's creatures (One Map = One Screen) For example, in one mainloop of the MainGameState, the state loops through all the creatures in the active map(How I wish I was an optimization wiz and could make that all the creatures in the active world..) and calls their AI() function, unless that creature is the player (Yes, the player is a creature like anything else.)


If you could discern anything from all that, what did you think? Can you more seasoned dev's foresee problems with this? Was it not clear? (Quite possible, it's very late here..)Is there a better way to do anything of the above? As for the story/setting/theme/hook, I have something quite big in mind, but that's way off in the future.

Cheers for reading!

[Z]

As far as I understand, these states are just for the user interface. From your description it looks needlessly complicated (are you going to create a new state for each small question the game will ask? along with the interstate relations?), why not just have methods which wait for the player input (and possibly call another methods, e.g. ChoosePlayerMove calls DrawWorldMap if the player is wanting to do just that)?

Since the player is just one of the monsters, "calls their AI() function, unless that creature is the player" is illogical, it would be more logical to call the method ChoosePlayerMove instead.

[Hellfish]

are you going to create a new state for each small question the game will ask?

Not necessarily, things like answering an NPC's question for instance could be done in the MainGameState by posting the question to the message log and setting a  'mode' variable, which the state's ProcessInput method heeds and, say only accepts y or n for input.

Since the player is just one of the monsters, "calls their AI() function, unless that creature is the player" is illogical, it would be more logical to call the method ChoosePlayerMove instead.

I don't quite follow. I have no way of telling wether a creature is the player other than the reference kept by MainGameState, the creature object themself doesn't know if they are a player(The AI creatures also use the Move<direction> methods for moving around,btw). (Reading back, that does sound kind of iffy...)

Thanks for the feedback!

[Z]

I meant that since both the player and monsters perform an action each turn, it would be logical to call PerformAction for both each turn, and for monsters this would mean AI, and for players this would mean UI. Depends whether you view the game as "first I move, then the monsters move in turns", or as "all creatures move in turns". The second one is more natural for me, and agrees with the "player is a creature" design, but both will work, of course.

[george]

I'm interested in the state structure too but I'm not sure what I would gain from it. Right now I have Game, UI, and Input parts that each have separate methods for whatever state the game is in at the moment. So if we're on the 'enter your name' at the beginning of the game, each of those parts is calling their respective method to control and display that. Are there additional advantages to states besides controlling program flow?

The basic AI/UI split seems sound, it at least works for me too . The player always goes first in their turn, but some turns the player doesn't get an action depending on its speed (likewise for monsters). I do call the player separately in the game loop, though, like:

if creatures_turn:
  player.input()
  everything_else.update()

[Hellfish]

Z: Actually, currently in the MainGameStates Main loop, it's all non-players first but that can be changed. If I decide to make creatures aware of wether they are the player or not the player could also be updated along with the rest.

george: I guess this would be a more OO and compartmentalized version of what you have. I've been taught to utilize the OO nature of C# in school, so I'm much more used to doing it this way, but apparently your way works too 

I'll be hammering out an AI test creature as soon as I finish a ViewMessageLogState. (Soon)