Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Feb 2012
Offline Last Active Feb 13 2016 07:45 AM

#5234801 Question about entity-component-system implementation for doors

Posted by on 14 June 2015 - 06:15 PM



I was building a game program that uses an "Entity-Component-System" type architecture and was wondering how you would go about implementing doors. In the program as it stands, there are the following requirements:


1. Components should be generic enough that you can form new entity types without a type of component for every type of entity (as that essentially defeats the purpose of the ECS architecture, which is to allow you to make all kinds of things with composition),


2. Components should contain only data, no code.


3. Systems contain all the code for the logic.


4. There is a messaging pipeline where the systems can send messages to each other.


Given this, I am wondering how you would go about implementing doors? It seems that doors require a state and changing that state changes the graphic displayed for the door. Right now, I have a GraphicComponent which stores a key to a graphical asset, and a PositionComponent to store the entity's position. There's also a PhysicsComponent which stores the physical properties of the entity. But if I add a StateComponent to store the door's state, then, when you change states, that has to update the GraphicComponent somehow, and also the PhysicsComponent to make the door passable -- this is a tile-based game, not one taking place in a continuous space. However, because of requirement 1, genericity, we cannot have anything too specific to the door in the StateComponent, but we must specify how to update the other components. But how do we do that without violating requirement 2 -- absence of code in the components? I have a "Finite State Machine" (FSM) object in my program, which would seem to be what I'd want to use, however it's meant to be general (I use it in the user interface to handle various user interface states, such as main menu, playing the game, etc.) so when you make one you specify code, not just data. It would seem it would violate requirement 2 to stick that in the StateComponent.


What is a good way to do this? Should I just use the FSM and see if I can get away with it?


And it gets worse: what happens if you want to have the door be jammed by something else sitting on the door's tile when it's open? Then there needs to be something to sense the object is present. How can you do this without a dedicated system for doors which would violate condition 1?

#5086964 Programming origin of (bug? feature?) in old game ("Duke Nukem 3D")

Posted by on 18 August 2013 - 12:28 AM

I just got the code from the 3D Realms website and had a look. I believe your hypothesis is in fact correct.


I discovered the following code segment in the routine "processinput" in PLAYER.C:

    psect = p->cursectnum;
    if(psect == -1) /* hypothesis: this means "out of range" sector */
        if(s->extra > 0 && ud.clipping == 0) /* "clipping == 0" = no clipping? I note this variable is modified by the noclip cheat */
            quickkill(p); /* kill the player */
        psect = 0;

(Comments added by me -- this code has pretty much no comments)


It looks to be exactly what you said. To check if the player is out of range, and kill them if that is the case. A failsafe, just as you thought.


There also appear to be a few other checks that look like this one.


Thanks for the suggestion!

#5086955 Programming origin of (bug? feature?) in old game ("Duke Nukem 3D")

Posted by on 17 August 2013 - 10:59 PM



(I'm posting this here because to me it seems game-programming related, but if you think it should be elsewhere, you can move it)

I saw this on Wikipedia:





No-clipping can conflict with other elements of the game. For instance, in Duke Nukem 3D, and the Commander Keen series, having no-clip and walking outside the level area causes death, and if the player has god mode activated the game will be left in an infinite loop or crash due to the way god mode was implemented. In most source ports for Duke Nukem 3D, this problem is corrected and it instead behaves more like Doom.



I'm curious about this. Now, Duke Nukem 3D's source code has apparently been released under free license (GPL), so I suppose one could dig through it and/or run experiments, though I don't feel like doing it right now. What would cause this phenomenon (namely that going out of the level in "noclip" mode kills you), from a programming point of view? As it doesn't seem at first obvious that this kind of thing would occur.