For Livio to provide information and screenshots of what he's doing.

I've decided to make the editor a separate swf file which can be loaded directly into game window (kind of like how the pre-loader loads the game into its own swf), because the editor may be quite a large system, so it should load only if you plan to use it.

The single biggest thing I have to do right now is collision detection. So far I've found that it will have to be more complicated than I thought: all flash can tell me is whether or not objects are overlapping each other, so I'll have to track which direction the player came from, and which side of the object you are hitting. I'll also have to figure out how to make the collision detection test every object at once. I'll have to spend some real time on it one day...

Hm, you might also need to make a topic to keep a record of the characters you need to use for the code.

You could follow Jebby's original suggestion and ask for help on stuff like that on other dedicated flash forums. That would probably be a whole lot easier than figuring it out yourself.

actually, I just look up guides on the Internet. they are usually much easier to understand than forum posts.

btw, I think I finally got this collision stuff worked out. It sure seems more complicated than necessary.

I'm going to code the game so that you can re-size it to whatever dimensions you want, and everything will adjust to the new size. This means you can play full-screen if you wanted to. But this will be most handy when you're in the level editor.

will it make the screen look really weird, or will it be like in hatic, where it just allows you to see more of the levels?

It won't stretch anything out, but yeah, it would let you see more. but the menus might look small if you make it huge, unless I go through the effort of making the menu buttons move with the resize

Then I am totally fine with it.

Or you can simply have set dimensions. I don't really see the harm in that.

Well, I'd really like to have the editor have resizeable dimensions so that you can adjust it to your computer screen's size, and since I'd like to embed the editor into the game itself (which would allow you to directly test your levels), then I might as well make the game resize too for it to work. It's actually really simple to do. Takes no more than a few lines of codes.

End of Day Report: (ah, remember these?)
Today would have probably been better spent by actually starting the Video Archive revamp, which is much needed, or by reading that 600-page book for school so that I won't have to cram it in on Sunday, but as I said earlier I had this uncontrollable urge to work on Aeon.

I've begun working on the real official file for Aeon (not just another test file). In fact I already set this file up, but up until today I've been treating it like a test file so it was really messy. But now it's been cleaned...

Stuff in the file:
There's the preloader (which is actually a separate swf), then the title screen with only one button and that leads to the "demo".

The demo is actually the frame in the file that controls the entire game engine. So far in it, I've got a fake level map code saved as a string, which it then parses into a preview map like HATPC does. The level code that I'm testing with is 42x43, and the speed seems to be around the same speed as HATPC when it loads its map.

In that same page, there's also a link where you can skip the loading of the preview if you don't feel like waiting for it, and there's also a "reload level" link where you can refresh the level you're playing if the author made an update to it while you were playing it. And another link to go back to the main menu (later, I'll make this bring you to either the level select screen or to the userlevels thing depending on what kind of level you're playing).

I also added that feature where you can resize the file to whatever you want and it'll update itself. The level start page looks great with it

Stuff to do Next Time:
Next time I'll make a function that hides the level start "page" so that you can play the level (remember, the level start page is just a cover on top of the real level as the game builds it). Then I'll start working on the physics and I've decided that I will center the game's events through a timer instead of enter frame so that I can easily pause the game without too much hassle and to make checkpoint-programming easier.

New Stuff: When you're at the level start screen (the screen that says "Jump to Start!") if the preview map gets cut-off, you can use the arrow keys to move the map around so you can see it all

I also built the function that builds the actual level. For testing purposes, it just builds the preview map but stretched to full dimensions. But I have bad news: the map builder function is surprisingly slow Nothing too serious, though, my 42x43 map takes about 10-20 seconds to load, but that's just annoying. I don't even know why b/c it's just the same function used for preview but with different x, y, width, and height values.... But it does look like the closer it gets to 100%, the slower it gets.

Anyway, the next thing to do is to make the player and some tiles... which will also lead to the creation of the level code "language" since that's what I'll be using for testing. But I have a feeling that I won't have a lot of time to be on the computer today

Livio, I have a question. What's in the test map? Is it just an empty room? Also, how many tiles are in the test map and how did you design both the actual map code and the tiles?

right now it's just a bunch of number between 1-5. Currently, it just makes a new square and tells it to change color based on the number.

but it'll get more interesting soon....

I just found a great forum discussion on collisions. It was so great that I bookmarked it. It's a good thing I didn't get too far into my coding.

Anyway, it turns out that Flash's hitTest methods seem to be overly processor-intensive, and even though it takes more code, if you check for hits manually it'll work better and faster for when you have tons of objects. So it's a good thing we're not working with oddly-shaped tiles.

As for other stuff I did today:
I tried to make load times faster by compressing level codes. For example, 20 tiles of terrain can be expressed as "x=20;", so that the game won't have to read through so much text. I imagine that this will save tons of code (but only for instances where there are 5 or more repeats, otherwise it ends up adding code) but it also depends on the level you design.

For the game's level area, I got backgrounds to work. You'll be able to pick from background images that will then tile across the background of the level, and then move both horizontally and vertically depending on the character's movements. I also added an option where you can pick a solid background color for a background. And eventually, I'll add more options where you can add effects to the image backgrounds, such as hue shift, opacity, color overlay (which is only good with opacity), etc.

And when the level is too small to fit in the screen, you good old trusty white void comes up. I actually put effort into making this work like this because I wanted someway to tell the player that they reached the end of the map (b/c you shouldn't be able to travel outside of the level's limits) and by having the white void, they at least have an idea that that's not part of the level. Btw, the void's natural color is gray...

I also did some more visual tweaking, and started setting up the "info bar" at the top of the screen when you play a level.

Tomorrow, I plan on working on the collision system.

Well, i expect the new game level code would be something like N, mainly because of the overlapping?

not really. N's codes were built to work within a defined level size. Part of its code looks like it defines the main grid, and then it looks like there's another part for objects with custom coordinates.

N game codes are hard to edit Mainly because of the 2 seperate parts. The gmae reads terrain from top to bottom, left to right, as i'm quite used to hatpc, its very hard to edit. But you can put in extra values for the objects which causes amazing glitches.

I find what Livo has posted surprisingly interesting.

This all sounds brilliant, but could we have some screenshots? Even if it's butt-ugly, I'd like an idea visually of what's going on. Thanks.

couldn't agree more.  

I also agree.

!support

(inserts supportive adjective here)