Sprite index.

Isn't that "for each" + loopindex = to 0, 1, 2, 3, etc same thing? Unless I'm missing something.

Are you using separate animation angles? Are you trying to make the shadow based of a fake light source? Why do you need to make the character bigger? There is a drop shadow effect as well as a plugin (those attach to the sprite). I think that's what you are looking for. You want the shadow to move in the direction the player has, but I don't quite see why you would need to do that. I use math to move a shadow in 360 on the floor of the character based on the pseudo light soruce. The description sounds like you want to do something else with the shadow.

> Because keeping everything in a single .exe is bad.

> hy is that?

nly thing I can think of is to make quick updates to the game without making users redownload entire exe. But single exe seems more safer? From what Ashley mentioned in the past, the events are hard enough to figure out for cheaters. I'm not clear on any other reason to separate the resources.

"Extended state machines can apply the underlying formalism to much more complex problems than is practical without including extended state variables. For instance, suppose the behavior of the keyboard depends on the number of characters typed on it so far and that after, say, 1,000 keystrokes, the keyboard breaks down and enters the final state. To model this behavior in a state machine without memory, you would need to introduce 1,000 states (e.g., pressing a key in state stroke123 would lead to state stroke124, and so on), which is clearly an impractical proposition. Alternatively, you could construct an extended state machine with a key_count down-counter variable. The counter would be initialized to 1,000 and decremented by every keystroke without changing state. When the counter reached zero, the state machine would enter the final state.

In extended state machines, a change of a variable does not always imply a change of the qualitative aspects of the system behavior and therefore does not always lead to a change of state.

The obvious advantage of extended state machines is flexibility. For example, extending the lifespan of the �cheap keyboard� from 1,000 to 10,000 keystrokes would not complicate the extended state machine at all. The only modification required would be changing the initialization value of the key_count down-counter in the initial transition.

This flexibility of extended state machines comes with a price, however, because of the complex coupling between the �qualitative� and the �quantitative� aspects of the extended state. The coupling occurs through the guard conditions attached to transitions

Guard Conditions

Guard conditions (or simply guards) are Boolean expressions evaluated dynamically based on the value of extended state variables and event parameters. Guard conditions affect the behavior of a state machine by enabling actions or transitions only when they evaluate to TRUE and disabling them when they evaluate to FALSE.

The need for guards is the immediate consequence of adding memory extended state variables to the state machine formalism. Used sparingly, extended state variables and guards make up an incredibly powerful mechanism that can immensely simplify designs. But don�t let the fancy name (�guard�) and the concise UML notation fool you. When you actually code an extended state machine, the guards become the same IFs and ELSEs that you wanted to eliminate by using the state machine in the first place. Too many of them, and you�ll find yourself back in square one (�spaghetti code�), where the guards effectively take over handling of all the relevant conditions in the system.

Indeed, abuse of extended state variables and guards is the primary mechanism of architectural decay in designs based on state machines. Usually, in the day-to-day battle, it seems very tempting, especially to programmers new to state machine formalism, to add yet another extended state variable and yet another guard condition (another IF or an ELSE) rather than to factor out the related behavior into a new qualitative aspect of the system�the state. From experience in the trenches, the likelihood of such an architectural decay is directly proportional to the overhead (actual or perceived) involved in adding or removing states (which relates to the actual strategy used for implementing UML state machines.)

One of the main challenges in becoming an effective state machine designer is to develop a sense for which parts of the behavior should be captured as the �qualitative� aspects (the �state�) and which elements are better left as the �quantitative� aspects (extended state variables). In general, you should actively look for opportunities to capture the event history (what happened) as the �state� of the system, instead of storing this information in extended state variables. For example, a state machine representing the behavior of a pocket calculator might use an extended state variable DecimalFlag to remember that the user entered the decimal point to avoid entering multiple decimal points in the same number. However, a better solution is to observe that entering a decimal point really leads to a distinct state �entering_the_fractional_part_of_a_number,� in which the calculator ignores decimal points. This solution is superior for a number of reasons. The lesser reason is that it eliminates one extended state variable and the need to initialize and test it. The more important reason is that the state-based solution is more robust because the context information is used very locally (only in this particular state) and is discarded as soon as it becomes irrelevant. Once the number is correctly entered, it doesn�t really matter for the subsequent operation of the calculator whether that number had a decimal point. The state machine moves on to another state and automatically �forgets� the previous context. The DecimalFlag extended state variable, on the other hand, �lays around� well past the time the information becomes irrelevant (and perhaps outdated!). Worse, you must not forget to reset DecimalFlag before entering another number or the flag will incorrectly indicate that indeed the user once entered the decimal point, but perhaps this happened in the context of the previous number.

Capturing behavior as the quantitative �state� has its disadvantages and limitations, too. First, the state and transition topology in a state machine must be static and fixed at compile time, which can be too limiting and inflexible. Sure, you can easily devise �state machines� that would modify themselves at runtime (this is what often actually happens when you try to recode �spaghetti code� as a state machine). However, this is like writing self-modifying code, which indeed was done in the early days of programming but was quickly dismissed as a generally bad idea. Consequently, �state� can capture only static aspects of the behavior that are known a priori and are unlikely to change in the future.

For example, it�s fine to capture the entry of a decimal point in the calculator as a separate state �entering_the_fractional_part_of_a_number,� because a number can have only one fractional part, which is both known a priori and is not likely to change in the future. However, implementing the �cheap keyboard� without extended state variables and guard conditions would be practically impossible. This example points to the main weakness of the quantitative �state,� which simply cannot store too much information (such as the wide range of keystroke counts). Extended state variables and guards are thus a mechanism for adding extra runtime flexibility to state machines[6]

