Ok: have to be logged in, and just flash export for now http://www.newgrounds.com/projects/games/1003479/preview

WASD/arrows + IJKL or controller
Space lets you enter houses (need to be fairly close to the door)
Enemies can't hit you yet, but their spells can (accidentally)
Shift changes your current weapon: sword, boomerang, bomb, spell
A couple of the drops don't do anything yet

If the rest isn't obvious or figure-outable, then that's something you should mention. The first group of enemies that you see are acting weird haha...

it's possible DCE removed some important things...but it cut the filesize in half so
waiting on a new haxe ui lib to mature before doing anything with its beta api

At 7/23/16 09:13 AM, OmarShehata wrote: I guess one thing I didn't really understand is what the next step was. If

Close()

doesn't guarantee that the socket closes right away, what do you do with your unit test then?

I'm glad you learned something, and thanks for the feedback. I should probably touch on this at the end. What I had to do was use a semaphore to ensure that all reading and writing had completely ceased before I called Close()

Ok: have to be logged in, and just flash export for now http://www.newgrounds.com/projects/games/1003479/preview

Nice. I really like the animation. I think there is a good foundation here for a game. I found a few bugs.

* One house had its door in front of a cliffside so it wasn't possible to enter it.
* Once upon exiting a house I got a black screen
* Once I bombed an enemy and died and the game froze. Possibly intentional for now ?
* I saw a couple enemies which seemed to spawn inside bushes and couldn't get out.
* When I threw the boomerang at a rock it passed through the rock on the way out, but on the way back it seemed to collide with it, or try to avoid colliding with it.

I think the sword is my favorite weapon, although I might play around with making the swing time a bit shorter to allow for some more strategic dodging and attacking. Just a suggestion though.

Overall looking good!

@PrettyMuchBryce do you have any suggestions for algos? Multiple enemies, one moving target, terrain can change a little, avoid grid-based-looking movement, some paths will be pretty tight fits, enemies can move in any direction (360 degrees). The issue now is that multi-raycasting from 5+ enemies is causing visible stutters, although I only do this once per .1 seconds so the stutters are a bit weird.

The most convenient route would probably be working with what you already have and trying to find the source of the performance problems, but if it's not possible another thing that came to mind was using A* with a dense collision grid. The nodes don't need to be the size of the visual tiles or entities. They can be much smaller. Entities which overlap multiple nodes would mark these nodes as occupied. If you're concerned about rigid looking paths you could look into path smoothing algorithms.

It's been a long two weeks. I'm exhausted. Vegas should be worth, though.

At 7/20/16 01:06 PM, Gimmick wrote: I should hope you got written authorization as well, lest it become a he-said she-said issue.

I haven't, I'm basically just going to keep everything encrypted like I have been and hope it goes well. If it doesn't, maybe my encryption will save my ass since they wouldn't be able to prove anything.
It probably won't come to that, but just in case..

I keep watch of my server's logs (duh) every week, and every week I see the same evidence of default scanners skiddies use to try and get access to web servers. Look, if you need to use an automated scanner to attack my website I can guarantee you won't ever get in. It's running a custom kernel, apparmor, RBAC, modsecurity with custom rulesets, and automated updates every day. On top of that, there's only one user allowed in SSH and that uses has a 4096-bit private key. I keep seeing things like "root" and "www-data" and "oracle" as invalid users in the logs. Good try, though.

At 7/24/16 07:06 PM, PrettyMuchBryce wrote: * One house had its door in front of a cliffside so it wasn't possible to enter it.

Yeah I need to implement a can-every-tile-be-accessed algo.

* Once upon exiting a house I got a black screen

More info? Someone else got this too, but I can't repro it. He got it by transitioning maps back and forth really quickly.

* Once I bombed an enemy and died and the game froze. Possibly intentional for now ?

Your bombs can damage you, and I haven't handled when you die yet.

* I saw a couple enemies which seemed to spawn inside bushes and couldn't get out.

