Yaya may be biased b/c he's mainly interested in our HATPC community. However, to make the site grow, we must aim at a much larger target audience. Even though our level database accepts any game, we will get virtually no real [active] members from that avenue unless it is an impressive service, and only our HATPC collection and features are impressive. With my vision for the upgraded site, people will come to the Interguild simply because they want to browse through our massive collection of levels for any game. The only thing attracting people to the more popular games on this site will be the fact that they can search several sites at once. However, for the smaller games, we will also have records from levels posted on forums and stuff, and when those people find a level database for those games on this site, they will post their levels here, bring their forum friends and so on.

They'll hopefully enjoy the ease of use of the database, in contrast to the fact that some other databases have questionable browsing, and maybe it'll get to a point where they prefer to browse for levels here as opposed to fr2db.fr, for example. And hopefully they'll get interested in some of the other games on here and come back for more. Through repeated use of this service, they may start uploading levels and become interested in the community.

*POOF*No Isa. I thought we were just a bunch of nutty guys who loved Hatpc and talked to eachother. Honestly I don't mind the multiple games though sometimes Livio's ideas do seem a bit radical and unrelated.  

I haven't worked on Aeon much ever since I began working on the new layout and stuff. But today, I was bored in school so I started looking through the files that I had on my flash drive. I wasn't sure which files were more updated, my home files or my flash drive files, so I just messed around in the swf (the final exported file) and played with the Debug menu, when I suddenly got this crazy awesome idea!

Well, you probably don't care about the specifics but it will enable me to make levels load crazy fast.

Basically what I found was that if you raise the frame rate, the demo level will load significantly faster, depending on how high the frame rate is. However, if you raise it too high, it'll backfire and the level will load significantly slower than at default. SO... I'm gonna try to experiment with a way that will detect your computer's optimized frame rate for loading levels, and then whenever it loads a level, the frame rate will automatically change to your optimized frame rate, load the level super fast, then when finished it'll switch back to what the frame rate used to be.

To detect your computer's optimized frame rate, I'm planning on putting something after the initial "game is loading" screen that will make you wait for like 5 seconds while it times you on how fast your computer goes through certain functions at varying frame rates. I actually don't know how long it'll take, but I'm timing you based on milliseconds... But then again, I don't know how long it takes Flash to react to your computer's specifications. Lol, we'll see how this goes.

You know, I prefer a content-filled slow-loading game over a fast-loading one without any real content, so please focus on stuff such as basic wooden crates now.

the loading-level screen is super important since you're going to be seeing that over and over again. I find that sometimes how quickly (or slow) a level loads directly affects how much I enjoy the level itself. And if it can load super fast, then that'll be the coolest thing ever.

Not as cool as Icicle spikes.

I don't care what you work on first, but at least make some sort of progress soon.

I doubt that our current demo can ever classify as "the coolest thing ever".

lol I didn't mean the demo, but the fact in itself that it can load super fast.

And I really don't see a difference in the order that stuff is done. As long as I'm not doing something pointless, it'll probably get done eventually, thus making no real effect in the long run. Plus, sometimes it's better to work on the parts that I feel like working on, so that I won't procrastinate on parts that I get tired of working on. Such as how when I set up the collision detection system, it took me a while to get it to work, but because it wasn't working, I couldn't work on anything else, so I ended up procrastinating a lot.

Isa, why are you so critical of what he chooses to work on for the demo first? Why does it matter that much? Is a poorly animated wooden crate going to make the game that much better that it should be a priority? No. It shows no more progress than making the levels load faster. It's a new object to use in the level, but that's probably not going to help finish Aeon any faster, so why should it be a priority over making levels load faster?

Releasing the Demo in parts is a good idea, because that way the community gets to find bugs, experiment with the tiles and settings, and if you then prioritize loading time instead of new content, a new update will come much later to the dismay of the community.

Isa has a point. Aeon Demos really help in terms of activity. In fact, I just realized something really interesting, but I can't seem to figure out a way to articulate this new idea.

But how long will they experiment with such minor additions? After the first Aeon Demo, I kinda stopped playing around with it maybe after the second day. When we get later on in the game, new features will be more interesting, but for now, a wooden crate(Which actually come after the door and spikes) won't cause add much to gameplay. We'll probably spend a day or two testing it out, but then we'll just move on when there's nothing else to do with it.



Speaking of which, we should probably decide which tiles should be added to the demo in what order.

terrain, doors, power boxes, secret areas, ....

edit: lol I know that was most likely sarcasm, but this is my prediction of how they will get added....

We already have terrain.

