At 3/3/13 01:32 AM, PrettyMuchBryce wrote: For some reason it seems like this board has gotten a bit snarky in the last month, which is ok, but maybe we're getting off track. I know you're all smart. You don't have to prove it with each and every post you make. Sometimes you can just chill out. That's why this is a lounge.

Eh, I spend the entirety of my offline life being polite to people and pretending they're not mentally set-back. I find it refreshing to come to the internet to rejoice in honest expression without being plagued by social conventions. In fact, just before you posted this, I was thinking about how the reg lounge seems to be getting a bit more fun suddenly, and how long it's been since I'd last seen comments like the one Glaiel made about 7th grade math.

in other words, I miss gust :P

At 3/3/13 01:39 AM, Toast wrote: Glaiel
I'm sure Glaiel is purposefully making somewhat hyperbolic statements that are not to be taken too literally. Stating how early or late a subject is introduced to students in school could never be a good measure of the difficulty of the subject either way. In this case though, I'm pretty sure basic trigonometric functions are taught somewhere around 8th grade, albeit not very effectively. I recall having stuff about inclined planes taught to us in physics class around the same time we learned about sine and cosine in math.

Slopes require knowing the equation for a line (y=mx+b), don't need to know anything about trig in there. It's fairly simple. Construct that equation for the slope, then plug y and x into it and see if y>mx+b, slope collision done.

At 3/3/13 02:54 AM, Glaiel-Gamer wrote: Slopes require knowing the equation for a line (y=mx+b), don't need to know anything about trig in there. It's fairly simple. Construct that equation for the slope, then plug y and x into it and see if y>mx+b, slope collision done.

Hmm, looks like all these years I assumed that a "slope" in terrain just means a change of level, be it linear or not. In that case I wouldn't even say you need 7th grade math to make something move up a slope, all you need is to understand how the coordinate system works in actionscript, and elementary intuition granted by mother nature that every kid should have.

At 3/3/13 03:04 AM, Toast wrote:

At 3/3/13 02:54 AM, Glaiel-Gamer wrote: Slopes require knowing the equation for a line (y=mx+b), don't need to know anything about trig in there. It's fairly simple. Construct that equation for the slope, then plug y and x into it and see if y>mx+b, slope collision done.

Hmm, looks like all these years I assumed that a "slope" in terrain just means a change of level, be it linear or not. In that case I wouldn't even say you need 7th grade math to make something move up a slope, all you need is to understand how the coordinate system works in actionscript, and elementary intuition granted by mother nature that every kid should have.

Well I assumed linear cause I figured he's doing tiles instead of shapeflag-based collision, since if he was doing shapeflag-based collision then you just get slopes for free by coding any collision at all...

Hi guys, some really cool replies I was surprised to see so many :)

So just for clarity, this will be a top down map, an isometric world like Habbo hotel. The A* I've nicked from my rather unsuccessful (and of questionable taste, please don't judge), London Riots game. The system is A* and calculates neighbors by casting a ray between each node. I've modified it with ease to be equal square tiles instead and it worked a treat.

I haven't looked into putting in multiple "levels" yet, but I thought I'd be cheeky and get you guys' opinion on it before I began. The main problem is the heuristic. If I simply add 1 cost if the goal is on another level, then the path is going to go underneath the tile, then realize the stairs are miles away and things will get very slow very quickly.

I was going to counter this by splitting into 2 paths. So if I'm on level 1 and the goal is on level 2 then first I will find a path to some stairs, then from there a path to the goal. This leaves the following possibilities unsolved though:
1) What if the nearest stairs don't access an area where the goal is (but some other stairs do)
2) What if the goal is on the same floor, but the shortest path involves going upstairs then back down again.

I will illustrate all of this in a crudely drawn diagram drawn in MSPaint :)

http://www.newgrounds.com/dump/item/fe9ee81a2b058e73af16d812 a7aa8a89

I think I'm going to solve this mostly via level design. Don't design anything that will have the problems that come with my "stairs first" approach. I don't think it would be that much of a restriction for what I have planned for this system.

