I personally prefer Feynman. I have been using Newton and many deratives of it for quite some time now, but it has lately downed on me that it is pretty worthless. Many of its features work fine for scrubs, but now that I require professional physics it just doesn't seem to work anymore.
So I have been researching a bit in Planck, Einstein and other such stuff and I do feel that Feynman is the most comprehensive and usable of them all. I mean, Higgs is nice and all but it is quite unusable and many of its features aren't complete yet. But they are making great progress there, so I might switch.
They are also developing physics that try to combine the current major systems, but it is actually pretty worthless and it is far easier to just use those different systems seperately, even if you use them at the same time.

update! I'm gonna be focusing a lot on other Interguild stuff now, but I will manage to get around 30mins to 1 hour of Aeon coding per day because I've found time to do it in school. I've been bringing the files in a USB drive and then working on it in my graphic design room during lunch. It's definitely much more interesting to work on that than to sit around bored outside where the sun is constantly trying to kill you

lol, your sun is lame. OUR sun, that's a problem. she succeeds

We don't have a sun. Just rainclouds.

I've got this E-book through my university on Flash and Actionscript 3.0. I'm going to read it, so I might be able to help with some of the coding in a few weeks (or months).
Unless you prefer to code the game by yourself. I understand it is easier if you've coded each line yourself and know what it all does. In that case I might try a small game of my own.

Or perhaps Livio could assign you a task, such as designing boulder physics or the GUI or something separate to what he's already been working on.

But first I actually have to learn this.

that would be really cool actually. It may also help my college applications if I say that I programed a game in a "group", because that lets them see that I have experience working on group projects.

