I am trying to get my head around how to design the following system, which I think can be defined as a finite state machine:
Say we have a pile of 16 building blocks (towers, walls, gates) together forming a castle. The player can drag the blocks to 16 places on a floorplan and if done right they will see the whole castle. All towers (there's four of them) are equal so they can go on any of the four corners. Same goes for some of the walls.
All in all there are 16 spots on the floorplan where you can put a building block and each of the spots can have 17 "states": empty + either one of the 16 building blocks. Doing some maths this leads to 17^16=a LOT of combinations.
The program starts with an empty floorplan and a pile of building blocks. It should then show a message like "build your own castle, start with the tower". When the user places a tower correctly, it should say "well done, now build all four towers". You get the idea.
Problem is: there are so many things a player can do. Put a block at the wrong place, remove a block, correctly put walls or towers all over the floorplan ignoring the directions given to them, etc.
It would be awesome if I could avoid having to use thousands of if-then statements to decide wether I should take the next step, show an error message or go back to the previous step based on what the player is doing.
How would you describe the NEXT, PREVIOUS and ERROR conditions for every step of the building sequence? Are there any design methods for this? Thanks a lot for your input.
Try to do this declaratively. Define an enum (or possibly classes) describing the kinds of blocks. Define and construct a 4x4 2D array describing the sets of permissible kinds of blocks in each position (implement the sets as lists, bitfields, whatever suits you best). Whenever a player tries to place a block in a position, check whether it is permissible against the 2D array. If you want to have particular messages for a position being correctly filled in, also put those in the same an array.
I don't know if a FSM is really what you are after: what kinds of sequencing constraints are you looking to verify? Does it matter whether towers are built first? From the rest of your description, it sounds like the above goal state description would be more suitable.
Related
I'm trying to accomplish the following behavior:
I have a continuous stream of symbols, part of which is pilot and part is data, periodically. I have the Correlation Estimator block that tags the locations of the pilots in the stream. Now, I would like to filter out the pilots such that following blocks will receive data only, and the pilots will be discarded by the tag received from the Correlation Estimator block.
Are there any existing blocks that allow me to achieve this? I've tried to search but am a bit lost.
Hm, technically, the packet-header Demux could do that, but it's a complex beast and the things you need to do to satisfy its input requirements might be a bit complicated.
So, instead, simply write your own (general) block! That's pretty easy: just save your current state (PASSING or DROPPING) in a member of the block class, and change it based on the tags you see (when in PASSING mode, you look for the correlator tag), or whether you've dropped enough symbols (in DROPPING mode). A classical finite state machine!
I want to check what is the definition of «iterative» in expansion regions in activity diagrams. For me personally this was never a question because I understand it as letting me do a For loop, e.g.,
For i=1 to 10
Do-Something // So it does it 10 times
End For
However, while I was presenting my UML diagram to an audience, an engineer team leader (not a UML maven) objected against the term ‘iterative’, because he understood ‘iterative’ to mean an 'iterative process' such that each step improves a result. I am also aware of this definition, but I assume the UML definition is not that, but rather means a simple For-Loop.
Please confirm that the UML definition of «iterative» and iteration is like a simple For-loop. Or otherwise, if so.
No, it has a different meaning. UML 2.5 states in p. 480:
The mode of an ExpansionRegion controls how its expansion executions proceed.
If the value is iterative, the expansion executions must occur in an iterative sequence, with one completing before another can begin. The first expansion execution begins immediately when the ExpansionRegion starts executing, with subsequent executions starting when the previous execution is completed. If the input collections are ordered, then the expansion executions are sequenced in the order induced by the input collection. Otherwise, the order of the expansion executions is not defined.
Other values for this keyword are parallel and stream. You can guess that behavior defined in a parallel region can be executed in parallel. stream is a bit more complicated and you might read on that page in the UML spec.
The for-loop itself comes from the input collection you pass to the region. This can be processed in either of the above ways.
tl;dr
So rather than a for loop the keyword «iterative» for the region tells that it's behavior may not be handeled in parallel.
Ahhh, semantics...
First a disclaimer - I am not a native English speaker. Yet my believe both my level of English and IT experience are sufficient to answer this question.
Let's have a look at the dictionary definition of iterative first:
iterative adjective
/ˈɪtərətɪv/
/ˈɪtəreɪtɪv/, /ˈɪtərətɪv/
(of a process) that involves repeating a process or set of instructions again and again, each time applying it to the result of the previous stage
We used an iterative process of refinement and modification.
an iterative procedure/method/approach
The highlight with a script font is mine.
Of course this is a pure word definition, not in the context of software development.
In real life a process can quite easily be considered repetitive but in itself not really iterative. Imagine an assembly line in a mass production factory. On one of the positions a particular screw/set of screws is applied to join two or more elements. For every next run, identical set of elements the same type and number of screws is applied. There is a virtually endless stream of similar part sets, each set consisting of the same type of parts as previously and requiring the same kind of connection. From the position perspective joining the elements is a repetitive process but it is not iterative, as each join is applied to a different set of elements - it does not apply to those already joined.
If you think of a code, it's somewhat different though. When applying a loop, almost always you have some sort of a resulting set impacted by it and one can argue that with every loop step that resulting set is being further changed, meaning the next loop step is applied on the result of the previous step. From this perspective almost every loop is iterative.
On the other hand, you can have a loop like that:
loop
wait 10
while buffer is empty
read buffer
You can clearly say it is a loop and nothing is being changed. All the code does is waiting for a buffer to fill. So it is not iterative.
For UML specifically though the precise meaning is included in qwerty_so's answer so I will not repeat it here.
I am creating a 3-D game with a cave as the main environment. The cave is made of a large number of ring segments, one attached to the other, thus creating a currently small tunnel system.
If the Player is inside the cave, only a small part of the segments are visible. I am figuring that actually hiding the not-visible segments could save a lot of gpu time, which I need for other objects like buildings or enemies.
So what I try to do first is hiding the entire cave and then unhiding the visible segments by turning ‚node.isHidden’ true and false.
The particular nodes are being found and accessed by their names: ‚Node.childnode (withName: „XYZ003“, recursively: false).isHidden = true‘ (or false).
It works to the point where the segments are unhidden, but once I am trying to hide a previously unhidden segment, the renderer crashes with an EXC_BAD_ACCESS.
Doing the hiding on a hidden object (of course useless, but helping to understand the problem) is fine, so is unhiding unhidden segments.
Following the hint of another thread, I moved the routine into the renderer delegate so not doing the switching during the wrong time, but instead during the phase in which such changes are supposed to happen, but this did not help.
As an alternative, I did the hiding (and unhiding) by SCNActions, but I received the same result, which really puzzles me, as this would be kind of the ‚official way‘ to do it...
I also played around with the ‚recursively’ boolean, getting the same outcome (works for unhide, crashes on isHidden = true).
Then I tried to change opacity or other properties of the nodes - which worked perfectly. On the other hand, trying to remove the nodes from the parent resulted in the mentioned crash as well.
I need this to work, because older hardware could never cope with several thousand nodes (trying this, the frame rate dropped to 10fps, even without enemies around). And newer hardware might break down once the enemies appear...
My thinking is that the pointer is somehow messed up by the first unhiding (and hence the BAD_ACCESS error), so maybe an additional bonding (often seen with spritekit-routines) or another way to get the node-pointer could be the solution. On the other hand, if the pointer is broken, why can I still access all other properties? Maybe it‘s the subnodes that cause the problem - everyone of the nodes has 20 subnodes, which are supposed to change visibility, too.
Did anyone come across this behavior before me? I could not find anything during my google-research...
Hiding and unhiding nodes frequently is typically not a problem by itself. You can hide a main node and any sub-nodes of the main node will automatically hide themselves, so you shouldn't have to loop them individually.
I'm not an expert debugger and don't know your skill level, but BAD_ACCESS can mean that you tried to send a msg to a block of memory that can't execute the message or whenever the app tried to deference a corrupt pointer. Search "What Is EXC_BAD_ACCESS and How to Debug It" for a decent tutorial on some options for dealing with it.
I do my changes in the render delegate as well, but depending on the number of changes and how long they take, I sometimes use timers to control the amount of changes that can be made in a certain amount of time. That way, and after some adjustments, I'm pretty sure that I'm not bogging it down to a point where it just spirals out of control.
Structure can matter - personal preference, but I try to setup an array of classes that create individual nodes (and sub-nodes) and therefore have direct access to them. That way I'm not iterating through the whole node structure or finding nodes by name. Sometimes a lot is going on before I really have to make a modification to the node itself and so I can loop through my array of classes, check values, compare, etc. before taking action that involves the display. That also gives me a chance to remove particle systems, remove actions, set geometry = nil and update logic counters when I need to remove a node.
I'm sure opinions vary, but this has worked well for me. Once I standardized the structure, I just keep repeating the pattern.
Hope that helps
OK, I have this chess app built with bitboard and I want to check if a given move put the opponent pieces in checkmate.
Verifying a check situation is easy. You build the bitmask of the enemy pieces' attack and you AND that with the bitmask of the opposite king, if the result is not zero, you have a check.
But what about check mate? A checkmate is something that will happen after the check. I mean, I move a piece, the app detects that the move generated a check. Then how do I know if this check is a check mate? Do I have to generate all possible bitboards for all possible plays of the opponent and check if there is a move that can remove the king from check? This not appears to be practical. Is there another way?
I don't think there is any other way. The final algorithm to me looks like:
Obviously, firstly check if by moving the king the opponent may run away from the check.
For each opponent's piece check if it is "forked" (that means that by moving it the opponents clears the way for any other check). Just "remove" it from the board and see if after that a new check is created.
If it is not forked: check if by moving that piece the opponent may block the check condition. This is done by intersecting two subsets of cells: one is a set of cells, where the opponent's piece may move, the other is a "line" between the opponent's king and the figure that attacks, and, therefore, "checks" it.
If these subsets intersect and the condition in the second step is passed - looks like the current situation is not a checkmate.
If there is no figure that is not forked AND can block the check - the situation is a checkmate.
I currently have two nodes in use, one of which is a boat (polygon) and the other a straight vertical rectangle. The boat needs to be a polygon so that it can be hit via projectiles, however this causes me problems when it collides with the vertical rectangle due to the many sides it's coming into contact with. Hence a piece of code I want ran only once is instead ran multiple times.
Is there anyway to make the collision detection only function for the first contact so that it doesn't repeatedly call?
I'm aware of setting the categoryBitMask to 0 however doing so renders the boat unable to be hit by anything else- something I don't want. Additionally I considered using a boolean variable to only run the code once whilst the boat is passing through, however as previously mentioned, due to the different sides, the code think it's passed through when in fact it's just hitting another side of the boat.
I don't have much code to show here other than setting physics bodies so I don't think it's necessary, but inside didBeginContact() I'm using a categoryBitMask comparison to check for collisions.
I may have not explained this very well, in which case I apologize, my English is not the best!
If anyone can help, it'd be much appreciated, thanks.
You can combine the individual physics bodies of your ship into a single body with
+ (SKPhysicsBody *)bodyWithBodies:(NSArray *)bodies
and then test for contacts with the composite body instead of the individual components.
If you are subclassing your node then simply create a BOOL property for it.
BOOL alreadyHit;
If you are not subclassing, use the SKNode's userData dictionary and create an entry for the same.