I fixed that earlier today I hope

* When I threw the boomerang at a rock it passed through the rock on the way out, but on the way back it seemed to collide with it, or try to avoid colliding with it.

The boomerang should always collide with rocks, like I'm pretty sure you can get the boomerang stuck if you position yourself behind a rock on the way back. Might have been a visual thing?

I think the sword is my favorite weapon, although I might play around with making the swing time a bit shorter to allow for some more strategic dodging and attacking. Just a suggestion though.

One of the swords that exists is faster than the others I think, but ok. Idr which sword is in now, though.

The most convenient route would probably be working with what you already have and trying to find the source of the performance problems, but if it's not possible another thing that came to mind was using A* with a dense collision grid. The nodes don't need to be the size of the visual tiles or entities. They can be much smaller. Entities which overlap multiple nodes would mark these nodes as occupied. If you're concerned about rigid looking paths you could look into path smoothing algorithms.

What I have now has performance problems with many enemies strictly because of how many times nape's raycast has to be called. Also, there is a rare edge case (literally) where the pathing fails. I want to do A* or heatmap when the enemy loses line of sight because otherwise the bug is a function of my player's speed and how often I raycast. Even once a frame can't deal fully.

What's the point of a dense grid, for a smoother path? I think path smoothing can be a problem since that would be running independent of nape, so I'd always have to double check that the path isn't colliding with something, which requires raycasts. I'd also have to take into account the width and height of the agents' collision boundaries, but that's not too big of a deal I think.

Thanks for the feedback!

At 7/24/16 12:45 AM, MSGhero wrote: Ok: have to be logged in, and just flash export for now http://www.newgrounds.com/projects/games/1003479/preview

I like it! Obviously its pretty early to say anything, but the system seems pretty good. Bryce mentioned the bugs I saw, plus some others. I recommend switch to WASD + Arrows for move and attack, respectively. IJKL is tough on the wrist.

My only real complaint is the trees. I don't like the lighting on them, and how each one stands alone, making the whole thing seem orthogonal and repetitive. Id much prefer a canopy pattern, like the lost woods in ALttP. other than that the art is great.

At 7/24/16 09:20 PM, GeoKureli wrote: Bryce mentioned the bugs I saw, plus some others. I recommend switch to WASD + Arrows for move and attack, respectively. IJKL is tough on the wrist.

Controls will be customizable, and I think I'll have several default loadouts to choose from.

My only real complaint is the trees

Makes blitting easier lol, but ok

Did you get the black screen error? I feel like that has to occur along the border maps, more than likely on row 0, but I'm not sure.

Obviously its pretty early to say anything
early
e a r l y

*cries*

At 7/24/16 09:38 PM, MSGhero wrote:

At 7/24/16 09:20 PM, GeoKureli wrote: My only real complaint is the trees

Makes blitting easier lol, but ok

Did you get the black screen error? I feel like that has to occur along the border maps, more than likely on row 0, but I'm not sure.

I didn't get a black screen but on the top left most place I got what looked like a see-through dialog bar

Obviously its pretty early to say anything
early
e a r l y

*cries*

Rome wasn't built in a day... or even 3 years, man

At 7/24/16 09:46 PM, GeoKureli wrote: I didn't get a black screen but on the top left most place I got what looked like a see-through dialog bar

Whoops forgot I was messing with a file but didn't change it back.

I found the cause of the/a black screen bug...what a bug. The little diglet things (Dagut) that leave damaging trails don't have their trails removed for some reason, even though the player's projectiles will get removed. They get destroyed, but then they stick around.

Edit: omg it's the nefarious removing from an array while you're iterating over it bug. I thought it was handled automagically, but I'm thinking of a different case.

At 7/24/16 10:03 PM, MSGhero wrote: Edit: omg it's the nefarious removing from an array while you're iterating over it bug. I thought it was handled automagically, but I'm thinking of a different case.

