At 7/28/14 11:57 PM, MSGhero wrote:

Their documentation on the server stuff and encryption is good, had to pm PG about one thing. Right now it's more of an issue of how the api will be organized. It could be like the flash api, or we could group things to be more organized. Like someone said, there's only 25 methods, so it's not the biggest deal if they aren't in pretty groups.

api.medals.unlockMedal() vs api.unlockMedal()

I'll keep an eye on it on github and and I'll be sure not to touch it at least until I see how you guys are gonna organize it.
I don't wanna just jump into someones project without asking, but I don't mind helping out with it when I have the time, if you guys needed it.

At 7/29/14 12:22 AM, bumblefish wrote: I'll keep an eye on it on github and and I'll be sure not to touch it at least until I see how you guys are gonna organize it.
I don't wanna just jump into someones project without asking, but I don't mind helping out with it when I have the time, if you guys needed it.

I have no clue how it's gonna be organized. What do you think?

At 7/29/14 02:56 PM, MSGhero wrote: I have no clue how it's gonna be organized. What do you think?

It honestly doesn't matter to me one way or the other.
As long as there is information on how to use the Haxe version there shouldn't be any problems organizing it a little.

At 7/28/14 11:57 PM, MSGhero wrote:

api.medals.unlockMedal() vs api.unlockMedal()

I don't really see the benefit of api.medals.unlockMedal(). In fact I think the group might make things esoteric, and I don't think there's enough methods in the API to justify it. If you do try it out, then at least make it API.medals.unlock(...); for less reduncancy.

At 7/30/14 08:56 AM, GeoKureli wrote: I don't really see the benefit of api.medals.unlockMedal(). In fact I think the group might make things esoteric, and I don't think there's enough methods in the API to justify it. If you do try it out, then at least make it API.medals.unlock(...); for less reduncancy.

The problem is implementing a good medal system. Since most of your medals won't be linear in any way, it's much more difficult to fit them into your game in an organized manner.

That said, I would prefer a Medal class in which there's an unlock() function. That way I can put the medals into an array with a string key and keep everything at least mostly organized while staying modular for easy copy/paste.

At 7/30/14 07:13 PM, egg82 wrote:

At 7/30/14 08:56 AM, GeoKureli wrote: I don't really see the benefit of api.medals.unlockMedal(). In fact I think the group might make things esoteric, and I don't think there's enough methods in the API to justify it. If you do try it out, then at least make it API.medals.unlock(...); for less reduncancy.

The problem is implementing a good medal system. Since most of your medals won't be linear in any way, it's much more difficult to fit them into your game in an organized manner.

That said, I would prefer a Medal class in which there's an unlock() function. That way I can put the medals into an array with a string key and keep everything at least mostly organized while staying modular for easy copy/paste.

Well, the medals are already in an array, and there's a getMedal(name) to access them by name. The order of medals matters sometimes, so it'd have to stay an array instead of a string map. Modularity isn't that big of a deal bc you'll never need to code "createSaveQueryByRating()" again in any project.

Plus you (user) aren't the one querying the server for medals and organizing the innards, that happens when you connect to the api.

I want the SaveQuery, SaveRating, etc classes to be in the "saves" package, with saves:SaveFrontEnd or something holding all the methods -> API.saves.method(). Redundancy would be annoying. For now, the methods will stay in one class.

So I'm finally getting round to building a game with composition. Hopefully @PSvils or someone knowledgeable can help me out.

What do I do about my main character?

Currently I have entities stored in JSON and then I can call a make entity method on a string path to the JSON, which parses it and builds it all up and whatever.

I need him to react to some kind of input, so I figure I need a system to handle that - that's fine. I need to have some sort of component to say what keys to react to - also fine. But I'm trying to think of the best way to store what reaction should occur for each key press.

I first thought maybe my KeyReactionComponent (working title...) could take a map of int to function, but right now my components know nothing about the entity they're attached to, so the function wouldn't be able to modify other components on the entity.

