The purpose of this topic is to collaborate and organize the construction of Aeon. Rather than uploading the current build of the game and working from that, I think we should start fresh, while progressively importing code from the current build. There are several reasons for this:
--the current build was put together rather sloppily, with a priority on playable results rather than long term planning.
--there are no comments anywhere in the code, so reading it is tough, especially when considering that things weren't well planned out.
--so starting new will help us better organize the game and it could teach collaborators about how certain parts of the code work.

So if this is how we choose to do things, I think that the first thing we should do is organize and define the XML settings, because these settings will be the infrastructure for how the game functions. So any drastic changes made in the future will be annoying.
More info on the next post

INTRODUCTION TO THE NEW XML

The cool thing about this is that you don't even have to know a programming language to help.

The current XML structure is really nothing more than a list of a few limited options. However, I hope that the new XML structure will be much more, almost like a mini-programming language, where you can set settings that change based on other settings. For example, remember that big post I made some time ago calculating the total number of possibilities with the version of the XML I was working on?

So for the new design I'm thinking of dividing all the options into three areas:
1) Assets -- defines imported images and sound files so that they can be referenced by other settings.
2) Level Properties -- includes info like title, dimensions, level code, backgrounds, etc.
3) Tiles -- Includes all the tile definitions, including the player which is just another tile.


ASSETS:
You need to assign an id name for each asset imported so that it can reference it later.

For importing images:

<image id="[NAME]" link="[URL]" />

For importing sounds:

<sound id="[NAME]" link="[URL]" />

The mask option is a cool new idea I got. You know how the terrain has its own pattern that continues onto other terrain tiles? Well, why not let people create their own sets of mask patterns and have other tiles implement them?

<mask id="[NAME]" image="[IMG ID]" color="[#RRGGBB]" colorOpacity="[%]" />

And perhaps we could use an asset for generating text in the level.


LEVEL PROPERTIES:
Level Code: (We can discuss the actual level code later)

<lvlcode width="[INTEGER]" height="[INTEGER]" frameRate="[0.01-1000]">[LEVEL CODE]</lvlcode>

Level Background:

<background image="[IMAGE ID]" color="[#RRGGBB]" colorOpacity="[%]" />

Level Boundaries: I'm actually not sure how this should be done. It may be best to consider how this works after we've planned how tiles will work. If you don't know what I'm talking about, it was that idea of different options on what the game should do when you walk off the edge of the level.

Also there will be several more options to help you customize the things like the camera and start screen.


LEVEL TILES:

This is very complicated, and this is where the bulk of the discussion will take place, as we will also be planning how tiles work at runtime. Unfortunately, the current tile design is lacking planning in several key areas, such as tile collisions, and there are flaws in its organization as well.

Well, I don't have much time to include any more details right now, but I'll post more this weekend.

I could help. i have had some experience with coding in the past

what language(s)?

Come on, Livio, I was planning to learn from your coding that you've already done on Aeon. I really want you to upload the current Aeon build so that I can study it. It seems to me that you don't think the actual coding is flawed, just the way it is set up (without comments and so on), and we don't need to do everything once AGAIN because of that. It seems much more convenient to just look at the code, figure out what X and Y does, and then add comments, maybe restructuring if something's placed in an odd position. But I DON'T want to start the Aeon project all over again, and apparently, I got at least three persons on my side (the ones who minus rated you).

So yeah. Just upload the current file, please.

Make that 4, I just didn't feel like lowering Livio's karma anymore. But yah, it seems like everytime we get some where in Aeon, there's a reason to start over again.

mosly htmal but i have made a mini flash game before

*html

Jorster there is something called the edit button.

yes i know i tried that but accidentaly quoted it so then i edited the quoted comment to spell HTML rite

You press the edit button. Is pressing a button that hard to do?

no we're not starting all over again. We're organizing the code that we already have by going through it and figuring out if it should be redone. Because I skipped over so many things while building the game and I don't think it's a good idea to build on top of all those shortcuts I took. The new file thing is just something procedural, where we can have more freedom to do the necessary changes without being limited to all the other problems in the code.

I recommend each tile has its coordinates set in the level code. When the tile moves, its coordinates are reset. When a checkpoint is reached, the game stores each tile's coordinates in an array or similar, so they can be reset. Each tile should also be given a unique id. A "locked" feature would be useful too, so some stuff falls, and some stuff doesn't. Things could fall when the game starts, and if you save the game in the middle of something happening, everything will still fall where it belongs... especially if your save feature also saves midair arrows. Furthermore, it wouldn't be a bad idea to have a rotation setting, so you wouldn't need 4 different types of arrows and stuff. The rotation attribute should only apply to things where its orientation matters, EG arrows.



If you're going to use custom pictures, you could also have an "image" attribute.

