What are the rules for constructing a deterministic finite automata in the form of a diagram? My professor explained by examples, but I am not exactly sure what rules must be followed by all diagrams. Any help is appreciated, thanks!
Off the top of my head, in a DFA, these are the main rules, (terms specific to DFAs are in double quotes):-
each "state" must have a "transition" for each "input" defined in the DFA
so this means, that a transition must be defined for every input being considered in a dfa, for a state, so that one knows where to go from that state for each input.
each "state" can have only ONE "transition" for each "input"
well this rule is pretty self explanatory, so if you have already defined a transition for an input for a particular state, don't create another transition for the same input from the same state.
Yeah these are the ones i remember. Hope it helps. Further these points can be used to differentiate a dfa from a nfa. Other simple rules for drawing would be :-
make a start state, indicated with arrow pointing towards the state
have at least one final state, indicated with concentric circles to draw the state boundary
draw the transitions as arrows
mark all the transitions with their respective input symbols
Related
I'm modifying the vehicle routing Optaplanner example. Vehicles are replaced with individuals who have to travel around the city, but they can do so using different modes of transportation. So I have an attribute on the anchor (Vehicle in the example, Employee in my modified code) called modeOfTransportation.
When calculating the arrival time using the custom shadow variable listener from the example, I want to take the mode of transportation into account of course. But, when Optaplanner starts initialising my planning entities (consumers), it seems that they at first are not connected to an anchor. So I can't get my mode of transportation, and everything breaks down.
Any ideas on how to proceed?
Below is what I want to accomplish.
shadowVisit is my planning entity, shadowVisit.getEmployee() should give me the anchor.
Doing a shadowVisit.getEmployee()==null check seems to hang the entire solving process.
arrivalTime =
previousStopDepartureTime.plus(
shadowVisit.getLocation().getDistanceFrom(
shadowVisit.getPreviousStop().getLocation(), shadowVisit.getEmployee().getModeOfTransportation())
OK, so I figured out what the issue was.
My problem is overconstrained, and I implemented a dummy employee as the solution (see optaplanner: modifying vehicle routing to let customers be not served)
I had not set a modeOfTransportation for my dummy, causing the null pointers. Sometimes is just good to write down a problem, makes you think hard enough to solve it!
Thank you very much for your input Geoffrey
That's strange, because the chain principles guarantee that every chain has an anchor (see below).
Maybe your #CustomShadowVariable's sources attribute doesn't include the anchor shadow var, and your custom variable listener is called before the anchor shadow variable listener is called.
OptaPlanner guarantees that it will call one type of variable listener for all domain classes before calling the next type. The order of those types of variable listeners is determined by that sources attribute (see second image).
I would like to use a Finite State Machine to handle Entity states in my game. Specifically, for the purpose of this post, I'm going to refer to the Player entity.
My Player is going to have states such as idling, running, jumping, falling, etc... and needs some way to manage these states and the transitions between them. In an OOP environment, the simplest solution was to make each state its own class, and have a method called handleInput take in input and determine if a state change should occur. For example, in the IdleState if either move_right or move_left occurred, the state would change to a new RunningState. This is easy and makes sense because the behavior of a state should be encapsulated in the state.
However, everything changes when you use a FSM in an entity component system. States are no longer objects (because that would go against the flexibility of a component system), but are instead different arrangements of components. The JumpState might have components like JumpComponent, AirbornMovementComponent, etc... whereas the AttackState might have components to represent an attack like SwingComponent, DamageComponent, SwordComponent, etc... The idea is by rearranging the components, new states can be created. The systems job is to simply handle these components separately, because the systems don't care about the state, they only care about the individual components. The actual FSM sits in a FSMComponent held by the entity.
This makes a lot of sense, except for when it comes to handling state transitions. Right now I have an InputSystem that looks for Entities that have an InputComponent and a FSMComponent and attempts to update the state of the FSM based on the current input. However, this doesn't work so well.
The best way (in my opinion) for the FSM to handle input is to have each state determine how it wants to handle input and how to transition to a new state based on that input. This goes back to the OOP way of implementing a FSM, going against the design of an ECS where components are simply data bags and systems do all the logic. In an ECS, the idea would be to have a system handle state transitions, but that gets complicated because every FSM might have different conditions to transition between states.
You can't simply state in the InputSystem "if the input is to move right, then set the state to running". That would be specific to the player, but may not hold true for ALL entities. If one day I decide to make an enemy controllable, the inputs that work for a Player wouldn't be the same inputs for an Enemy.
My question: How can I let my FSM be generic enough and flexible enough in an ECS to allow for various implementations of state transitions without having to do explicit if/else checks in the systems themselves?
Am I approaching this completely the wrong way? If so, what's a better solution for implementing a FSM in an entity component system?
Just riffing off of #fallaciousreasoning's post (and its subsequent comments).
Ash actually has two FSMs that operate at different levels.
First, there is the FSM operating at the Entity level that manages (entity) state transitions by changing the composition of components on an entity as you transition from one state to another.
And secondly there is the FSM operating at the Engine level that manages (engine) state transitions by changing the composition of Systems executed by the engine.
Combined they make for a pretty robust FSM.
The trick is to determine what type of transition you need to work with; one where 'data' composition drives transitions, or one where 'logic' composition drives transitions.
So armed with this new found knowledge lets reason about how this would work.
In more naive approaches to changing component composition, we'd use a number of 'tag' components, along with some lengthy switch statements (or if/else checks) to handle these changes in entity state, ultimately resulting in bloated Systems that do way more than they should. Ash's Entity FSM refines this and avoids those lengthy switch statements (or if/else clauses) by mapping a given component configuration to an identifier and providing a manager that can be used to trigger state transitions. This manager instance can be passed around as a property within a component OR it can be composed/injected as a member of a system.
Alternatively, taking the Engine FSM approach, we break out each bit of state specific logic into their own Systems, and swap them in and out based on the given (engine) state. This method is not without its drawbacks since the absence of a system will affect all entities associated with it. However, its not uncommon to have Systems dedicated to a single entity instance (for example, a player character) so this can prove useful in the right context. Come to think of it affecting entities globally via System swaps may be desirable in some cases as well.
( Note: If the scope of your logic modification needs to be more narrow, you can restrict it to the System without involving the Engine FMS. This can be achieved by implementing the State pattern within a System where the system can change its behavior by delegating to different sub-systems based on state.)
I've seen some ECS frameworks label System compositions as 'Phases', but they fundamentally act as FSMs where the ECS engine processes entities using different sets of systems associated with a given phase.
In closing, data composition is just one half of the equation; how you compose your bits (or blocks) of logic is just as important when trying to implement a FSM within an ECS.
The ash framework has quite an interesting approach, the author writes about it here
He takes a similar approach to the one you were suggesting, arguing that an entity's state is dependent on the components that make it up (which in turn, determine what systems process the entity).
To make managing the state transitions easier, he introduces a FiniteStateMachine class, which tracks what components are required for an entity to be in various states.
For example, an enemy AI might be in a patrol state if it has a Transform and Patrol component, so he would register that information with the FiniteStateMachine
var fsm = new FiniteStateMachine(enemyEntity);
fsm.CreateState("patrol")
.WithComponent(new Transform())
.WithComponent(new Patrol());
When the Finite State machine is told to change the state of the entity, it removes and adds components to get to the desired state. Any system that needs to change the state of the entity just needs a reference to the finite state machine (something like fsm.ChangeState("patrol")).
He's also released the source code for it, which you can find here (it also explains it better than I ever could) and there's a practical example in the basic asteroids game here. The code is in ActionScript (I think) but you should be able to decipher it without too much difficulty.
I think - as I googled around, searched stackoverflow, and didn't find a clear answer - we need to clarify for the future: what is the exact scope of glEnableVertexAttribArray?
What do I mean exactly? Well, we know: Uniform state is bound to the shader program. So calling glUseProgram(X) (X > 0) will also set all used uniforms to either their default value (except on ATI), or the value we provided earlier via glUniformXXX() when that same program was active. So my answer to my question like "what is the exact scope of glUniform" would be "every use of one specific shader program".
Now I have the situation that a Mesh may consist of multiple sets of buffer objects. The pseudocode of rendering looks like this:
mat = mesh->getMaterial;
mesh->overrideUniforms;
mat->prepareGL; // call glUseProgram, update changed Uniforms, bind textures
mesh->render;
Now mesh->render obviously deals with binding Attributes and drawing. In case a mesh has multiple sets of buffers, it'd look like that (assuming each buffer object set contains all data for all attributes/one render pass):
for_each(set_of_bufferObjects)
bindBufferObjects
for_each(Attribute)
glEnableVertexAttribArray
glVertexAttribPointer
glDraw
If the scope of enableVertexAttribArray was f.e. "every use of program X", I could spare those glEnableVertexAttribArray calls, as long as I enabled the array before (when program X was in use for the first time).
If on the other hand the scope was "during one specific program use", I could set them up once within mesh->render and then forget about them. This would particularly explain why I don't suffer side-effects from not disabling any VAAs.
So is anybody out there enlightened to know which piece of GL state the glEnableVertexAttribArray belongs to?
P.S.: I'm explicitly asking for gl/es 2.0, as there are no VAOs by spec! So please don't answer "just use VAOs".
This state is global. Not related to the program state at all.
Edit: I just noticed the last paragraph of your question. So to the original poster, please ignore the part below, since you did not want to hear about VAOs. ;) I'll leave it there, just in case it helps somebody else.
Full OpenGL, as well as OpenGL ES 3.0, have an additional object type called Vertex Array Object (often abbreviated as VAO). This allows you to store all the setup state for a given set of vertex buffers in an object, and switch to the set of state with a single glBindVertexArray call. If you use this feature, the scope of the state becomes the VAO.
My goal is to implement a (very simple) strategy game.
For the moment, I'll start with the map and two characters (I want the terrain to affect them differently) to experiment with pathfinding
The problem is that I have very little or no experience in object oriented design. I've used C++ classes before, but it was pretty straightforward: for instance, a class Graph implemented using an array of sets, with a method AStar. I didn't have in mind the concept of "several players".
I've thought of the following elements/classes: Game, Map and Character. Eventually a Pathfinder class.
First question: the position of a character is something the game should know? The map? or each character?
( I think the game should )
Second question: where would it be a good choice for a "findPath" method?
The Game?
Should a pathfinding algorithm be a method of Map? Something like map.findPath(character, srcpos, dstpos)
In the Character class? It makes more sense to do character1.findPath(map, srcpos, dstpos)
If I added a Pathfinder class, it would have to build its own representation of the map in order to determine the shortest path. And before doing that, it would have "to ask" the map how the terrain affects each player.
( I prefer the latter )
It seems the construction of an auxiliary structure (and asking the map) to apply, let's say, A* is something that I can't avoid.
Making things object-oriented is not a goal, it's a tool to be used when it makes sense. C++ is a language with lots of functionality that you can easily drown yourself with, so my advice is to keep things simple and easy.
This can mean keeping data and logic tightly together sometimes, or separating it completely other times.
First question: My initial reaction is that the character should know its position. But how you represent it with data depends on how you intend to use it, so both the game, the character and potentially also the map needs to know where the character is.
Second question: It depends on what the Map class is. Is it an object representing the map itself with necessary functionality exposed to the rest of your program, or is it a toolbox of functions that works on a simple data representation of the map?
If the Map class represents the map, it should have the necessary functionality exposed for a Pathfinder class to work on it (the pathfinding algorithm will need to have some additional data derived from the map, maybe temporary, maybe persistent).
If the Map class does not represent the map, you can put the pathfinding functionality in it. I think it would belong there in that case. If the pathfinding code causes the Map class to get too big, you should separate it into its own class anyway.
First Question: The position of the character should be a part of character itself (makes sense this way) for me.
Second Question: Finding a path logically cannot be a part of Map. Then you would be violating one of OOP principles i.e. Single Responsibility.
According to me you should create the PathFinder class. You can design it in this way
class PathFinder{
PathFinderAlgorithm algorithm;
//other required values according to your design
Path findPath(){
algorithm.apply();
}
//other required methods according to your design
}
PathFinderAlgorithm is an interface.
Using this you can also change the algorithm that you are using to find the path. Like if you in future need to find the longest path, all you have to do is create another class which will find the longest path and replace it in the PathFinder class.
I am working on a UI where the top level, logical grouping of display objects is 2-D or 3-D (variety of objects can be displayed either two dimensionally or three dimensionally.)
My language of choice does not allow for numeric characters to be the first character of an identifier (not actually aware of any that do) so I'm looking for a sane and legible prefix to use. I have thought of:
Ddd (e.g. DddObject or DdObject)
ThreeD (e.g. ThreeDObject or TwoDObject)
But both options look ugly and weird to me. Has anyone come up with a cleverer replacement to 2-D and 3-D object naming?
I have used 'TD' once (for 3D), but that's not very intuitive. I think you should use a 3D or 2D suffix where required, as suggested by SigTerm above, for example Point2D and Point3D. In other cases, like TriMesh, where it is obvious that the object is 3D, there is no need for either a prefix or a suffix.
I have personally found it best to avoid prefixes and suffixes as far as possible. Not only does this save you some typing effort, but the code also becomes more readable. Of course, the convention will also depend on the context. For example, if you have a scene object that can hold both 2D and 3D object, you would like to name it just 'Scene'. However, your problem might dictate having two separate structures for the 2D and 3D scenes, in which case you might want to name them 'Scene2D' and 'Scene3D'.
Using something more abstract is not good in the long term, because there is just no way that you can fully convey the logic behind the choice to others, and over time it will become more and more open to misinterpretation. For example, someone, someday might end up adding a class called Loggin3D, for log errors :)