No this is a work-in-progress level, using those two tiles I made the DDA with. I may or may not finish it. It's possible in its current form, btw.

also if you have no side and you jump out of the grid, you're stuck.

I worked a ton on Aeon today. What I did was start implementing that new XML design that I've been talking about. Seriously, this stuff is so crazy, there must be literally hundreds of options for the "Player" by now. However, it's set up in a way that you don't have to define them all. In reality there are only about 13 unique options, but each option can have counterparts for when the player is facing left or right, or pressing the up, down, left, right, or space-bar keys. That's like 104 options already. And if that's not enough, they each have a crawling counterpart, so we're now up to like 208 options. And if even that isn't enough, you can set extra conditions, for when the horizontal or vertical speeds are less than or greater than certain numbers, so if you used this to double or even triple the amount of options you have, that's around 624 options.



AND that's only counting the non-visual options! I've added a very versatile system for building animations. The animation options are organized just like the other ones I just talked about, where there are counterparts for when the player is facing left or right, or pressing one of the 5 keys. You can add as many frames as you want, and you have tons of control over how each frame looks like, where it's positioned, how long the frame lasts, and you can even control if it loops and what frame it loops to. In all, that's around 11 options per frame, and if a well-made sprite was to have at least 3 frames per animation sequence, then that's a total of 264 options for standard counterparts, 528 with the crawling counterparts, and if you added 3 conditionals to each, that's a total of 1584 options for animation alone. Add that with the non-visual options to get a grand total of 2208 options.



But wait! There's even more!! That's just counting one state (you know, such as standing, falling, swimming, ladder-climing). So if you did all that for all four states, you'd have 8832 options!!!



OMG!



Lol, I think I made my point a long time ago, that this new XML layout will exponentially expand on the game's amount of customization.

lawl, i'm completely amused by the amount of : wtf :s. this is so awsome

so uh. can you elaborate on, WHAT those options are? are they numbered? if i'm duck-climbing a ladder with the up arrow pressed, what # of option is that?

I didn't want to elaborate too much or else I might end up with an even bigger post, but fine. Here's an example:

There are different levels of priority:
default
crawling
face left/right
keyboard: move up/down/left/right or spacebar

And each level goes into effect but it may then get overwritten by the level below it. For example, the acceleration of gravity (now renamed to yAcc) would be under default, but you could also set it so that you fall faster while facing to the right, so you'd set another yAcc option under faceRight. Or you could make it so that you fall even faster when actually moving down (pressing the down arrow key), in which case you'd set another yAcc option for moveDown.

I just haven't decided on how the keyboard categories would be prioritized. I figured left/right would be more important, followed by up and down, and spacebar is just added for the heck of it. I may or may not allow you to manually control these priorities, or even listen to other keyboard button presses.

But it's not like I have a humongous list of all the possible scenarios that you can set options for. It's really a much more flexible system. I spent hours today writing loops that would decipher the way the XML is written and then convert it into easily accessible variables that can be used in-game.

And there's definitely a risk that with all these options to test for, the game could get slow, but I think I've come up with a really efficient way to do it all.

But back to the example above, that <movement> tag is one of the three major categories of options I talked about. The others are <animation> and <collisions>. Here are the options I have so far for each:
The new "flip" option on the <image> tag lets you flip an image either horizontally (x) or vertically (y). And you can also rotate the image counterclockwise (I think) with the angle option. The offSets let you shift the image in any direction, so that the hit bounds may better line up with the image. The width and height control the image dimensions. I'm not yet sure if this'll end up being like how tiles dimensions work, or if the dimensions will actually let you distort the image. Oh, and the <loopTo> tag can be set to false, if you want it to just stick on the last frame, or you can set it to a number and it'll jump to the nth frame in the sequence. Good for if you want the walking animation to start a bit differently than from the looping.
I made it a bit more user friendly and changed the weird offX and offY, which used to be half the width and height, but now it's real width and height, so you have a better idea of the size, compared to the 32x32 grid. So far all that's here is dimensions, but I'll probably add things later for the Player's strength, as in, can they get killed by arrows? dynamite? explosions? spikes? I'm not sure yet how the destruction feature will work. I may give every deadly and destructive thing a number and if your strength is less than that number, then it'll kill/destroy you. I use kill and destroy together b/c tiles will also run off of that idea.

Lots of changes here. Note that negative numbers simply imply direction. Positive means it's either going down or right, depending on if it's y or x, respectively. Also it's worth nothing that the accelerations do not override each other, but rather they merge together. So if you have a default yAcc of 2.35 and a moveDown yAcc of 1.2 (let's say this is the falling state), the default yAcc will increase your speed only if the default yMaxSpeed allows it. Meanwhile, the moveDown yAcc can further increase your speed as long as the moveDown yMaxSpeed allows it. And btw, the <xBreaks> is just <ambientFriction> from the current demo.



If anyone actually read all that, please tell me that my typing was not in vain and that you found it interesting. Anyway, all this is subject to change, of course.