Also RE: the fellow who said we should all post what we're working on; I've been on an MMO for the best part of 9 months now and it's finally starting to shape up :)

I learned about slope detection from here

http://acidleaf.com/as3-slope-detection-for-non-uniform-terr ains/

I've always thought slope detection was "OMG SLOPES so hard and advanced" but it's really easy, at least with that approach.

As for what I'm working on, I'm still stressed about getting an impressive demo to show for GDC. The "Best in Play" winners were announced. We didn't get anything, but damn there are some awesome looking games:

www.gdconf.com/events/bestinplay.html

Also, if you have an iPhone, search for "Move or Die" in the appstore.

I wonder if you experienced programmers feel the same... Maths in code seems to be much harder than maths in mathematical notation. I mean, lately, I've been working with nothing more than y=mx+c and very basic trig in Flash, but it was enough to give me quite a headache.

It was particularly frustrating when I scratched my head over Math.cos() for a long time, then realised the input was supposed to be in radians, not degrees. :(

At 3/3/13 08:47 AM, FlyingColours wrote: I wonder if you experienced programmers feel the same... Maths in code seems to be much harder than maths in mathematical notation. I mean, lately, I've been working with nothing more than y=mx+c and very basic trig in Flash, but it was enough to give me quite a headache.

It was particularly frustrating when I scratched my head over Math.cos() for a long time, then realised the input was supposed to be in radians, not degrees. :(

I think it's easier in code personally. Gives you the ability to see something visual every time you change your calculations. Maybe I'm just a visual guy :)

Cos and Sin always work in radians, just your calculator does that for you automatically. Understanding exactly how sin, cos, tan and expressing angles in terms of PI works is a must in my opinion. It's surprising how many people don't know why they work the way they do.

The little "try it" gizmo here explains it quite well:
http://www.mathsisfun.com/sine-cosine-tangent.html

At 3/3/13 09:19 AM, Rustygames wrote:

It was particularly frustrating when I scratched my head over Math.cos() for a long time, then realised the input was supposed to be in radians, not degrees. :(

I think it's easier in code personally. Gives you the ability to see something visual every time you change your calculations. Maybe I'm just a visual guy :)

True, it does, but seeing my mistakes visually and having no idea how I made them is much more frustrating.

Cos and Sin always work in radians, just your calculator does that for you automatically. Understanding exactly how sin, cos, tan and expressing angles in terms of PI works is a must in my opinion. It's surprising how many people don't know why they work the way they do.

The little "try it" gizmo here explains it quite well:
http://www.mathsisfun.com/sine-cosine-tangent.html

True, I probably should. :) I had some fun with drag-and-drop swf, but I think it was just explaining the unit circle definition of the trigonometric ratios.

I found this site quite useful: http://www.clarku.edu/~djoyce/trig/angle.html

At 3/3/13 07:51 AM, 4urentertainment wrote: I learned about slope detection from here

http://acidleaf.com/as3-slope-detection-for-non-uniform-terr ains/

I've always thought slope detection was "OMG SLOPES so hard and advanced" but it's really easy, at least with that approach.

I've read that thing, and it does seem pretty simple, but only in theory. :P I'm sure if I actually try it, it will take at least a month to get it right.

I tend to avoid this kind of thing, and that's why I make mostly 'board game' thingies. Maybe I'm just an incarnation of Ah Q.

I've also included a screenshot of what I'm doing. From this, three conclusions can be drawn:
1. I'm a noob.
2. I haven't been making much progress.
3. My doodling is horrible.

At 3/3/13 09:47 AM, PSvils wrote:

At 3/3/13 07:16 AM, Rustygames wrote: I haven't looked into putting in multiple "levels" yet, but I thought I'd be cheeky and get you guys' opinion on it before I began. The main problem is the heuristic. If I simply add 1 cost if the goal is on another level, then the path is going to go underneath the tile, then realize the stairs are miles away and things will get very slow very quickly.

You're over thinking this...I don't understand what your problem is, stair tiles are like any other tile, except it connects to tiles on another level. Done. Let A* do the rest of the work, and it'll always find you your path, if there is one.

