Hey Isa, I think I figured out a way to make it so that you won't need CS5 in order to compile Aeon. First, here's some info on different ways you can compile a project:
http://proquest.safaribooksonline.com/9781590597910/14
http://proquest.safaribooksonline.com/9781590597910/22
http://proquest.safaribooksonline.com/9781590597910/23

And rather than placing our objects into the Flash Library, you can embed them using code and the compiler will do it for you:
http://proquest.safaribooksonline.com/9781590597910/115

It's alright, I appreciate that you took the time to check those things for me, but I'll find a way or two to get CS5 to work for me - if everything else fails, I'll just download the trial version again.

oh wait, it seems I overlooked something. That solution would meant that we wouldn't be able to use Flash's built-in components, like ScrollBar and TextArea. Or maybe there's a way to do that too? Oh well, we can always look into it later if we need to.

Btw, this week I've tried to start a habit of working on Aeon for at least an hour everyday, but unfortunately, I haven't been keeping up with that goal for the last three days. Maybe I'll work on it some more later today after I finish my computer science projects.

I'm still giving you plus karma for having the ambition to destroy your social life, lol. I'm cheering for you!

lol. well, there's not much to do around here on campus anyway, and that hour usually comes from some free time in between some of my classes.

Sorry for necroposting, but I got Flash 8 from school. Is there any good tutporials anywhere that I could use to start of scripting in flash? (I think I'm using Actionscript 2.0)

Make that dittoed. But also I don't really know enough about scripting to know what to do about Aeon.

ActionScript 2.0 is unfortunately very out of date. Livio uses 3.0, and it's very different from 2.0, I think.

I've been meaning to post this for a while now, but we've had Aeon up on a public repository, so you can track our progress from there:

https://github.com/ksiondag/Aeon/tree/livio

I'm linking to my branch rather than the master branch because at any given moment this is most likely to contain the latest version of the game. Part of the reason why I hesitated to link to this was because it contains references to features that I'm hoping to surprise you with, but whatever.

If you're like Thomas and you want to try compiling this code, you'll have to configure your compiler so that the .swc files in the project root are included in the build path. And if you do manage to compile it, prepare to be disappointed because many features aren't working as I continue to work on back-end stuff. I'd just wait until the demo if I were you.

I mentioned that I've been working on this game with a friend from university, Greg, but as of today he will be leaving the team. He's been having some problems getting a decent IDE to work in, among other things, and he's found it fairly challenging to find the focus and discipline to work on the game. Meanwhile, I've been making significant progress everyday and it has gotten to the point where he thinks I'll be more efficient if I won't have to wait on him to code features and if i just coded them myself. He's got a point, but it's still a shame that he couldn't contribute more to the project.

I've gotten into the habit of sending Greg daily progress reports of everything I've coded during the day, and it's really turned out to be a helpful habit from a productivity and organizational point of view. I guess I could try to keep that habit up here (so that you can be amazed when you see how I've dedicated 4-7 hours daily to coding Aeon, not counting breaks), but these reports are usually about the internal workings of the game, which you probably don't care about. So I'm thinking of submitting these reports as commit comments on the repository, since I tend to push to the repository once at the end of the day.

But given Greg's departure from the team, I might need to extend the Aeon demo by another week. This way I can continue working until the weekend before I return to university and you can have a more complete game to play with until the following demo. I still want to try to get something working by new years, but that's not very likely.

