Log In
Name:
Pass:
Online Members (0)
No members are currently online.
Current Interguild Time:
Mon Jul 6 2020 1:29 am
Member Chat Box  [click here to enlarge]
Recent Posts and Comments
ShareThis
« Blogs Index < Aeon Project < The Aeon Update Blog
« Livio's Blog

I'll be working on Aeon a lot this week because not only is it Thanksgiving weekend here in the U.S., but I also don't have a lot of school work to do. After this week, however, begins the final stretch before final exams, so I'll be very busy. During finals week, though, I think I'll have quite a lot of time. I only have one final that I really have to study for. After that, I'll go home early for winter break, but I may or may not have much time during break because I will be traveling to the Dominican Republic. Actually, if I remember correctly, last time I was there was when I was still learning the fundamentals of Flash and I had quite a bit of time to experiment with it. I believe that was also the time when I damaged my monitor so that it now has a white vertical line on the right side of the screen.

Anyway, today I reorganized Aeon's source files. Here's the new structure, for Isa/jell who may or may not be following these technical updates:

br.com.stimuli.*
--- This is a series of classes and sub packages imported from the BulkLoader open source project.
gui
---Btn
---BtnRecSolid
---BtnRecText
---BtnRndGrad
images
---no classes in here, just a ton of images from the "Graphics n' stuff" topic
init
---Aeon
level
---level.util
------FrameNode
---LevelArea
---VoidBG
logs
---ErrorLog
pages
---Page
---CreditsPage
---HomePage
---LevelPage

As for what this new build can actually do, the part that loads external content is pretty much perfected. I'm using that BulkLoader class I mentioned, and it's perfect for this situation since I imagine some levels will be loading tons of content. It also checks for errors in your XML and sends a description of those errors to the ErrorLog so that you may more easily fix them.

The ErrorLog is a pretty cool little class. It's basically just a big textbox with a close button (BtnRndGrad), but you can only create one ErrorLog at a time. After one exists, you can reference the error log from anywhere by doing
ErrorLog.getInstance();
If you try to create a new one, it'll throw an error, and if you want to create a new one, you'll have to call
ErrorLog.deconstruct();
, but this is all explained in the file's comments. The advantage to all this is, again, that you can reference the ErrorLog instance from any class without having to pass a reference around, which is very convenient because I'm breaking up the initialization of the level across multiple classes this time, as opposed to having a ton of code in LevelArea.as.

Btw, I built a quick CreditsPage with basically the same credits that can be found on http://interguild.org/aeon

Lately I've been working on the new foundations of the level classes. The LevelPage is in charge of loading the initial files, then passing the necessary information to the LevelArea class which forms the actual playable level. The LevelPage also holds the LevelEditor, which this time around will be an 'overlay' above the LevelArea.

I'm making drastic decisions about how the level will run. In the new XML, you'll have to declare a new <frame> and then put options within that tag. For example, see my Official Aeon Demo Level that I've been neglecting lately. It's still vastly out of date, and I don't want to update it because there are ideas there that I have yet to transfer to my notes, but there you can see the basic idea. The difference is that there will no longer by an <init> tag. The first frame is by default the init tag now.

Under this concept, the title screen will no longer be an object that is separate from the LevelArea. Instead, the first frame of the level or HUD or tile or whatever will be what you see under the title screen, and the next frame can be the beginning of the actual play attempt. For example, say you wanted the background to be red under the title screen, but green once the level starts, you would set the first frame of the background to be red, and the next frame to be green. Because the LevelArea is frozen while it's waiting for you to start, you will get the changes you want.

Why would I over-complicate things like this? Mainly because it allows for so much more versatility. Under this system you would be able to define much more complex animations of your own for the beginning of a level. For example, you might want the level zoomed out all the way and then you want the camera to gradually zoom into 100% view at the start of the level. Or you could make the level spin around once and then zoom in.

The HUD will also be a part of the LevelArea and it will be controlled completely through XML. Through the same title-to-attempt transition methods outlined above, you can make the HUD be a flashy title screen on frame one, and then a more conventional heads-up display on frame two.

As a fail safe against stupidly designed HUDs, pressing the Esc key will act like a pause button, and in that pause menu, you will be able to quit. The pause function should therefore also fire when you're viewing the title screen. Speaking of keys, you should be able to have complete control over what the key's do, with the exception of the Esc key.

It's gonna be quite a challenge trying to convert all these options into efficient code, and that's what I'll mostly be focusing on this week. It may be that I will have to give up some ambitious ideas, but we'll see. I won't upload the current files yet mainly because they're in the middle of being worked on and it's not like there's much demand for me to upload them anyway.
[?] Karma: 0
User Comments (3)
« Forum Index < The Aeon Development Board

Isa
[?] Karma: 0 | Quote - Link
Tuesday, November 23 2010, 9:05 am EST
No. I'm an octopus.

Age: 27
Karma: 686
Posts: 7833
Gender: Male
Location: Uppsala, Sweden - GMT +1
pm | email
Don't worry, I'm following the updates.

I'm worried that you're making too many options now - there's a non-trivial risk that a new player will be scared by how much you can customize. I don't think we need to have the option to rotate our loading screen and zoom in, and nobody will complain if that ability is left out. It kinda feels like you're just adding an excessive amount of things for your own enjoyment.
Livio
[?] Karma: 0 | Quote - Link
Tuesday, November 23 2010, 1:26 pm EST

Age: 27
Karma: 470
Posts: 9620
Gender: Male
Location: Arizona, USA
pm | email
yeah, I just thought up that rotate idea as I was typing in an attempt to provide more examples.

And we can avoid new player confusion as long as we present it correctly. The default editor will pretty much be as simple as possible, as if these options weren't even there. But you could also go straight into the XML and change things yourself.
Livio
[?] Karma: 0 | Quote - Link
Tuesday, November 23 2010, 3:43 pm EST

Age: 27
Karma: 470
Posts: 9620
Gender: Male
Location: Arizona, USA
pm | email
YouTube lets you load videos into your own Flash movies. I imagine that we'd be using this a lot when it comes to loading music for levels.

« Forum Index < The Aeon Development Board

In order to post in the forums, you must be logged into your account.
Click here to login.

© 2020 The Interguild | About & Links | Contact: [email protected]
All games copyrighted to their respective owners.