Your typing was not in vain.

First I was opposed to the customization idea, but after messing with the new debug menu I'm liking it more and more.
You just need to make an Aeon Lite, without all the customization options for the people who don't like/understand it. This version can also be distributed to other sites as advertisement and for you to earn a few extra pennies.

I'm sorry livio, your typing was in vain. i saw your huge post and skipped to jell's post, saw his first line and then read your last one, lol.

however I did read jell's post, and I like what he's saying. I don't know what livio said, but I assume that jell had some relation to it, so...I support that whole customization options in general; and what jell said about that aeon lite - this could be really cool, actually.


you know, this post reminds me the post i made when i quoted your idea, saying 'ignoring livio's post, i have an awsome idea' and presented your idea..

I'm sorry Livio, your typing was also not in vain. I agree with Sprout here, even though it's simple there are some people who wouldn't understand it at all. It's a bit interesting, but later on I guess it'll become more interesting?

Great.

I don't think the debug menu is a very practical way to edit these options in the real game, though. We'll definitely have to design a graphical user interface for the Level Editor so you can edit all this without having to know how it works (and maybe even add a place where you can do live testing, where you can change a variable and see it in use right away ). But what I'm saying is that having tons of options doesn't have to be so intimidating if the interface that presents it is nice and simple. Actually, the way I want to design the level editor is that it first appears simple and limited, but there will also be options hidden in it that can let you do all of this crazy stuff.

At first, I was thinking of not letting you edit the level code (or in this case, the xml in the debug menu) because with the editor, there would be no need for you to see it. But now I'm thinking that I should probably just keep it anyway, in case anyone ever wants to edit things that way.

you can have this bar or something, like in the sound control panel - where the player can move the level clicking the mouse, and then testing movement in a small window that won't take long to load.
that's like knytt stories. i support, but it'll have to be loads of work - consider that i still don't know how to make a level there.

Hey, I don't know why, but I feel we should leave those 'The Interguild' characters in the final version. As an easter egg, you know? A game can't be complete without a few easter eggs.

It doesn't matter whether we leave them in or not, because the final version (and I think the next demo, too) will allow you to load images straight from URL's, so you'll be able to use anything you want.

Well, there's always a chance it could be inappropriate... If you want this to be released to the general public...  

you can already post images on the forum, so posting them in your level isn't that big of a difference.

I've been working on Aeon lately. I'm still in the middle of implementing/making the new xml options, and these are just for the playable character. I'm also going to set up a default xml file that will include all the default options and settings so you won't have have so many options to copy over per level.

After I'm finished with this, I'll move on to the xml for tiles, which will also set them up for the new procedure for restarting levels.

Here are some interesting ideas I've gotten recently:

Up until now I have been hesitant to make something that will let you modify the debug options in real time mostly because I'm lazy. However, I'm thinking that I'll have to make such a feature eventually because of this concept that I just thought of, which is that things in the game can change after certain events. For example, when the door opens, the door will have to change its settings to change appearance. I could work off of that concept and let players make other tiles change in response to that same door-open event. And you should theoretically be able to change any part of the debug options. I could also let players create their own events, such as when a certain tile is destroyed, or when the player reaches a certain area of the level. This could eventually lead to that "keys" idea that was mentioned sometime ago, where collecting a certain object will open the path to somewhere else. You could make "power ups", where collecting one tile permanently or temporarily increases your maximum running speed. You could also make teleporters.

Another idea I got was to make the white void outside your level editable. You could give it its own custom colors and images, or you could tell the game to simply expand the level background. Or make it look like the terrain. This would of course have to come with more options with how the game will deal with the player going outside the level. Maybe it could act like a solid wall, or it could act like HATPC's invisible forcefield, or it could let you fall into oblivion, and maybe an option to automatically kill the player after a certain amount of time in oblivion.

Another idea I got was to get rid of the jump-to-start screen and to just give the player multiple options on how they want their level to appear as it loads. For example, they could just have the level zoomed out all the way so the entire map can be visible, or they could have it set to a specific zoom, or let the player zoom in and out freely. They could control whether or not the player could move the map around to see what's not in view, and if the map should be locked onto any one position. This of course can be complemented by the new white-void options, as a zoomed out level looks better if the white void is really just a continuation of the terrain, or the background. Another possible option for the appearance of the "load-level" screen would be to just display the beginning of the level, as if you had already pressed jump to start, just like in N, except that the camera will be zoomed in to the starting position as if you were already playing the level. And finally, the last potential option would be to show nothing at all. Maybe let people design their own loading screen, with their own artwork, text, backgrounds, level-name logos, images, etc. In fact, you could combine this last idea with any of the previous options, as well.

I actually approve of all of these things, but it sounds like a real pain to make all of those options, especially the ones regarding the start up.

The start-up options could be very simple, actually, except for the idea for custom designs, which is only slightly complicated. It's all simple compared to all the crazy stuff tiles could do.

I started a new blog for this, so this topic is now locked.