if possible always iterate loops backwards, let me count thy reasons:
- you can remove elements during iteration
- its faster because you only check array.length once
- in as3 its simpler/shorter/faster to say for(var i:int = arr.length; i--;) than for(var i:int = 0; i < arr.length; i++)

At 7/25/16 04:35 AM, GeoKureli wrote:

At 7/24/16 10:03 PM, MSGhero wrote: Edit: omg it's the nefarious removing from an array while you're iterating over it bug. I thought it was handled automagically, but I'm thinking of a different case.

if possible always iterate loops backwards, let me count thy reasons:
- you can remove elements during iteration
- its faster because you only check array.length once
- in as3 its simpler/shorter/faster to say for(var i:int = arr.length; i--;) than for(var i:int = 0; i < arr.length; i++)

Just to balance that argument:

Downsides:

- Readability suffers (although, like all readability arguments, this is a matter of taste I suppose)
- If you use an unsigned integer for your iterator, the loop will become infinite if it's allowed to go below 0, since the number will wrap back up to a large positive number

Also you can mitigate the access of arr.length by assigning it to a variable before starting the loop (always a good idea)

At 7/25/16 06:25 AM, Rustygames wrote: - If you use an unsigned integer for your iterator, the loop will become infinite if it's allowed to go below 0, since the number will wrap back up to a large positive number

So long as i-- is used as the conditional, an integer underflow won't be an issue. You'd have to do something pretty goofy (or downright wrong) with the conditional to cause an infinite loop.

At 7/25/16 08:08 AM, Diki wrote:

At 7/25/16 06:25 AM, Rustygames wrote: - If you use an unsigned integer for your iterator, the loop will become infinite if it's allowed to go below 0, since the number will wrap back up to a large positive number

So long as i-- is used as the conditional, an integer underflow won't be an issue. You'd have to do something pretty goofy (or downright wrong) with the conditional to cause an infinite loop.

I rarely iterate the length, I usually just do `for (pt in pts)`. I'm not sure if that gets optimized to the best option per target. Definitely haven't used uints in a long while.

At 7/25/16 09:53 AM, MSGhero wrote: I rarely iterate the length, I usually just do `for (pt in pts)`. I'm not sure if that gets optimized to the best option per target. Definitely haven't used uints in a long while.

If your target language is ECMAScript (assuming you're writing this as Haxe to start with) then it probably isn't, and the for...in loop is slower than a regular for loop, but not significantly enough that it's likely to be an issue. On the other hand, it's better to use a regular for loop for arrays because for...in isn't ordered and is generally intended for iterating object properties. Plus, for..in will only give you the index, not the value, so it's pretty much just doing the same thing as a regular for loop but in a goofy way.

But it's possible that Haxe will fix that for you if your target is ECMAScript. (Not that it's a good idea to rely on a compiler to fix your code for you.)

At 7/25/16 10:33 AM, Diki wrote: But it's possible that Haxe will fix that for you if your target is ECMAScript. (Not that it's a good idea to rely on a compiler to fix your code for you.)

Js optimizes it to a while loop, if this screenshot from my phone doesn't upload. I think because there are actual js/cpp/etc devs who care about the performance of generated code, they specifically make haxe output what is "best." This is pretty minor performance gains as far as I care, either way.

Yeah, the main benefit is to allow removal during iteration, everything else is just minor gains. would be nice if more languages had a for each reverse, though. In as3 for each can have elements removed during for each iteration but if haxe is compiled to a while then you lose that ability.

At 7/24/16 09:20 PM, GeoKureli wrote: I recommend switch to WASD + Arrows for move and attack, respectively. IJKL is tough on the wrist.

@MSGhero pls no

At 7/25/16 05:30 PM, Sam wrote:

At 7/24/16 09:20 PM, GeoKureli wrote: I recommend switch to WASD + Arrows for move and attack, respectively. IJKL is tough on the wrist.

@MSGhero pls no

