I think a potential is to have an isInvalid instance variable which defaults to false. When this is true, it does not need to repaint the wall (e.g. scan and pick the animation), when it is false it indicates it needs to. You can programmatically set it to false if you need to repaint a wall for some reason (e.g. opening a passage).

You could then have something like

SP_001 Is on Screen:

SP_001.isInvalid is set:

Set SP_001.IsInvalid to False

(Scan and reset animations)

Might be better as a sub condition and the other way round - you'd have to experiment to find out.

Have a look at my asteroids source in github - the page http://myconstruct2dev.blogspot.co.uk/2 ... roids.html decribes it.

You can't really. It's mathematics.

The simplest way of doing it is probably to calculate where it ends up, then get the nearest fielder to that end point to move there, catching it if the ball is off the ground just before it lands when it rolls. This works quite well for cricket, but cricket is different in that a lot of shots are along the ground anyway, and it means a fielder cannot intercept the ball on its way to the target area.

Pretty much as you say

Enemy.OnDestroy:

System.compare2Values random(0,1) < 0.6 : (Action 1)

Else : (Action 2)

C2 is mostly event driven ; so it isn't really "if enemy destroyed" - it's actions that are executed when the enemy is destroyed.

You can improve the inertia thing using the standard velocity equations in 3 directions - it will be near enough. You only need precision for flight simulators (and then they are just better approximations)

It is quite complicated. You have a straight line which is the ball trajectory after hitting it and you want the shortest right angle distance to that line, but eliminating anything that isn't catchable (e.g. above about 7-8 feet off the ground). There are probably some maths equations online that will solve this.

You can probably break it up into approximations. Standard equations will generate the trajectory of the ball from the impact of bat on ball and you can calculate it every couple of metres or so, working out if the fielder (do the basemen chase the ball ? English !) can get to that point in the elapsed time.

The problem is a human instinctively knows whether they can catch or get a ball or not, or someone else is better placed to do so.

Having written several cricket simulators over the years (a similar hit bat with ball and fielders game popular in the UK and other countries) it is very difficult to realistically simulate a swinging bat versus a moving ball accurately. Baseball is worse because the bat is round. Generally you cheat Most games rely on lining up and timing to determine where the ball is hit. Accurately simulating a pitchers behaviour "trying to trap a batsman" is even worse.

The thing to do is make it fun. Stick Cricket for example is absolutely awful as an accurate simulation of cricket. But its fun.

Someone from India (play cricket a lot there) asked me about this professionally, how do you accurately simulate the effect of bat on ball ; I suggested they don't, make it approximate, make it fun.

If your game or app or whatever is accessing and updating data used in local storage with any frequency it is probably better off in a cache - unless it is multiplayer and more than one person is updating it of course. Once read into a dictionary it can be accessed immediately.

Probably you shouldn't use LocalStorage like this. Think of it as a distant store with very slow connections, you don't want to be sending stuff back and forwards all the time.

Practically I would load a single item at the start and save it back (say) at the end of each game, with all the data json encoded using a dictionary.

Okay. I think I've fixed it, basically see http://studio2.org.uk/c2/working.capx. Somewhat butchered so you might want to use it as a basis

After a lot of experimenting getting nowhere I remembered I had a similar problem in (of all things) Frogger, where I was figuring out continous sprites making up logs and turtles. The problem, I think is when you do xxxx overlapped with xxxx at offset(a,b) it gets mixed up about which xxxx you mean. Inverting this (hence looking for failures and the 15-VA_BITWISE) seems to crack it, along with the foreach action. It doesn't seem to cope well automatically - if you take the foreach out, it doesn't work.

The problem with this is that it does this on every frame which is a bit heavy on the processor, you may want some sort of invalidate flag in SP_001 so it only picks ones it hasn't already done, if you change an edge for some reason you can mark it invalid.

Also, you were using self.x-16,self.y in the offset, when it should have been -16,0 (because it's an offset ), I didn't realise for a while.....

I'm not totally clear what's happening here - you are creating this dungeon and then you want each path square in it to be decorated differently depending on what's immediately around it ?

My instinctive reaction here is you have a sychronisation problem. Would it be better rather than to try to do everything at once, to split it into two very seperate sections of code - firstly build your paths without any edging effects (e.g. the maze builder bit) and then check the directions for each open path to see which decoration to use. It looks like you are trying to do both at once which strikes me as asking for trouble You could put the two parts in seperate source files which would maintain seperation.

There's a lot of sprites in this as well, but your proc. dungeon is not that densely packed in terms of 'open paths'. It may well be worthwhile using a tiled background for a lot of the default stuff. I appreciate the need for it not to look too cloned, Walls that can blow up etc. could be created dynamically on a seperate layer on top.

You are probably mixing the order up. The difference between webstorage and localstorage is you have to wait for responses using events. It can't be thought of like you do an Array etc., it's asynchronous. It's a bit like talking to someone over a very bad phone line.

If you look here http://myconstruct2dev.blogspot.co.uk/2 ... roids.html and the github link on the page there is a game where it definitely does work <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";-)" title="Wink"> and it's a very simple implementation

Hi. I came across this by accident and I have done three (?) of the four ; Pacman, Galaxians and Frogger ; see my blog at http://myconstruct2dev.blogspot.co.uk/ ; I have been cloning (ish) games as a learning experience in C2.