Most of the efficiency would be lost unless the heuristic takes into account that level change. And since that all depends on where the stairs are it's not as straightforward as it may sound. You're right A* will solve the problem, I'm just worried about how quickly it will solve it :)

I left the source of this at work so I can't show you exactly what I mean until Tuesday, but I will update you all then :)

Also RE: the fellow who said we should all post what we're working on; I've been on an MMO for the best part of 9 months now and it's finally starting to shape up :)

Screenshots, or it doesn't count! :P

For some reason I don't really like showing early versions of something I'm working on on the internet; I prefer to make it a surprise :)

However in the spirit of getting back involved with the NG Flash forum community I shall show you something. It's an MMO card game. I know there are a few out there (about 3 or 4 popped up while this has been in the works!), but we've got a twist which I think will separate us from the rest. I'm having fun building it anyway, it's been a long time since I've built anything outside of my 9-5.

My concept art for the RPG that's mostly done in code that I found and artist for. He's better than I am, thankfully

It only had a few colors to choose from...

I'll post a screenie later of the other RPG that's like 95% done and HOPEFULLY coming out this month.

At 3/3/13 01:32 AM, PrettyMuchBryce wrote: I have a proposition.

i like the screenshot once a month thing. ill see what i can find later

At 3/3/13 11:14 AM, PSvils wrote:

At 3/3/13 10:51 AM, Rustygames wrote: Most of the efficiency would be lost unless the heuristic takes into account that level change. And since that all depends on where the stairs are it's not as straightforward as it may sound. You're right A* will solve the problem, I'm just worried about how quickly it will solve it :)

But what's so different about a level change? If there's a cost to it, you just add that to a stair cases tile cost. Like...I don't get what you mean :D You just give stairs a certain heuristic.

P.

And what would that certain heuristic be? :)
I'm using Manhattan for the heuristic at the moment, which obviously only works if you are on the same level.

I wish I had the source here, I would just knock it up again but I'm busy on other stuff today :(

This will honestly have to wait until Tuesday because I'm thinking it difficult to explain without the swf/code examples to back it up

At 3/3/13 11:21 AM, Rustygames wrote: This will honestly have to wait until Tuesday because I'm thinking it difficult to explain without the swf/code examples to back it up

Where's your amazing engine NC? Flying out there on a magic carpet in Pakistan?

At 3/3/13 11:40 AM, Toast wrote:

At 3/3/13 11:21 AM, Rustygames wrote: This will honestly have to wait until Tuesday because I'm thinking it difficult to explain without the swf/code examples to back it up

Where's your amazing engine NC? Flying out there on a magic carpet in Pakistan?

Oh god that's an old one. I can't even remember what that was about... An Inglor thing?

i've been following the math links :P

the "what are you working on?" sounds like a fun idea, but to be honest I can't effectively show what i'm doing ATM. It's a whole lot of backend/engine work with PHP.

uhh... Have some random numbers and two encrypted "test"s?

If anyone's interested, I seeded a blum blum shub with random.org for the numbers, and the tests are two different algorithms: one Rijndael-128 on NOFB mode and one GOST in ECB mode

At 3/3/13 11:21 AM, Rustygames wrote: And what would that certain heuristic be? :)
I'm using Manhattan for the heuristic at the moment, which obviously only works if you are on the same level.

I wish I had the source here, I would just knock it up again but I'm busy on other stuff today :(

This will honestly have to wait until Tuesday because I'm thinking it difficult to explain without the swf/code examples to back it up

I think I understand your problem now. You want to pathfind to x,y,level, but the game will go to the x,y of the current level since that's closer than x,y of the next level? I'd say from the start, check if the tile is on the same level. If it's not on the same level, pathfind to the stairs then pathfind from the entry point of the next level to x,y or to the next set of stairs and so on. Push the second path after the first one or however your code works.

Any of you have experience with loading data with the NG api? I don't wanna addChild their savebrowser component (have a custom one), but I don't see how else to get the savefiles.

Current game:

At 3/3/13 01:27 PM, MSGhero wrote: Any of you have experience with loading data with the NG api? I don't wanna addChild their savebrowser component (have a custom one), but I don't see how else to get the savefiles.