and about the code, I've been trying to keep it clean lately. I think I've got it decently organized (but it still is a little messy in some parts [nothing a few comments won't fix]) and I've tried to put more things into functions so that I can then make functions which do nothing but call a bunch of other functions.

Btw, I finally got a ton of boring stuff done/fixed/reorganized in the game. All of the buttons to "Quit", "Stop Loading Preview", and "Reload Map" work again, but in a much cleaner fashion. And I even fixed a glitch that happened with the collision-detection grid messing up.

And then I made even more progress. I also reorganized the way the tiles are created in the level. Instead of separate classes for each, they will all be inside one big jumbo class, which will essentially let us more easily mix and match options and classes and other properties.

AND I also got a huge part of terrain to work. When you create terrain, you have the option to set its fill to either a solid color, a patterned image, or a mixture of both (which means the fill would have some sort of opacity change on it), and you can also specify the terrain's border color and border width, and I think we'll also make terrain borer images, similar to how HATPC does it. But the point is that I got terrain borders to work! And I'm talking about how the border doesn't show up in between two touching terrain tiles.

I thought it was an impossible task, and it was a pain to code, but it works! And it uses my collision-detection grid to set it all up, which shows you how great that works too. (It was actually necessary for me to use that, since it's the fastest way to regain references to other objects in the display list, b/c when everything is created in a loop, variable references override each other, and your next best option is to give the object a unique name everytime and then call it up by name, but that's inefficient, as I heard, so instead I rely on the collision-detection grid, which is essentially a big array of grid tiles, and each tile keeps track of all of its objects-- and it's supposed to be more efficient, so it cuts back on loading time and on lag at run time)

By the way, here's a screenshot of my the awesome terrain borders. lol

Here the background is set to a solid red color, and the terrain has a solid gray color with a 3px black stroke. And that black bar with the red line under it at the top of the screen is supposed to be the bar at the top of the screen that shows all of the information like, how many points you have, attempts, etc. I still have to fill that up and make it look better...
and all of this was created with the game's level code...

This is about all I understand of that stuff about coding and classes and recoding, but good work because all this progress is really good..... Goodbye uploader glitch.

Uh, i didn't understand the image; the black background is set to a solid RED color? does that mean that when we play, we'll have a randomly set 20-30 pixel high red line? =\

can you make for example, a screenshot of what this code currently looks like, so that i understand better?
...:
  

What? Shos, the black bar is the terrain surrounding the level placed automatically, the red is the background, and the grey is normal terrain placed by the level creator.  

oh. XD
when he said the background is colored black, i thought that what currently is the backround will be red. stupid me; misunderstanding. nevermind, then.

lol at my last post. It was so late, I didn't even know what I was saying...

that black bar at the top of the screen is supposed to be the info bar, which will have your points on it, the number of power boxes you've gotten, and buttons to restart, pause, and quit. Obviously, I haven't worked on it much.... But at least my info bar will not overlap the level like in HATPC. I can see why they were being lazy with it though.

So the next thing for me to work on would be some image-compatibility for the fills and strokes of the terrain.... and after that, maybe I'd work on the player and its movements.

This game is coming along nicely, thanks to Livo.

Before I start doing stuff in the wrong language, you are using Actionscript 3.0 right? Not 2.0.

yup, AS3.

btw, I did a lot of stuff today. The terrains now have a tiled background (like how HATPC's terrain backgrounds are). You can select a solid terrain color, a bitmap pattern, or a mix of both. When you mix both, you can basically tint the pattern to whatever color and magnitude you want.

I also made it so that you can change the stroke of terrain to be on the inside or outside of the terrain tiles by having either a positive or negative border width. The default is 2 or 3 pixels on the outside, because I think that looks best. But if you make the borders really extreme, it creates some optical effects. But fortunately, the border doesn't add to the hit-test of the terrain tiles.

That's another thing, I've made the hit tests of objects more flexible. The objects now have variables in them specifying the points in them that should be used for hit-testing.

I've also finally begun working on the actual player/character/hero of the game, and its movements and controls, along with the big game loop that will update everything every frame, which brings me to an interesting question that I will bring up in another topic....

As for the player/character/hero, I'm going to make it similar to HATPC, where there is a "buffer" on the left and right sides of non-breakable objects, so that if you don't perfectly land on the block and land only on its corner, then you'll kind of shift to one side and keep falling. Like most properties of objects, this too will be editable. I'm also thinking of adding a buffer to the space bar command, so that if you press space like 2 or 3 frames before you touch the ground, then it'll jump for you when you land on the ground. It's supposed to make things a bit easier for certain traps (b/c I hate dying b/c I press the space bar just too early), but I guess you can change this option for the levels you make. We'll have to test the default setting, though, to make sure it doesn't make things too easy.

the game loop is working out pretty good. Right now I'm working on the collision detection. There will be two major functions that check for collisions: one for objects, checking for collision amongst themselves, and another one checking for collisions caused by the player. The player (when I say player, I mean the character/hero) is tricky b/c he is actually taller than the grids that I use for collision testing, so I have to test 6 points on the player, rather than 4. But that's not much of an issue...

The way the collisions are tested (you already know about the Grid that keeps track of immediately-surrounding tiles) is that each item has 4 points on it, which represents the four corners of the "square" that represents the "hit-able" region of the object. Then each object tests to see if each point is within the region of the 4 points of another object.

The way I coded it is that each point records the object that it has intersected with, and then after the collision tests are done, all the points are brought together to see which parts of the player/tile hit what object, and then it figures out what to do depending on the properties of that object. It's working pretty good so far.

A good feature we could use to differentiate our game a bit from HatPC:  have we discussed the possibility of characters being able to grab on to ledges and pull themselves up? It's pretty standard in most platformers nowadays.

Would you know how to do that?

probably, but that's something that'll be more suited to larger, more open-air platformers, where there's more running than figuring out how to beat traps.

That would be a sweet character specific skill. For example, I don't really see an armadillo doing that, but it would be very suitable for a cat.

Please no.  I don't like games that do that, and while it is more realistic, it bugs me and, just please no.  Maybe like Jell said, just the cat, though.

hey wait, if any character ever has a smaller jump height, edge-grabbing would make them much cooler to use. In fact, edge grabbing could have probably saved Armin from being super boring. And maybe wall-jumping too.

No wall jumping, either.  Grabbing ledges I can tolerate, but NO wall jumping.  They would make many traps cheatable.

not unless these traps are specifically designed for wall jumping. and it shouldn't be a big deal if these powers were reserved for certain characters

But what if you wanted that character for a cave, because of his, say, speed.  But you don't want the wall jumping.