Should I just have a singleton component and system for the main character? I feel this kind of defeats the purpose. Could you guys give me the run down of what you'd do?

am such noob

At 8/2/14 02:48 PM, Sam wrote:

Could you guys give me the run down of what you'd do?

am such noob

I wouldn't use component design :) I'll use it if psvils ever releases that game editor.

Why do some developers put a trail of spaces after some lines of their code? Ie.

Like, how does that even happen? Do we just accidentally lay on the space bar for a quick nap after some code or are we being lazy with our removal of lines we don't need?
Either way, it drives me absolutely nuts.

At 8/2/14 07:44 PM, egg82 wrote: Why do some developers put a trail of spaces after some lines of their code? Ie.

func() { //<- spaces
doStuff();//<- no spaces
} //<- spaces

Like, how does that even happen? Do we just accidentally lay on the space bar for a quick nap after some code or are we being lazy with our removal of lines we don't need?
Either way, it drives me absolutely nuts.

When they delete code using backspace or delete, they might not be deleting the tabs that the next line was indented by. As the file gets passed around, the tabs get interpreted as spaces. Happens to me anyway.

At 5/9/14 04:46 PM, GeoKureli wrote:

At 5/9/14 03:03 AM, PrettyMuchBryce wrote: Hey guys. I felt compelled to let you know that I am moving to San Francisco soon ! I'm really excited about it.

Good luck In SF. One of the reasons I took my current job was so that I'd eventually request a transfer out there. Awesome place, and a way better place to get into a stable gaming job than Chicago.

Thanks man. I'm not really doing game development anymore. I'm doing more traditional software engineering at this point. Still doing games in my free time, though !

http://prntscr.com/4a4ngd
Well, that's a thing that's happening now o.o

Cross-promotion of AIR apps on mobile is pretty neat, could help with app store exposure once it comes to ios.

Side note: the 2nd author looks pissed.

And if you guys ever need a decent isometric lib in haxe that doesn't perform like shit like every other one, I got you.

Day 1 of RMFC: Stayed up late, woke up early, helped set up, sold $200 worth of stuff in the first four hours, then went to work and sold $200 more. Passed the fuck out, and here I am.

Also had a really, really drunk furry ask my girlfriend and myself to have sex with him in turn.

Welp..

Day 2 of RMFC: Came in early and was able to stay all day, made $630
Went to a rave, now I'm tired again.

At 8/9/14 11:42 PM, egg82 wrote: Day 2 of RMFC: Came in early and was able to stay all day, made $630
Went to a rave, now I'm tired again.

You can credit that to all that publicity from jugg2.

All 46 clicks

At 8/10/14 12:54 AM, MSGhero wrote: You can credit that to all that publicity from jugg2.

All 46 clicks

All dat internet moneyz :P

Day 3 of RMFC: Final day. Sold just about everything, only had half a table of items left and even then some of it was new jewelry we put out.
Made about $1,000 in total, minus taxes that's still a lotta profit. Gonna have to deal with those tax formalities soon, though, or we'll have the fury of the IRS on us in a few months.

Was a lot of work, but totally worth it.

I could literally throw all this on the bed and sleep on it. And I want to. So badly.

This biteable thing looks pretty cool

http://biteable.com/

It costs $100 per video though. Which, as their FAQ says, is yes pretty cheap for a custom animation, but this isn't really custom. If it catches on it'll eventually be a pretty cookie-cutter kind of thing.

Haxe api is almost usable, save file loading and saving is next. Not sure how to handle the file icons, bitmapdata is only accessible when compiling to flash in pure haxe. I don't want to use any openfl because the api could be used with the other haxe libs like flambe or awe6. Hmm...

At 8/14/14 11:39 PM, MSGhero wrote: Haxe api is almost usable, save file loading and saving is next. Not sure how to handle the file icons, bitmapdata is only accessible when compiling to flash in pure haxe. I don't want to use any openfl because the api could be used with the other haxe libs like flambe or awe6. Hmm...