?

Iunno, do you need to use the NG API to save and load SharedObjects?

At 3/3/13 01:27 PM, MSGhero wrote:

At 3/3/13 11:21 AM, Rustygames wrote: And what would that certain heuristic be? :)
I'm using Manhattan for the heuristic at the moment, which obviously only works if you are on the same level.

I wish I had the source here, I would just knock it up again but I'm busy on other stuff today :(

This will honestly have to wait until Tuesday because I'm thinking it difficult to explain without the swf/code examples to back it up

I think I understand your problem now. You want to pathfind to x,y,level, but the game will go to the x,y of the current level since that's closer than x,y of the next level? I'd say from the start, check if the tile is on the same level. If it's not on the same level, pathfind to the stairs then pathfind from the entry point of the next level to x,y or to the next set of stairs and so on. Push the second path after the first one or however your code works.

Any of you have experience with loading data with the NG api? I don't wanna addChild their savebrowser component (have a custom one), but I don't see how else to get the savefiles.

Current game:

Bingo you got it. That's exactly the problem. Your solution is what I'm going to go for, but if you check my post with the shit MS Paint picture I drew, you'll see there are a couple of problems with that method too.

When I get my hands on the source I started on Friday I'll let you guys know what solution I came up with in the end.

By the way, it would be cool if people posted any working demos they might have. I would but the lobby system isn't done yet so it would be a pain

At 3/3/13 01:39 PM, egg82 wrote: ?

Iunno, do you need to use the NG API to save and load SharedObjects?

No, but I'm not using sharedobjs for this. The reference isn't as helpful as I'd like it to be; most of my understanding of the api comes from a readme that came with it. But it only covers loading by clicking inside the provided movieclip rather than getting the files without user interaction.

I have to respond to the awesome screenshots.

PSVils This looks really cool. I have heard of Ogre. What do you think of it so far ? I probably don't have enough time at the moment to give you the help you deserve. :[ I'll shoot you a PM if that changes, though.

FlyingColours Don't be so hard on yourself. This looks like a cool little strategy game. I don't think I could do any better. It looks like you're still prototyping. So have at it!

Rusty This looks absolutely epic. When do we get to play it ?

MsGhero I love the artstyle. Did you do the art? I have a soft spot for 16-bit lookin adventurey games with dialogue like that.

At 3/3/13 01:55 PM, MSGhero wrote: No, but I'm not using sharedobjs for this. The reference isn't as helpful as I'd like it to be; most of my understanding of the api comes from a readme that came with it. But it only covers loading by clicking inside the provided movieclip rather than getting the files without user interaction.

yeah, I want to say the NG API puts an encryption on the SO. For obvious reasons, we can't have the key.
well, either you're using SOs, URLLoaders, or AIR. Those are your options when it comes to saving data with AS3.

At 3/3/13 02:06 PM, PSvils wrote:

At 3/3/13 01:48 PM, Rustygames wrote: Bingo you got it. That's exactly the problem. Your solution is what I'm going to go for, but if you check my post with the shit MS Paint picture I drew, you'll see there are a couple of problems with that method too.

You get the estimated heuristic by getting the shortest distance, aka, you cycle through all staircases, get the distance from each staircase to your current point, and the distance to the goal on level 2 summed. The shortest distance between all staircases should be your estimated heuristic.
Then proceed as you normally would.
(The more levels you have between the 2 goals, the estimated heuristic calculation will get exponentially longer to calculate: level1Doors * level2Doors * ... * levelNDoors)

P.

It's a good plan. It still won't solve the problem I illustrated where you go up and then down again to get to the target fastest, but I think level design will be the easiest way to solve that. I'll try your suggestion and I expect that will yield better results that my initial thought of splitting the path into 2 for stairs. Thanks for the help dude, I'll let you know how I get on with it :)

At 3/3/13 02:58 PM, PrettyMuchBryce wrote: I have to respond to the awesome screenshots.

PSVils This looks really cool. I have heard of Ogre. What do you think of it so far ? I probably don't have enough time at the moment to give you the help you deserve. :[ I'll shoot you a PM if that changes, though.