Is that what you're looking for?

EDIT - Also, I agree with Isa. You shouldn't restart. Work with what you have, then make minor changes here and there for optimization. You can optimize without starting over!

heh, you guys don't seem to know just how entrenched these problems are. I tried fixing them before and it's just way too much work. I figured this method would be much less work-intensive in the long run.

and Deku, the problem with your system is that there's way too much code involved. Actually, your <tile> tag is dozen times more simplistic than mine, but that under your system, we would have to have a <tile> tag for each individual tile in the game. The system in the current demo is much more favorable in that you define one tile definition, give it a one-character id/symbol and then the map code is just a sequence of those symbols, with its location telling you where it should be instantiated on the map.

How inefficient would my version actually be? If it has more code, I think that's okay as long as the game runs faster. Would it just slow things down?

Also, look at this:
http://www.actionscript.org/forums/showthread.php3?t=150617

It may or may not be relevant, but it looks like some minor changes can hugely optimize XML in Flash. Maybe you're making the same problem--it's worth a look, just in case.

I'm not really thinking of it in terms of the game running faster but in that your level files may get ridiculously huge. These files are already quite huge in the current demo, but at least you only have a few tile definitions, as opposed to one for every single instance of that tile in the game.

And the XML will only be used once by the game engine. When it creates the level, it parses the xml into all the tile's variables, which is much easier to manage.

Let's discuss the way tiles actually work so that we can figure out how to make their XML.

"Tiles" are basically any object in the game, including the player. The reason they are all merged together under one object is so that they can share properties and make customization much cooler. Under this definition, tiles should be able to do the following things:
-collide with other tiles and respond appropriately, depending on the two tiles' collision settings
-respond to events (keyboard presses, collisions, door-open, anything that can lead to an 'event'
-destroy other tiles
-be destroyed
-fire events that the game responds to (player death, power-box/fuel-cell count)
-fire projectiles

So far, all the game can do is detect collisions, and the fact that the player can respond to keyboard presses isn't set it up in a favorable fashion. In fact, right now the player is its own class, it's not even part of the tile class.

As for the XML structure that I've been working on lately, I've noticed that it's still not as open as I'd like it to be. Sure you can have the tile behave differently under keyboard presses, but now as I consider using that system for other events, it's less than ideal. It also has a pretty confusing "state" system, which I'm thinking of getting rid of entirely.

Instead I think we should do something like:

and maybe somehow you can mix and match those if's and do something like if(this && that) or if(this OR that) and perhaps let people put if's within if's like:  

if(){ if()//stuff else //other stuff }

I'm not sure how we'd translate that into xml code. perhaps something like this:
  

So under your definition projectiles are also tiles? I would make the distinction between tiles, objects and scenery.
Tiles are "solids". If another tile falls on it, it will land on top of it. Crates, boulders, terrain and power boxes would be examples of tiles.
Objects are "interactable non-solids". If these come in contact with a tile or another object, an interaction may happens. The object can get destroyed, the tile can get destroyed or something else. Spikes, projectiles, monsters, the door while opened, explosions and the player are objects.
Scenery don't interact with anything. They are just there for the scenery. Such as the background, the door while closed or the debris that flies around when anything gets destroyed.

Yes, projectiles are other tiles, which means that tiles should have the ability to instantiate other tiles.

But I don't think we need to make that distinction between tiles, object, and scenery--at least not for the game's programming. We can have a setting for when a tile never updates, thus making it an object/scenery, and another setting for when it doesn't react to collisions, thus making it a scenery object.

You're seriously overcomplicating this. I could cleary understand Dekudude's idea, but have no ide about what is meant to happening in yours. Anyway, I know that this is the wrong place to post this, but, you should've added sound effects and music to the previous demo, certainly they should be in the next one.

yeah the reason for the way I'm setting things up is to maximize the amount of customization you can do with the game. And yeah, we should really get to work on sound.

Btw, I wasn't planning on uploading the files right away b/c I figured they could be a major source of confusion. If we were to follow my approach for making a new file and importing the code by pieces, I thought I could not just introduce the code, but also talk about all the problems with it and any possible solutions or alternatives at the same time. That would allow us to focus on those parts individually, enabling us to set the perfect foundation for the game.

But if you really want to see the files, I can upload them. I have a few sets of files, actually. The one I was working on doesn't compile, but I also have previous builds.

here are the files:
http://www.interguild.org/aeon/aeon.zip
http://www.interguild.org/aeon/aeon_old.zip

Nice!

Now to check and analyse, and hopefully understand.

in the meantime, I'll be working on the level database....

It'll be a while until I can look into this, I need a newer Flash version.

So yeah, Livio, don't expect me to do much. I hope this will be easy to learn.