Power of abstraction.

At 8/15/14 12:19 AM, slugrail wrote: Power of abstraction.

I looked it up, and these typedef structs can be used like duck typing, interesting. Sprite can be cast to a { x:Float, y:Float }. I don't think that helps here, and generics don't look good here (might have to though). I learned what the js version of bitmapdata is called, so I might #if for flash and js, but that might not work when coming to openfl. Idk, this is weird.

I will never be beaten.

3/29/12

At 8/16/14 06:43 AM, Sam wrote: I will never be beaten.

3/29/12

FUCK YOU SAM.

At 8/16/14 04:22 PM, Luis wrote:

At 8/16/14 06:43 AM, Sam wrote: I will never be beaten.

3/29/12

FUCK YOU SAM.

O-ok

i mis u

At 8/16/14 05:31 PM, Sam wrote:

At 8/16/14 04:22 PM, Luis wrote:

At 8/16/14 06:43 AM, Sam wrote: I will never be beaten.

3/29/12

FUCK YOU SAM.

O-ok

i mis u

I MISS YOU. ALL. DONT BAN PLS.fla

At 8/16/14 05:58 PM, Luis wrote: I MISS YOU. ALL. DONT BAN PLS.fla

THE RIGHTEOUS FURY OF THE BAN HAMMER SHALL SWIFTLY COME DOWN UPON THE UNWORTHY AND SMITETH THEM.

hai, Luis :D

created a nice little 2D raycasting collision detection library in AS3 which should work with whatever project you have since it uses its own system. Bit of a pain to port vertices from whatever you have to this system, but meh. Price I pay for being "general" I suppose.

Anyway, detecting and reporting every possible pixel-level collision along a line going from (0, 0) to (800, 600) with a circle and a square (poly) takes 7.9896 ms on my PC.
Detecting and reporting the closest pixel-level collision to the starting point (0, 0) with the same data takes 1.2174 ms or 1.4898 ms depending on which object comes first (circle or poly) on my PC.

All-in-all, I think that's pretty alright for most projects. A square is a pretty simple shape, so I'm sure adding more vertices will increase the time it takes, but I'm not sure by how much.

I still have no idea what I'm going to do with this.. Thing- once I'm done with it. For now it's just a big collection of things I developed over time that have been useful to me regardless of the project, engine, framework, or library(ies).

Anyway, back to work. I still have quad tree and pixel-perfect (bitmapdata alpha) collision classes to create.

While trying to find a good pixel-perfect bitmapdata collision detection class, I somewhat-created my own. By that, I mean I stole bits and pieces from other ones and put them together. Either I made Frankenstein's monster or something beautiful. Either way, I can't find anything like it on the interwebs.

Basic theory:
if the two rects of the bitmaps don't intersect (given x, y values and widths + heights) then they're not colliding, so do nothing else
otherwise, create an overlap rectangle for both bitmaps; then copy the alpha channels from these and put them into new, blank bitmaps of the same size as the collision rect.
take the uint vectors from these bitmaps, go through them, and add them together. If the sum of the values from these vectors is greater than either of the original vectors plus a certain threshold, assume a collision. You can even pinpoint the pixel(s) that collided.

again, not sure if this is even a good idea or not, but it's worth a shot.

At 8/18/14 10:36 PM, egg82 wrote: again, not sure if this is even a good idea or not, but it's worth a shot.

Sounds neat, I don't think I've ever seen the alpha channel draw. Does that mean you're using srcAlpha in copyPx?

At 8/18/14 11:25 PM, MSGhero wrote: Sounds neat, I don't think I've ever seen the alpha channel draw. Does that mean you're using srcAlpha in copyPx?

nah, they have a copyChannel function. Basically the same thing as copyPixels except it's specifically for the different channels.

also, a mistake: the sum of the two vectors would need to be greater than both the original vectors to be considered a collision.