FlyingColours Don't be so hard on yourself. This looks like a cool little strategy game. I don't think I could do any better. It looks like you're still prototyping. So have at it!

Rusty This looks absolutely epic. When do we get to play it ?

MsGhero I love the artstyle. Did you do the art? I have a soft spot for 16-bit lookin adventurey games with dialogue like that.

The card game itself is nearing completion, but there is a whole world of pain ahead with all the external API's (Facebook, Kongregate etc) and the "world" around the cards. I really hope to finally get this thing in the hands of the players in a month or two. Thanks for the compliment, I appreciate that :)

At 3/3/13 02:58 PM, PrettyMuchBryce wrote: Did you do the art? I have a soft spot for 16-bit lookin adventurey games with dialogue like that.

Ha...good one. I'll let the actual artist know you said that

At 3/3/13 07:16 AM, Rustygames wrote: I will illustrate all of this in a crudely drawn diagram drawn in MSPaint :)

http://www.newgrounds.com/dump/item/fe9ee81a2b058e73af16d812 a7aa8a89

I don't exactly see the problem here, try not thinking of the pathfinding visually like that and just think of it as a bunch of nodes connected together. If you need a heuristic just like, x distance + y distance + level distance*10. Play around with it, if its very unlikely that a path goes between levels then just consider transferring levels as a lot more expensive.

At 3/3/13 04:36 PM, Glaiel-Gamer wrote:

At 3/3/13 07:16 AM, Rustygames wrote: I will illustrate all of this in a crudely drawn diagram drawn in MSPaint :)

http://www.newgrounds.com/dump/item/fe9ee81a2b058e73af16d812 a7aa8a89

I don't exactly see the problem here, try not thinking of the pathfinding visually like that and just think of it as a bunch of nodes connected together. If you need a heuristic just like, x distance + y distance + level distance*10. Play around with it, if its very unlikely that a path goes between levels then just consider transferring levels as a lot more expensive.

It's one tactic, but that will encourage the path to get off the level as soon as possible which, as in the example with some "blocked" second level paths (where a set of stairs leads to a part of the right level which cannot reach the goal) could slow things down a lot. Depending on the size of the map and the level design this could be fine of course.

At 3/3/13 04:58 PM, Rustygames wrote: It's one tactic, but that will encourage the path to get off the level as soon as possible which, as in the example with some "blocked" second level paths (where a set of stairs leads to a part of the right level which cannot reach the goal) could slow things down a lot. Depending on the size of the map and the level design this could be fine of course.

I really don't think you'll run into any speed issues with this unless your map is like, 100 levels of 1000x1000. Is your goal static or does it move around a lot / does the map change a lot?

Also, increasing the cost of moving up stairs means it will check the stairs later, not earlier

At 3/3/13 06:03 PM, Glaiel-Gamer wrote:

At 3/3/13 04:58 PM, Rustygames wrote: It's one tactic, but that will encourage the path to get off the level as soon as possible which, as in the example with some "blocked" second level paths (where a set of stairs leads to a part of the right level which cannot reach the goal) could slow things down a lot. Depending on the size of the map and the level design this could be fine of course.

I really don't think you'll run into any speed issues with this unless your map is like, 100 levels of 1000x1000. Is your goal static or does it move around a lot / does the map change a lot?

Also, increasing the cost of moving up stairs means it will check the stairs later, not earlier

You said have a high cost for being on a different level. That would mean it goes up stairs earlier.

I don't know if you've used grid based path finding much in the past, but if you're using it every time the player clicks, and you're on say, a 25x25 grid (x2 levels), with minimum walls, the calculation times start to add up. Of course it will always find the path, I'm just pondering the quickest way to do that. Maybe I'm worrying too much

At 3/3/13 06:39 PM, Rustygames wrote: You said have a high cost for being on a different level. That would mean it goes up stairs earlier.

That would be high priority, high cost is the opposite.

also if 25x25x2 is causing noticeable slowdown for you, you might want to go take a look at hour you're using your data structures, since I can usually brute-force a tilemap that small without much performance cost at all.