you don't really need Flash, since the bulk of the code is in those .as files. Although that would mean that you wouldn't be able to compile the swf. However, you could still write your own code, test and compile it in a different file, and then I could implement it into the game.

I'm removing myself from the list of programmers, until I actually start to do something useful. I don't want to raise the expectations you got just yet.

If you're worried about size, just compress it all, like so (sort of like Hannah too):

0> (the game can detect the coordinates)
<tile id="[int]" type="arrow" setting="wooden" locked="[boolean]" rotation="90" posx="[X-coordinate]" posy="[Y-coordinate]" />

.>
<tile id="[int]" type="arrow" setting="metal" locked="[boolean]" rotation="90" posx="[X-coordinate]" posy="[Y-coordinate]" />'

You could have little things that represent other little things. A zero could be a normal, wooden crate. A period could represent metal. Etc. Then you could have a script decipher it all. In my mind, that would be the easiest, fastest way to do it, and I can't imagine it screwing with the game's load speed too much either.

wait, I'm not sure what you mean by that. Is that the level code (the code that tells you what the map will look like)?

you know the argument for focusing on the game itself, and leaving for things like how switching between pages for later? That's actually what I've been doing, and why I took so many shortcuts, but because of that, now changing it to something worthy is getting more complicated an annoying. I read in a book somewhere that skipping around like this is like accumulating debt, and the longer you go without paying it, the more time you end up paying for it in the end. That's why I want to start a fresh file to clear all the mess that accumulated.

Also a note on how collision testing works:

There is an invisible grid covering the entire level. Each grid is 32x32 and it keeps track of which tiles are in it. When a tile moves around, it calculates which grids it should be inside of. Then it adds that tile as being inside that grid. Then it tests to see if it had collided with the other tiles within those grids. That way, you only test for collisions with tiles that are nearby as opposed to every tile in the game.

Actually, tiles don't do this at all. Only the player tests for collisions, and as I've said, we're getting rid of that class, and the player will become just another Tile.

After the restructure that I now think that you should do, the first thing to be added should be comments on what everything does, although it isn't too hard to understand if you just try a little. It's easy to guess what the variables do due to the good names you've given them.

Nevertheless, giving everything at least a "headline" would be helpful.

"After the restructure that I now think that you should do"
yay, so remove those negative ratings

I was getting stuck on a design for the level database anyway, so I'll work on this instead. I'll publish my work and ideas here as I work.

Easy now, I never rated you down.

I don't ant to start all over again. And 5 people agree with me as the post has -4 karma. The post may have -4 karma, but there are 6 votes in total.

-1 -1 -1 -1 -1 + 1 = -4

but we're not starting over again! I explained that in the last post. Starting a new set of files is just a procedure we're using to organize the code we already have. There are pages and pages and pages of this code, so it's not like organizing it would be an easy feat

Isa which version of flash do you have?

I have MX 2004 >_> We used that in our programming class where we learned AS 2.0. Not cool. I am currently installing the trial version of Adobe Flash Pro CS5.

Have you tested the missile and nitroglecyrin coding yet?

for some reason the earliest version CS5 can save to is CS4. That's kinda lame. But your flash is way too outdated anyway.

Btw, you can try getting Flash Builder 4, it's free if you're a student, and it would at least allow you to compile .swf's after your free trial is over, but you won't be able to reference the stuff in the .fla's library.

edit @ dbx: no

DBX, the most advanced object we have is breakable crates. As far as I know, crates aren't even influenced by gravity. Do you think that missiles and nitroglycerin objects is high on the list of Livio's things to do, considering we still don't have basic things such as arrows? I don't.

The missiles are the arrows far as I know.

Ok, Livio, I guess fixing the code is fine. Your 1st post was a bit misleading (I didn't -karma you, though), but as long as this'll benefit the game. I don't want Aeon to end up like my country's national debt.

lol, well I probably didn't put much effort into explaining it b/c I had already explained it somewhere else.

anyway, I think I just spent like 20 minutes trying to sort out this problem I was having with my files. Now I'm really starting to work on the code...

The game I am now mostly wasting my time with is Dwarf Fortress. An incredibly complicated Rogue game that is still in the alpha stage. It is being created by a single coder, Toady, with some help from his brother. It has been in development since 2004 (I think) and is now roughly 31% done. This game is basically Minecraft's older brother (almost literally, Notch started Minecraft as a Dwarf Fortress/Sim City hybrid).

Every month or so Toady releases a new version. And although the game is very much playable, there are still several outstanding bugs. They can mostly be played around, but they're still annoying. However, Toady doesn't really like bugfixing. He would rather add exciting new features. If a game breaking bug appears he will fix it in a couple of days, but he tends to postpone the less important bugs to later.
The problems arise when he eventually gets around to the bug fixing. Instead of being from fresh features, these bugs are now embedded deep in the code. Fixing these bugs is possible, but because much of the newer features are build on the older features, fixing these bugs will usually create new bugs in the other features. And then fixing these bugs will cause even newer bugs. And so on.

By only adding new stuff instead of cleaning up the old stuff, you will only dig yourself a hole that will be get more and more difficult to climb out of. Livio worked by adding small bits to the code, creating a code that existed out of many separate bits instead of one whole. Instead of creating the stable structure you would want, this instead creates a fragile shell. While it is faster to build, it will eventually collapse down on itself. And once that happens, fixing it will be close to impossible.
Livio has now reached a point where the code is getting too messy and complicated. So what Livio is doing now is streamlining the entire project. While on the short time this will cause some delay, it will make sure that there won't be any significant problems on the long term. It better he does it now, then waiting till the entire thing crashes down.

Right now I'm trying to figure out how my Btn class works. It draws the buttons that you see around the game, and it wasn't put together very well.

Don't forget to add comments!

yeah that's why I'm trying to figure it out, so that I can add comments. I guess it's unimportant, but what if we want to change it one day? I read in another book that you always have to plan for change, and so your code should be easy to change. And I find it hard to believe that the way buttons look like now is what we'll use in the end, so if we ever wanted to change how they looked like, it could be really annoying.

You know what, I'm gonna just make a Button interface, and then we can make classes that implement it like MainBtn and DialogBtn (for the dialog boxes in the editor)

Hey Isa, if you want to try making something simple, maybe you could try making a pre-loader for Aeon? According to most tutorials, a preloader is just a small flash file that loads the main swf.

I'm willing to do that in a while, but not now. It's 00:52 over here, but maybe tomorrow?