I'm thinking that our next additions should go in this order

Door(we need a goal in our level, even without the powerboxes)
Spikes
Steel Crates
Ladders
Platforms
Wooden Crates
Power Boxes
Other crates
Water
water taps
water/tap crates
Moving enemies(?)

anyway, about what Isa said, it's true that whenever I work on things for a long time, it hurts the community, mostly because not many new things happen and I guess people get bored. So to counter that, I think that it may be a good idea for me to be less disciplined with what I work on and when I work on it. For example, lately I've been working on nothing but the new layout, but then out of no where I made the new New Topics button, which was pretty interesting after a period of nothing new, aside from comps.

So I guess what I'm saying is that I need to work on more things, rather than trying to put all my focus on projects one at a time. Hmm, now that I think about it, the fact that I always focus on one big project at a time is probably why there's very little glitch fixing around here. And why those FR2 and N preview-makers were never made... and stuff like that...

I thought we were talking about the Aeon Demo specifically.

My suggestion would be for you to perhaps make the door, then work on the faster upload thing, because a fast level uploader will probably be useful when we start testing the spikes for any glitches.

I've been working on Aeon lately. I'm gonna see if I can get my collision test revamp done and out of the way by the end of the weekend. I really should work on this for more extended periods of time (as opposed to brief instances of work) b/c some of my organizing is very questionable...

Anyway, expect a lot of glitches to be fixed.

Hey, CSD was right all those months ago, that for some reason in the Debug menu, decimals hardly make a difference, or rather, it's like they aren't there. Well, I just checked in the decimals are indeed recorded, so if there's anything going in, Flash may be rounding the differences in pixels when displaying it.

I also finally set up CSD's optimized settings, but I thought his falling speed was too high and the running speed too slow, so I tweaked them.

If you do math using those decimals and other numbers that aren't decimals, maybe the result ends up as not a decimal? I don't know... Try casting any non-decimals into decimals during calculations?

I don't know, if I use 0.1 for acceleration it seems to work just fine.

like I said, I think it's just an illusion cased by the visual rounding of pixels when everything is displayed.

I just fixed an annoying glitch that has been blocking all progress on the Aeon demo for the last few months. Here's a description of the glitch:

Sometime after releasing the last demo, I began to recode the basic structure of the collision detection system. What was wrong with the old system was that there really was no way to prioritize in what order reactions occurred in, and the game tried to just react to every tile it came across. For example, say you were walking along this path: If you walked into that wall on the left, a collision would've been triggered with the highlighted tile. And if you tried to jump up that wall, the game may be tempted to act as if you were hitting those tiles from underneath, rather than its side, so you jump would be interrupted. The reason this doesn't happen in the Demo from October is because the tiles had side-buffers which prevented that.

So my solution to fix this problem was to overhaul the whole collision detection-management system. Now, the collisions are in pretty much done in random order, and they're all logged as several objects in an array. That array is then sorted by the type of reaction: whether or not it depends on the horizontal or vertical position of the player in order to be valid. Following this priority, the part of the code that handles all of the collision reactions begins to implement the changes one by one. On each loop, it checks to see if the already-implemented changes have overwritten the upcoming reaction.

The glitch was that this new system was not achieving its desired effect, except that this seemed to make the problem worse. It turns out that all that happened was that I forgot to update some variables, and when it checked if the collisions were still valid, it kept comparing the same values over and over again.

So now, collisions work way better, and I just avoided several potential glitches that would've come up in the future, too. Now after I finish polishing this, I can start adding new tiles.

just added the death function in the game. When you die, you keep going in the direction that you were going when you died (but there's a max speed of like 3 pixels per frame, or else you'd fly around like crazy) for 40 frames (1 and 1/3 seconds), and then the level restarts.

You can kill yourself by pressing "K", and even though that's redundant (b/c you can skip death and just restart by pressing "R"), I think I'll keep that function there for the heck of it.

I'm currently adding spikes. And now that I'm adding other tiles other than terrain, I really have to get the tile system organized in a more efficient way.

I wonder if you know that if you click the terrain of the map, it turns green, then blue, then yellow, then black again?

yeah I knew that. I added that on purpose when testing something. I just keep forgetting to take it off.

Now I remember, I added that when I was testing the scrolling feature. What happened was that I would write maybe one line and then I'd copy and paste it several times to get a big map. Once it grew bigger than the available space, you can use the arrow keys to scroll the map around. It's really hard to see if it's moving if all the tiles look the same, so I added the thing where all I had to do was click and the color would change so that I can have that visual reference point.