actually I'm currently pretty fond of IJKL and arrow keys as an alternative to WASD and IJKL, so i guess everyone is can be happy

At 7/25/16 05:30 PM, Sam wrote: @MSGhero pls no

Why do you hate yourself?

Edit: Is it Halloween already?

At 7/25/16 05:59 PM, egg82 wrote: Edit: Is it Halloween already?

What is holloweenish about a purple totem?

At 7/25/16 06:13 PM, GeoKureli wrote:

At 7/25/16 05:59 PM, egg82 wrote: Edit: Is it Halloween already?

What is holloweenish about a purple totem?

It's more the spooky aspect of it that caught me off guard at first.

At 7/25/16 07:45 PM, MSGhero wrote: It's more the spooky aspect of it that caught me off guard at first.

This. Also it really does look slightly creepy in a "toy-doll" sense.

At 7/25/16 05:59 PM, egg82 wrote:

At 7/25/16 05:30 PM, Sam wrote: @MSGhero pls no

Why do you hate yourself?

It's for efficiency. Fingers travel less distance... or something...

At 7/25/16 05:30 PM, Sam wrote:

At 7/24/16 09:20 PM, GeoKureli wrote: I recommend switch to WASD + Arrows for move and attack, respectively. IJKL is tough on the wrist.

@MSGhero pls no

If the key bindings can be changed by the player then this problem would be averted.

I also have no idea how you could use such a goofy keyboard. You don't code with that thing, do you?

At 7/26/16 08:28 AM, Diki wrote:

At 7/25/16 05:30 PM, Sam wrote:

At 7/24/16 09:20 PM, GeoKureli wrote: I recommend switch to WASD + Arrows for move and attack, respectively. IJKL is tough on the wrist.

@MSGhero pls no

If the key bindings can be changed by the player then this problem would be averted.

I also have no idea how you could use such a goofy keyboard. You don't code with that thing, do you?

Only thing it's really missing is the arrow keys, which you get used to with the FN key and I don't use the numpad much anyway.

get in the tube

https://www.youtube.com/watch?v=QTe5i-jEYTs

https://www.indiegogo.com/projects/haxeflixel

Flixel is having a fundraiser for the founder to work full time on the lib (it needs it badly), and it's almost funded already.

At 7/26/16 03:23 PM, MSGhero wrote: https://www.indiegogo.com/projects/haxeflixel

Flixel is having a fundraiser for the founder to work full time on the lib (it needs it badly), and it's almost funded already.

at first I wondered why he didn't just do a Patreon. Then I saw Patreon getting $125 a month compared to IndieGoGo getting what appears to be 2550 with most of a month left to continue funding

At 7/26/16 05:32 PM, GeoKureli wrote:

At 7/26/16 03:23 PM, MSGhero wrote: https://www.indiegogo.com/projects/haxeflixel

Flixel is having a fundraiser for the founder to work full time on the lib (it needs it badly), and it's almost funded already.

at first I wondered why he didn't just do a Patreon. Then I saw Patreon getting $125 a month compared to IndieGoGo getting what appears to be 2550 with most of a month left to continue funding

EDIT: The Flesh to Stone fun pack listed there was made by my buddy Ted.

Acutal Edit, I guess I hit reply instead of edit, accidentally.

All this, this, and this tells me is that you don't give a shit about security. There is no reason I should be seeing any of those in 2016.

By the way, all of those are from the same company, on different sites. I'm pretty sure nobody there knows how to HTTPS.

Edit: Damnit, NG - why do you hate me?

At 7/26/16 05:53 PM, egg82 wrote: All this, this, and this tells me is that you don't give a shit about security. There is no reason I should be seeing any of those in 2016.

By the way, all of those are from the same company, on different sites. I'm pretty sure nobody there knows how to HTTPS.

Edit: Damnit, NG - why do you hate me?

There's an option now to force your game to be served on https, which is cool. I'm not sure what the benefits are to not doing that, though. Seems like it should be the default.