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

So I pretty much spent all of my computer time today working on Aeon. This post is to summarize what I did.

Technical Difficulties

The first few hours (most of them from yesterday) were spent just trying to get Flash Builder to work the way I wanted to. As you know, I got a new computer about two weeks ago, so I had to move over all of my files and settings from my old computer. When I tried to import my old Aeon project into my Eclipse workspace, it must've been corrupt or something because it made Eclipse start throwing NullPointerExceptions at me whenever I tried to look at my project files. It was a pain, but I basically had to just rebuild my project and put all of the resources in it.

However, this allowed me to start making it a truly ActionScript-only project. Previously, I had relied on an FLA file that had some images such as the Aeon logo saved in the library, but now I've learned out how to embed those into the compiled SWF purely through AS3. One disadvantage to not being able to use an FLA is that I can't use the components that come with Flash CS3, such as the TextArea that you see in the Debug Screen. Fortunately, I can probably find a replacement on the Internet for free.

Probably my favorite reason for not using an FLA is that compile times are drastically shorter since Flash Builder no longer has to connect to Flash CS3. So rather than running my tests in the Flash IDE, I've been forced to run them in a browser, such as Firefox, which isn't really that big of a deal. I did spend about an hour trying to figure out how to get Flash Builder to stop overwriting the generated HTML file so that the SWF could be embedded at 100% width and height while still relying on that file to run and debug the program.

I know you really don't care about those technical issues, but the point is that I lost quite a lot of time to them.

Catching Up

Next, I went looking through my old files, trying to remind myself where I was when I last worked on this game. I also had to organize long lists of ideas that I had accumulated throughout the school year.

Last time, I was in the middle of rebuilding the game. The problem was that the past demo had grown way too disorganized and many things were implemented so poorly to the point that they were acting as barriers against the addition of future features. Rather than reorganizing the existing code, restarting seemed like a much more practical approach.

Unfortunately, back then I had no experience in how to correctly plan out such a large project. My approach seemed to be the same as the first time, except this time I was simply avoiding the mistakes that were evident in the previous build. Although it was much more linear in that I would add a feature when it became visible. First I made the main menu, then I started adding the features that would go around the level area, such as the pause screen and the asset loader that lets you load images from URLs.

Fortunately, that's as far as I got. This means that I can start using the skills that I learned this semester to seriously plan this thing through. I may be able to start from where I left off, but even if I don't, it'll serve as a useful prototype on how the asset loader should work.

Design and Planning

While I was catching up on the Aeon project, I made some UML diagrams in order to document my plans as I remembered them. The act of making them helped me find tons of holes and problems that I had overlooked. For example, here's a small state diagram I drew to describe the major "pages" that the user may be in at one time:

The Browse Level page is where you can see all of the levels in the database.
The Game Page is the complicated area that holds all the stuff needed to make the level run.

What's useful about this diagram is that it specifies what kind of page transitions are possible and what could be the reason for those transitions. It was while making this diagram that I realized that there will in fact be times when the user will have to be on the Game Page and the Browse Level page at the same time, namely when opening a level he/she wants to edit. It would've been a pain if I had run into this problem after I had already written everything! My solution was partly influence by my desire to have the level editor support having multiple levels (this is a key feature that will affect the fundamental design of the level editor, so it's best to start planning for it this early). I decided to make the Game Page get initialized from the very beginning so that it exists throughout the entire time the game is open. As the program runs, all that changes is whether or not the game page is in focus. Meanwhile, the page will be coded in a way that lets it have multiple levels open and a way for you to switch between those levels. This may actually prove to be essential for that secret door idea that we decided on long ago.

These diagrams show some of the ideas that I came up with during the school year, but it wasn't until today that I had actually documented them. First, the level editor will appear on top of the Level Area (the space in which the actual level plays out in) and it'll basically let you edit the level directly, without having to use a fake representation of the level, like in the current demo. This means that you can playtest your levels instantly, without having to wait for them to load, and it also means less coding for me.

Second, the (Pause) Menu can be accessed at anytime within the Game Page. Whether, you're playing a level or editing it, you can use the pause menu to quit at anytime. The pause menu also has the error log, which is actually useful for reporting problems that may happen if you load a badly formatted level code, or if some of the assets you tried to load no longer exist.

Third, I conceptually merged the idea of the Jump-to-Start screen, the win screen, and the on-screen info that shows up while you play into one big category called the HUD. The reason for this is that I eventually want to make these three items customizable in some way, so to make it more user friendly, I imagine that it would all be handled by the same editor, or the HUD editor. I know this really isn't all that important to Aeon yet, but it's a good idea to write down for now.

This is actually kind of messy. I know that we were planning on having some kind of Advanced Editor to contrast with the Simple Editor. It may become clearer when I start designing the user interface for the editor and figuring what options will be needed, but right now I'm not sure exactly what would be included in the "Advanced Editor". Would it simply have more options and panels on screen at once? Or will it just have buttons that open dialog windows with more options? Perhaps one of those windows would be complex enough to be called the "Tile Editor"?

I guess it'll all be figured out when it needs to be, but the second thing that this diagram captures is the idea that one would be able to play a level, pause it, and then edit the level as it is without having to reset it. This is one of the advantages to having the level editor work with the Level Area directly, as it could be used as a true Debug mode with real-time editing.


I made some other diagrams as well, and I even started working on a class diagram so that I can figure out which classes I'll need to write and what kind of dependencies they'll have with each other. However, this diagram is still in its early stages.

The last chunk of my time today was spent studying how I was going to make Tiles work. I was thinking of all the features that every tile should be capable of and it's actually very hard to find an elegant way to represent these features as a set of rules and options. For instance, the player's horizontal run speed can change depending on whether he/she is underwater, but it also changes if the player is standing and if it's crawling. It seems like I'll have to end up relying on special cases, which could end up causing a lot of confusing glitches. I guess now I see where all those glitches in HATPC came from.
[?] Karma: +5
User Comments
« Forum Index < The Aeon Development Board

There are no comments yet, so feel free to be the first to comment.

« 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.