Thursday, December 16, 2010

Coding - It's UML Time!

Sorry folks but...


IT'S UML TIME!


Note that most classes members are omitted and method signatures simplified.
They say that UML is worth over 9000 words...
...so I'll just throw random class diagrams at you.



1. Controllers 


2. AI

NCLASS
I used NClass for this. NClass is nice for doing C# class diagrams.
http://nclass.sourceforge.net/


End of uml time.

25 comments:

  1. SPAAARRTTAAAAAAAAAA!!!!!#!@$@ONE%1$#ONE#!#!1@!#!@$$*^$@##$@@!111!!!!@@$@#%^%ONE

    ReplyDelete
  2. Hmm, hadn't come across nclass before - cheers!

    ReplyDelete
  3. Is that a PLIF mutation I see? Damn I miss that comic

    ReplyDelete
  4. lulz

    Fairly standard actor class design. I have a question that could also be translated as a feature request, though.

    Do civilians exchange/share information retrieved from their memory 'sensor' ? It could lead to the basics of discussions like:
    1: 'hey i need ammo!'
    2: 'yeah i found some there, beware of X i spotted in the vicinity'
    1: 'thanks, if you need to rest, crash at that place'

    Maybe it's already in place, I've payed little attention to the survivors and I've yet to give 6.0 a real try (i'm caught in my own project).

    Also, i kinda like the idea of a hive mind when dealing with zombies. The Z.Masters could retrieve the sensor data from all the zombies in a given radius and in return each zombie in this radius may get their data from what the ZM has retrieved. This could lead to 'FUN' inducing events where a zombie (in the ZM's hivemind radius, but not yet in follow mode) spots you, it start yelling the info at the ZM horde, which soon start chasing you.
    Some loss of data could also be added, the farther is the zombie the less likely is for the data to be passed to the ZM. And it may require a few turns for before the info is passed to the ZM, so the player has a chance to kill the 'scout' before the ZM is aware of his location.

    cheers, sk.

    ReplyDelete
  5. Most RLs blends actors types and controllers into the same class. Eg: Skeleton extends Actor and contains both the AI and the abilities of a Skeleton.
    RS separate both. Actor is just a container for ActorModel (not shown here) and ActorController. That's why you can control a zombie for instance.

    Exchange of percept is possible but not done yet. Right now they just say "I saw this" "I saw that" but its just for flavor and for the player.

    I'm not too fond of ZM reading minds. The horde effect is achieve by zombies following ZM scents, sort of like insects do.

    ReplyDelete
  6. classes> yes i understand that, i also recognize this design from books I've read on the matter. I'm using something a bit more basic as i've no Controller of any kind. I just flag a citizen as player-owned, so its AI module isn't called when it's NPC's turn. If for a reason I wanted to change the PC, i change a boolean in the related actors plus a pointer in the UI interface.

    hivemind> Reading mind isn't the term i'd use, i was more thinking of communications through grunts and sounds [or comm/radio devices in a different setting], but yeah semantics. I was expecting this answer anyway, otherwise it would render most of the scent system redundant.

    ReplyDelete
  7. It's always interesting to discuss architecture and design. IMHO, when designing for a personnal project -that is not doing a team project- any architecture and code that allows you to do what you want is valid, no matter what "profesionnal" designers will tell you about patterns and what not.
    Anyway what is the theme of your game and in what language is it coded?

    ReplyDelete
  8. Indeed :)

    In fact i work on a few different things.

    The one I was talking about was Grand Rogue Auto, my roguelike project. It's coded in Delphi/Pascal, it's not already released but a first very basic alpha should be out during January. It's supposed to be a roguelike GTA, but the more i code, the more i realize it's going to be a city simulator. You'll find additional info here:

    http://grandrogueauto.blogspot.com/

    (tbh, it was supposed to be a zombie RL until i discovered your project when documenting myself on roguelike games. So, I switched my focus, and in the end I am glad as it will allow me to test a few AI related ideas i couldn't put in a zombie game).

    I'm also the author of AI scripts and plugin for a space opera game (called X3). Coded in their proprietary and cumbersome script system:

    http://afmodding.comli.com/

    ReplyDelete
  9. Its always nice to see the coding behind a game.
    A year ago I wouldn't have understood anything of this.

    ReplyDelete
  10. @SK GRA looks very interesting! Subscribed!

    ReplyDelete
  11. Thanks,

    Damn, now I'd better deliver! :p

    ReplyDelete
  12. Roguedjack, this is a bit of a silly request, but do you think it would be possible to add a "Spectate" mode to after-death options?

    In that you could just fly around as a ghost or follow individuals and see what happens to them etc?

    Without having to "play" the game so to speak?

    It'd just be so interesting following an NPC civilian around without having to worry about myself, seeing what they do on their own etc!

    Thanks if you take the time to read this comment!

    ReplyDelete
  13. The engine cannot handle a spectator mode.
    But.
    It can handle a follow mode, you see the world through an NPC eyes with a Borg-like system : the AI would issue actions for the character you are following.
    Note sure players would find interest in that though and there would have some UI issues to solve.

    ReplyDelete
  14. Alright, I can understand that, borg would work fine for me too but I agree with your assessment that most players would probably not be interested in that.

    Still, I figured it was worth throwing the question out there and I am grateful for the reply and looking forward to whatever new ideas you introduce into upcoming versions of RS!

    ReplyDelete
  15. Wouldn't it be possible to make an actor which is ignored by all other actors and can walk through them? It would be a spectator mode.

    ReplyDelete
  16. One thing wrong with this post:

    I don't know coding at all.

    ReplyDelete
  17. I understand the 'component entity / aggregate' design of the Actor, but could you perhaps explain the role of the ActorAction and the Sensor/Percept in more detail?

    I guess that the ActorAction is there so its easier to reuse behavior amongst classes that inherits from the BaseAi class and that it implements the actual action to take. And that the ActorAction uses the Sensor to check for Percept's which tells something about the tile where it's at..?

    ReplyDelete
  18. This is a standard Agent based AI process :
    Sense -> Perceive -> Think -> Act.

    Sense : empty, since game world is already formalized data (not a robot in realworld).

    Perceive : Sensors extract meaninful Percepts from game world data (eg: "i can see item X is at location L and it is turn T", which is what the Percepts properties are : Percepted=item X; Location=L Turn=T)

    Think : state & percepts fire behaviors.

    Act : ActorAction sent to the game.
    ---

    ActorAction is just a command pattern that sits between AIs and the game engine. Contrary to most games there is no actual logic in ActorAction concrete classes. All the logic is in RogueGame, ActorAction just encapsulates the intention if you will.

    ReplyDelete
  19. Just to add that :
    - Sensors are of course limited by the actor model (eg: FoV range, Smell %) they actually ask the game to compute the actor FoV etc..
    - "most game" as in "most OOP based game architecture".

    ReplyDelete
  20. I read some older post. I like the design but its basically the different AIBase classes calling methods on RougeGame, and the Sensors are like helper classes?

    ReplyDelete
  21. Sensors do the job of sensing. Different AIs will just use different sensors (eg: FoV, Smell). Encapsulating that role in a class allows nice stuff like the MemorizedSensor.

    ReplyDelete
  22. Kool. Btw. (off topic) I saw that you are using managed direct x. Isn't that a depricated api? Why don't you use xna instead? I guess for a rouge game, that doesn't need realtime graphics (60fps) you can do fine with gdi+ though.

    ReplyDelete
  23. MDX is deprecated but couldn't get SlimDX to work.
    XNA forces you into an update-render loop which I didn't want.

    ReplyDelete
  24. you can use xna in a winform which doesnt force a render loop.

    ReplyDelete