Actions and Transitions

When an event instance is dispatched, the state machine responds by performing actions, such as changing a variable, performing I/O, invoking a function, generating another event instance, or changing to another state. Any parameter values associated with the current event are available to all actions directly caused by that event.

Switching from one state to another is called state transition, and the event that causes it is called the triggering event, or simply the trigger. In the keyboard example, if the keyboard is in the �default� state when the CapsLock key is pressed, the keyboard will enter the �caps_locked� state. However, if the keyboard is already in the �caps_locked� state, pressing CapsLock will cause a different transition�from the �caps_locked� to the �default� state. In both cases, pressing CapsLock is the triggering event.

In extended state machines, a transition can have a guard, which means that the transition can �fire� only if the guard evaluates to TRUE. A state can have many transitions in response to the same trigger, as long as they have nonoverlapping guards; however, this situation could create problems in the sequence of evaluation of the guards when the common trigger occurs. The UML specification[1] intentionally does not stipulate any particular order; rather, UML puts the burden on the designer to devise guards in such a way that the order of their evaluation does not matter. Practically, this means that guard expressions should have no side effects, at least none that would alter evaluation of other guards having the same trigger"

http://en.wikipedia.org/wiki/UML_state_machine

So, yeah this is nice info for those that use state machines, but like most wikis it needs to be simplified.

Allow the user to choose. Make your app as rich as you want in graphics/resources then make lesser versions.

From looking at your screenshots you are using functions for all your changes. Functions are triggers outside of the eventsheet so they shouldn't be affected by tick speed issued. Every time a trigger is called is should work every time instantly perfectly, but maybe newt is right that because the functions work this way, the function is called and mid event execution the frames might be going out of sync. Is your cpu to gpu ratio low?. Functions haven't been explored by the community enough so people are bound to expereience there issuess. I always found functions calling ofther functions buggy in the past with crashes and such so at least the new builds aren't crashing on you.

Either way, I agree you definately need more information to be able to avoid this. It looks like the type of app you want to make would combersome without more info.

There was example here that used listbox to store all the x,y(could add states like shooting etc), but the link is gone, altho I think I have it on a pc somewhere or someone may have posted old example in uploads. However, this way is not very efficient but you can use short cuts like interpolation, getting the speed and angle of motion, and only adding new values when something changes.

Another request on this behavior.

You have conditions to compare distance on the path, but its only returning that value down to its decimal.

Would it be possible to get that value returned as an int?

int(value) ?

Hi, I haven't tested this behavior yet, I don't need the edit time paths. But is it ok to assume that I can just use normal math to set up the paths at runtime?

Transverse collision detection - when object was moving too fast in frame 1 and it skips over an object in frame 2 collision can be backtracked to check the previous frame positions and detect the collision doing the call.

Inheritance tree - parent-child objects to speed up cpu time among other things.

Better music plugin - DSP Effects

Play AVIs in the background.

Also:

For those that don't know what GGPO is, you can read this (first and"What's this rewind thing?" paragraphs. And the first few paragraphs here) for a quick understanding of what it is. This is what newer fighting game like "BlazBlue, Street Fighter 2 HD Remix, and the recent Marvel vs Capcom 2 release use". It basically keeps the clients in sync behind the scenes by rolling back frames in the game play. The is done while you can't see, so it feels more close to the real arcade experience. Here is a random online match of a game using GGPO

.

Now how would trying to use timedelta instead of fixed frames affect this style of netcode? I don't want to waste any time when it's time to convert to netplay. And if it doesn't work, I'd rather remake this specific game last in something else and finish offline only games. Thanks.

Jonathan5 I'm aware of Scidave's work and he's done enough for community already. Thanks for posting those links, so more people get a chance to see them. Hopefully, he or a dev could shed some light on this issue.

Are there any examples of some MMORPGs using it (not that I'm making a mmorpg btw). And can you say for certain that using a python library for networking will work well with a fast paced online action game with construct, and there isn't any reason why it shouldn't be fine. MMORPG in a 2D sense would probably mean 6-18 characters in a room cooperating. I should point out I'm talking about the quality of the network and not that it just works. Will it just depend on the programmer and there isn't any reason Construct and Python would conflict.

For those that don't know what GGPO is, you can read this (first and"What's this rewind thing?" paragraphs. And the first few paragraphs here) for a quick understanding of what it is. This is what newer fighting game like "BlazBlue, Street Fighter 2 HD Remix, and the recent Marvel vs Capcom 2 release use". It basically keeps the clients in sync behind the scenes by rolling back frames in the game play. The is done while you can't see, so it feels more close to the real arcade experience. Here is a random online match of a game using GGPO

.

Now how would trying to use timedelta instead of fixed frames affect this style of netcode? I don't want to waste any time when it's time to convert to netplay. And if it doesn't work, I'd rather remake this specific game last in something else and finish offline only games. Thanks.

Jonathan5 I'm aware of Scidave's work and he's done enough for community already. Thanks for posting those links, so more people get a chance to see them. Hopefully, he or a dev could shed some light on this issue.

Can't say I've ever really had anything against MS, they're doing their job and making more money. I do however, would like the best software/hardware available to always be on top so that technology/innovation and new ideas aren't bottlenecked. That said, the next OS I buy with be Win7.