Okay, I changed my mind. I'm gonna post my daily progress reports here, because it's not very motivating to post them in a place where it's likely no one will read them. In fact, I haven't posted a single report on github since last week (not counting today's report), so instead of an end-of-day report, I'll write an end-of-week report today. Anything left unexplained is left unexplained for a reason, which is mostly because I would rather wait for the demo to give a full explanation of some the features.

END OF WEEK PROGRESS REPORT

This was a tough week to find time to work on the game, mainly because of Christmas and New Years and various family activities. Overall, I worked for 15.2 hours this week, which is not a lot compared to the 24 hours I spent in the previous week. But now that all of the holiday festivities are over, I hope to get back to full efficiency again and to make the deadline for a playable demo this weekend.

Here's a list of things completed since last week:

--Fixed a bug in the styles system

--The styles system now supports deep inheritance, thanks to the wonders of recursion.

--The User Levels page only shows Aeon levels that were uploaded to the database after New Year's Eve 2011, so that you don't end up loading in incompatible level codes, which at this point break the game for unknown reasons. This change is also meant to prevent people from getting excited when they see how many levels there are, only to realize that none of them load properly.

--The User Levels page now gives you an error message when no levels were found.

--Fixed what seems to have been a threading-related bug that prevented the game from loading a new level after closing another one. This bug can still happen if you try loading an invalid level code, so I will have to investigate this further.

--Started working on the new collision detection designs.

--Started implementing the new collision detection system. Progress is described in more detail with the following list items:

--Set up the beginnings of the static/dynamic object system. All objects start as static, but before starting the level, some may change to dynamic depending on what their styles are. This means that I implemented the system that allows for state changes from static to dynamic.

--Later, I added support for dynamic-to-static state changes, specifically in the case where a dynamic object falls on a static object and becomes static itself. I still need to add support for when in-game objects (as opposed to initialized objects) change state from static to dynamic. These objects must notify any surrounding objects of the change, in case they too need to become dynamic.

--The only styles supported before this week were  

hitbox-width

,  

hitbox-height

, and the shorthand  

hitbox-size

. This week I added the support for the following settings:  

init-state

,  

allow-state-change

,  

allow-collisions

,  

can-use-ladder

,  

coll-edge-top-solidity

,  

coll-edge-right-solidity

,  

coll-edge-bottom-solidity

,  

coll-edge-left-solidity

, and the shorthand  

coll-edge-solidity

.


Today I plan to work on getting in-game static-to-dynamic state transitions to work properly, and to get the new collision detection system to distinguish between multiple directions.

I find it totally awesome that this is now an open code. good to see you making progress. since it's end of semester already, are you going to push this through?

My classes ended almost three weeks ago, and I've really been trying to push this game forward since then. You guys don't even know about some of the incredibly versatile systems I've designed and implemented already. I just wish the game was in a more playable state, though. I go back to University on Sunday, but classes don't start until Wednesday of next week, so if I don't get a good demo by this weekend, I'll try to get it ready by Tuesday.

I've really been getting serious about time management for the last few months, and I'm hoping I can make the time to keep making significant contributions to Aeon during the semester, because I'm really not interested in waiting until Summer to make real progress again.

Pretty cool!  I was a bit disappointed when you said you wouldn't ;ost them here, because even if we didn't understand it, I would at least enjoy it and it's better for you.

/can't wait for demo

I think that you should make a list of features/ideas/implementations/other good programming stuff, so that when you talk about it and use it for like uh...resume? so it'll be easy for you to explain. this way you can also let us know, and it could be shorter than just a wall of text.

That's not a bad idea, shos, but that sure would take up a lot of time, and that's not something I have a lot of. Maybe I could write some posts about it on my blog. The excuse will be that since it's open source, those posts will be the definitive guide to understanding the code.

END OF DAY PROGRESS REPORT

Wow it's been a long day. I could've sworn I wrote my last report yesterday.

I worked on Aeon for about 5.6 hours today.

I made lots of important improvements to the collisions detection system. The first being that objects can now "collide" with multiple objects at once. What I mean is that when you have one object (such as the player) standing on two tiles at the same time, both tiles register it as a collision. Before this fix, the second collision would have been invalid because the first collision had already been resolved, thus placing the intruding object out of the second object's boundaries. The way this works is that it checks to see if the second object's boundary is on the same plane as the first one.

I also like how the new collisions system isn't as arbitrary and as random as the old one. The new system prioritizes which collisions need to be resolved first based on a number of different criteria, such as whether or not this collision has happened in the previous frame, whether an object will be destroyed as a result of the collision, and proximity. This helps avoid tons of random glitches.

The second major thing I worked on was an improvement to the state-changing system. Yesterday this morning, I thought I had already gotten about half of this system working, but now I see that it was really closer to 20%. There are tons of special cases to handle, especially when converting between nonstatic to static states. Today I designed some ways to solve these problems and I implemented the fix for one of the cases (when a dynamic object collides with a static object, which must be notified of all changes by the dynamic object). The other case was when a static object wakes up, it must also tell all nearby objects to also wake up. I already wrote down a solution to this issue, but I haven't implemented it yet, because I want to implement some other features first in order to help me test it.

The next thing I worked on was that I finally implemented the part of the game loop that updates the styles for objects that have had their styles changed by collisions. Rather than looping through every object in the game (which might be a lot), the game instead goes through every nonstatic object and every static object that has had its style triggers altered by the collision resolution system. This also led to more special cases in how the game needs to manage static/nonstatic state changes, because it's the responsibility of nonstatic objects to update the style triggers for static objects whenever a collision with the two begins and ends.

I've added a few more styles:  

hitbox-offset-x

,  

hitbox-offset-y

, the shorthand  

hitbox-offset

, and  

set-static

.

The style  

init-static

  is only applicable during style initialization, but  

set-static

  allows you to change the state of an object at will, based on events. For example, I was able to make a tile that would always be static, except for when something landed on top of it, in which case it would awaken and slowly fall downward. But when the object above it was removed, it would become static again and stop moving.

The  

hitbox-offset

  settings allow you to move the hitbox relative to the tile's upper left corner, which at initialization is a multiple of 32. This is useful for when you don't want the hitbox of your tile to be aligned with the sprite's boundaries, or when you would like to make something like a floor spike, whose hitbox is a fair distance from the tile's upper left corner. It's also useful for any styles that change the size of an object on the fly. By manipulating the offset, you can make it seem as if the top boundary of the hitbox expanded, as opposed to limiting yourself to only expanding the bottom boundary.

The last thing I did today was get started on adding the Behavior system. The Behavior system is designed to add functionality to tiles simply by manipulating its style triggers. For example, the Player controls are part of the Behavior system and it maps keyboard actions to style triggers, so how the object reacts to basic events like "move left" or "crawl" are completely dependent on that object's style settings. Other Behaviors might add other functionality such as giving enemy a route to follow, or commands based on some simplistic AI. Unlike many other parts of the game, the Behavior system has not yet been designed for customizeability, so I'm going to have to cut corners for now and make the PlayerBehavior built-in for the sake of the demo. I hope to one day design this system fully, but given that it's not a core feature, it's pretty low on my priority list.



Tomorrow I will finish implementing the PlayerBehavior class, which will finally allow me to move a guy around the screen again. From there I'll be able to test the collision system with collisions from several angles.

All of this sounds great, but it seems like you are working on very many fronts at the same time - couldn't you work more efficiently if you focused your efforts?

It's actually more focused than it looks. One of the first things I did was implement the framework for the styles system, because that was the most risky aspect of the design and I had to ensure that I could get it working efficiently. The styles system is what controls all of the customization options within the game. I spent a long time trying to come up with a customization interface that would be flexible and elegant, and I couldn't do it using XML, so I made up a system with syntax similar to CSS instead. With almost a hundred different settings and almost two dozen style triggers (or pseudo-classes, if you know CSS), this system is incredibly versatile while limiting the amount of level code needed to alter the functionality of a tile.

While I got the framework and all of its triggers running, I have yet to implement all of the planned properties, mainly because I have to implement the actual feature in the game before you can do anything with the style setting. So whenever I say I added a new style property, I really mean that I've added the actual feature that the style property is supposed to represent.

So after I got the framework of the styles system working, the next step was to get collisions working, because the collision detection system is what alters and controls the style triggers and it's ultimately what determines which objects in the game loop will have to have their styles updated. I only implemented enough of the collisions system to allow me to test this aspect of the styles system.

Once I got that done, I used the same work-around code that I wrote for the collisions system to test the next core feature of the game loop: static and nonstatic objects. There's still one last thing I need to do with this system before it truly works, but I'll implement it later when I have more features to test it against.

Now the next step is to focus on the collision detection system so that it actually handles collisions correctly, as opposed to only looking for one type of collision. The reason I'm starting the Behavior thing is because it will help me be more efficient in testing the collisions system so that I can move an object around on screen as opposed to moving an object in the code, recompiling, and loading in the level.

By the way, level loading is insanely fast now. I seriously don't know how I could've made it so inefficient last time.

END OF DAY PROGRESS REPORT

Today I worked for about 5.0 hours.

I added the PlayerBehavior feature that I was talking about, and I also added a ton of new style properties:
init-as-player
accelerate-x
accelerate-y
accelerate (shorthand)
max-speed-right
max-speed-left
max-speed-x (shorthand)
max-speed-up
max-speed-down
max-speed-y (shorthand)
max-speed (super shorthand)
friction-right
friction-left
friction-x (shorthand)
friction-up
friction-down
friction-y (shorthand)
friction (super shorthand)
set-speed-x
set-speed-y
set-speed (shorthand)
allow-jump
mid-air-jump-limit

I also added a new style trigger called "jumping". I can't believe I didn't think to add this as a trigger rather than a property in my original designs, but now that it's implemented you can control the jumping height through  

set-speed-y

, and maybe even provide some horizontal boost using  

set-speed-x

. You can also set different jumping heights based on whether the player is currently standing (by using the "standing-on-down" trigger) or if the player is doing a double jump (to turn off double jumping, set  

allow-jump: false

  as the default and set it to true when the player is standing). And for the heck of it, I added an option that will allow you to specify the number of double-jumps that the player is allowed to perform in the air, called  

mid-air-jump-limit

. Set it to 0 and you get infinite jumps, set it to 1 and you get 1 mid-air jump, and so on.

The friction settings only apply when the object is not accelerating on the appropriate axis. For example, if the player is walking to the right, friction won't be applied, but if the player stops moving right (and is not moving left) then friction becomes a factor. Because of this, it may be more accurate to name this value "decelerate". What do you think?

I didn't get to work on the collisions system like I wanted to, but I did a lot of debugging and glitch fixing, particularly with the state-changing system and the level loading process. I also tested the game with a 100x100 grid of objects and found ways to significantly optimize the gameloop.


Tomorrow I'll continue optimizing the code for a while, and then I'll get to work on the collisions system, which I'm really looking forward to.

Then how do you get 0 extra jumps if 0 means infinite?

I have a feeling that 0 should be, just that, 0 extra jumps, and -1 should mean infinite jumps instead.

You have to turn off mid-air jumping altogether by setting allow-jump: false. But you're right, this is pretty unintuitive, so I'll go with what Darvince said.

It's 6:45pm and so far I've worked on Aeon for a total of 10 minutes. I wasn't home for most of the day, so I better get to work...

END OF DAY PROGRESS REPORT

Today I worked for about 4.4 hours. If it wasn't for my goal to get at least 4 hours of work done per day, I would've stopped at around 2.5 hours because I'm pretty tired.

So today I started with the same optimizations I was working on yesterday. I added a large meter on the corner of the screen that would print out the average frame rate for the previous 10 frames. The game really did not perform well at all when there were multiple nonstatic objects in the level. I tried putting in a thousand nonstatic objects and it pretty much crashed, or at least each frame was taking about 5 seconds to process. I did manage to optimize it enough so that it only starts to slow down significantly after maybe 7 nonstatic objects, but that's still not good enough. I'll have to do more research on where the major slowdown is coming from.

The reason I didn't actually start researching that was because I got sick and tired of having to quit the level in order to restart it, so I impulsively added the restart function, which is also the checkpoint system. I haven't added an actual checkpoint tile yet, but I could do it in 5 minutes if I wanted to since all the functionality is there. The game stores a chain of all of your past checkpoints, which is nice.

So why didn't I add the checkpoint tile if I was so close? Because I imagined that storing the states of an object mid-level could lead to interesting collision problems as opposed to the state of the object at initialization. And the focus of today was supposed to be collision detection and not optimization or checkpoints. So I finally got to work on making a "real" algorithm that resolves collisions as opposed to the workaround code I had in place before.

As of right now, the game can detect collisions from all directions, and it does a very good job of avoiding conflicts. I really must've coded the old collisions system horribly because that was so plagued with conflicts that I had to rely on buffers and other cheap tricks just to get around them. I haven't even implemented the buffer system yet and I don't have any weird glitches that let you stand on walls, for example. Although, there is this one glitch I noticed that involves jumping near a wall while facing left. I'll investigate that tomorrow.

I also played around with the styles system a bit more today, and I managed to get wall-jumping to work! I didn't even have to add any new features. That's how flexible this styles system is. Although, I did run into some trouble with some inherent flaws with the system, namely how annoying it can be to get the game to prioritize your settings in the way you want. Right now the priorities are calculated very similarly to real CSS priorities: the more stuff you have defining the style triggers, the higher priority it gets. Because this tends to incentivize convoluted style definitions, I'm thinking of adding a feature that will let users specify their own priority number to style definitions.


So tomorrow I'll look into that glitch I mentioned, and then I'll continue to flesh out the collisions system. Right now the system assumes every object is solid, rather than listening to the  

coll-edge-solidity

  property, and it does not resolve collisions between two nonstatic objects.

END OF DAY PROGRESS REPORT

So today I was separated from my laptop for most of the day as I let Haily play Skyrim on it. I used that time as an excuse to make progress on a blog post, since I've really been neglecting my blog ever since I've started this work-on-aeon schedule.

Today I worked for 4.2 hours. I was kinda disappointed, though, because all I really did today was fix glitches.

There were some really tough problems to solve with the collisions system and I'm really proud of how accurate it is, especially compared to the previous system. But there were also some stupid glitches that took way too much time to debug than I would have liked.

I've started implementing some more of the code that fixes collisions, but I've decided that I would work much more efficiently if I did it in the morning, rather than right now at midnight.

Tomorrow will be my last full day at home before I move back into my university dorm for the new semester. The features that I still want to add before the demo include: a pause menu (or at least something where I can't print all of the errors of a bad level code to), a camera system (will probably be the same fake camera system from the last demo), animation (you can already load assets in and manipulate them and it's all really flexible and awesome, but you still can't actually use them ), a real collisions system that responds to the customization options (definitely will get done tomorrow). I would also like to add more support for dynamic objects, but it looks like that's gonna have to get cut for now.

I'll probably spend an entire day getting the demo ready for release, writing guides, and making a generic demo level. This demo won't have a level editor like the last one, but thanks to the super fast load times now, you should have no problem using CaveMaker.

END OF DAY PROGRESS REPORT

I worked on Aeon for 7.1 hours today.

I finally made the "real" system that resolves collisions. As opposed to yesterday, the system now checks each object's collision properties so that it can determine whether or not the collision is "solid" (as in the tiles must not overlap). This means that the following style properties are now useful, despite having already been implemented:
coll-edge-top-solidity
coll-edge-right-solidity
coll-edge-bottom-solidity
coll-edge-left-solidity
coll-edge-solidity (shorthand)
can-use-ladder

The ladder one is useful because one of the possible values for the solidity is 'solid-ladder', which means it's solid to everything except to ladder-users, which is useful for recreating the same type of ladders that HATPC had.

I also did a little optimization work by getting rid of some static constants that I've been using. It stinks how AS3 doesn't have macros or anything else that will replace variables with constants at compile time, because referencing them at runtime is one of the slowest things in the language.

After that, I added a little thing of text to the bottom of the home screen that says "Aeon Demo | Version 4.0". If I really do continue working on Aeon on a regular basis during the semester as I intend to, I imagine I might release updates to the demo every now and then as well. Rather than giving each update a full demo number, I might instead just call them 4.1, 4.2, etc. I'll probably release Demo 5 when there's a significant enough update.

Then, I added another style property called  

z-index

, which only has two possible values: 'front' and 'back'. This is useful for stuff like making sure the player is in front of ladders and stuff. Although this is a bit primitive, since it only allows you two settings, but it's just a workaround until a more fleshed-out stacking feature is designed.

I also implemented a few other features that help you customize how a tile's collision-edges work:
coll-edge-top-buffer
coll-edge-right-buffer
coll-edge-bottom-buffer
coll-edge-leftbuffer
coll-edge-buffer (shorthand)
coll-edge-top-bounce
coll-edge-right-bounce
coll-edge-bottom-bounce
coll-edge-left-bounce
coll-edge-bounce (shorthand)
coll-edge-top-recoil
coll-edge-right-recoil
coll-edge-bottom-recoil
coll-edge-left-recoil
coll-edge-recoil (shorthand)

The buffer system was a pain to make. After getting the collisions system to work accurately without buffers and cheats, the buffer system essentially creates holes in the collision edges of tiles, which just yields a ton of glitches. I fixed most of the ones that I could find, but you'll probably find more of them, especially if you create some absurd buffer regions.

I then added some collision settings, which effectively add ladders and fake water-tiles to the game:
coll-effect-ladder
coll-effect-water
If you wanted to, you could create a really big tile, set it's  

z-index

  to 'back', and make set  

coll-effect-water

  equal to 'true', and you just added water to your level!

I also finally added the ability to crawl again. The feature was supported all along, but now PlayerBehavior maps the down key to that action. I also added a few more style properties to customize how when you can and can't crawl:
allow-enter-crawl
allow-be-in-crawl
The first one lets you set when the player is allowed to start crawling, while the second one can be used to kick players out of crawling mode if you don't want them crawling during a specific moment. For example, in HATPC you can crawl in mid-air as long as you start crawling on the ground. But if you were to set  

allow-be-in-crawl

  to 'false', you could effectively turn off crawl-jumping.

I also started working on the auto-crawl feature, which will keep you crawling if there's a block on top of you. So far this is turning out to be a very difficult problem to solve, and so far it just doesn't work.

By this point in my day, I had already accumulated about 5 or 6 hours of work time, so I really wasn't feeling like working more on such a tough problem. So I instead started working on a camera system. I went in thinking I was going to add a cheap, fake camera effect like the one in the previous demos, but I found myself implementing the full camera feature that I had already designed. Right now it still works like the cheap camera I had in mind, but all of the framework is there already so that I could easily add customization features later.



Tomorrow, I'll be travelling back to school. I'm not sure how much work I'll be able to do tomorrow, but regardless, I'm going to leave the auto-crawl problem until Monday, since I really need to tackle that with more time and focus. In the meantime, I'll probably continue working on the camera feature and get to work implementing the animation system.

Livio, do you want comments on this? I just want to let you know that I am reading, but I don't really have the knowledge to make useful comments, so I'm just letting you know that I am actively reading this.