AS3 plataform engine (getting ideas)

[Eddie]

hey, so i want to make an flash AS3 plataform engine from zero.
This will suport H-games, like the mario-rape style.

Hope the engine will work good. Thats why i'm planning alot, before start to code (downing flash CS5 right now). This engine will be fast and smooth, but it will not have alot of features.

So, i'll describe what development kind i'll use, below:
______________________________________________________________
I'll work on 2 project:
- The Engine
- The Cene Maker

The engine (aka. game) will have, inside it, all the 'cenes' that will be used. The 'cenes' is nothing more than code, saying what and where images, characters and collisions will be used, all information that an cene needs.

What will 'generate' that information will be the 'Cene Maker'. Using it will be easy:
Just on the flash, with the CeneMaker.fla, you will import images, characters and collision boxes to the stage. Then you run the .swf, and you will recive the generated texto from that cene, informations like:
- Char used. Char that may be used (explain later).
- Images used (static images [background, plataform, etc], animated images (animated plataform, etc).
- Boxes (where chars can walk).
- Events (I havent planned this yet).
Thats all I can get, before i start to code. Thats is necessary, i'll say again, for imagem caching, image merging, image disposing (yea, will have some BitmapData class work). Also, collision will be independent from images, so we can optimize that.

So, for now i've seen how the CeneMaker will work. Lets take a look in the main Engine.fla:
- Splash screen, menu, etc.
- cene list.
We also will have more .fla, like:
- Chars.fla
- Images.fla
Not done yet. Each char and imagem will have its own .fla:
- CharA.fla; CharB.fla; ..
- ImageA.fla; ImageB.fla; ..

Finnaly, we will analize the Char.fla and Image.fla, what information must be inside those files. Lets see CharA.fla:
- Name. For example: "CharA", or "CharB", or "CharA+CharB". That kind of name will be noticed, and the engine will think 'ah, looks like the CharA is the hero, and CharB is the monster. When CharA and CharB colide, CharB will rape CharA. CharA and CharB dont exists anymore, and we have "CharA+CharB" as a single character', wich will be the rape animation, noticed as character.
Lets say that "CharA+CharB" (rape) collides with "CharC", then the engine will look for "CharA+CharB+CharC" character, an gang bang.
With the CeneMaker project, he will cache all the characters that is in the cene, also, he will look for all the possible group rape, and cache it. That should make things really fast.
Lets keep going, we are on CharA.fla proprieties (code inside MC):
- Name (already said).
- Box. Just an rectangle. For now, this box is static, just follow the char (if the char moves around).
- Something to care: Timeline animation. The animation must happend only in the charA.fla timeline, not inside another MC's. Thats because the cache system will save every frame of the animation in an BitmapData vector list, and we will have an faster rendering, more fps.

For last, we have the imageA.fla, that have:
- Type. It can be "static" or "animated". Both will be cached to bitmapData's, but in different ways.
- Speed. Its just the speed in relation to the hero. If the image is an background, the speed should be less than 1.0 ; if its part of the platafor, the speed should be 1.0 , that means that the image will move the same portion that the character moves. This propriety will also be noticed on the image cache system.
- Layers. This can be a number, an string, whatever. Some layers example, in order: background1, background2, charLayer, frontground1, frontground2. With that, we have all information we need to make an really good image caching system.

Last words:
With that system style, the development is easy for developers and for coders. I mean, when you have just an 'CharG43.fla' update, the programmer (or other designers) dont need to download everything again.. just that single .fla file, and just have to replace it on the project source.
__________________________________________________________

Alright, this is big. But its just the planning before the coding.
I hope designers and programmers say what they think about the engine, basead on theyr experience, or ideas.
if u dont got something, ask and i'll try to fix it.

When the planning is 100%, we just 've got to code :3

[Favelor]

teleportation is a HELL NO! make the lazy SOB walk! as for your title...make a plataform engine. who stopping ya?

[Renara]

Well it partly depends on whether you want to wait for v0.3 or if doing it yourself is part of the fun, as v0.3 will have a modularised (broken apart) file structure, separated code package(s), a fairly capable physics engine as well as a ton of other stuff. It's one of the parts of the game that's taking the longest to do, partly as a mix of me never having enough time, and certainly overdoing many parts of it (in a good way).

The main problem with v0.3 is that we have no release date, and won't until we're right near the end, and even then we might not bother setting a date, as it usually invites trouble with open arms and gets missed as a result

If you're looking for hints on the physics side though; flash has some built in capabilities such as symbol clipping, which is nice and straightforward, and pretty fast since it's just a rectangular collision, nothing complicated there. If the areas that that produces aren't ideal then you can code it yourself fairly easily to create rectangular areas smaller than the item's actual size, it's actually possible to just use simple, visibility=false symbols for such a purpose as well since they won't render, and flash's built in clipping function is marginally faster than doing it yourself. I think someone detailed a per-pixel clipping method somewhere on here, but that's usually overkill unless you absolutely need that kind of precision, most of the time you can get away with just defining some simpler shapes and using them to detect the collision.
For an efficient physics engine you'll want to do low-detail collision detection first, then use a more precise method. The simplest collision to detect is a circular (or spherical) collision; so for example if you have a character whose height is about 200 pixels, you can use a circle of maybe 125 pixels in radius to very roughly work out if a collision is about to occur, and only if it is will you then go on to do rectangular or even more precise collision detection, as this allows you to quickly eliminate objects that you can't possibly hit.

For v0.3 I went and increased the amount of work I needed to do by going and doing collision in three dimensions, but fortunately I have a background in that

[Eddie]

thx 4 advices :3
edited my post :p

For the rendering.. i'll use the bitmapData class's copyPixels(). Its much more faster than the defalt flash's rendering. example: http://wonderfl.net/tag/copyPixels

For collision, i never get much into that ><' for the beggining i'll just use 'rectangles'. The thing is that all the collision information will be code, just Rectangle class. But the collision, for a first look, will be static. Will just follow the char.. and will have some optimizations, like i'll make here: http://wonderfl.net/c/zgaG

[Eddie]

Well, I'm starting towork on all that, just to see how further i can go. Sorry for the 2x by the way.

First, i had to test the cene maker, where people actually will work on the scenario. I got troubles, but its working:
- Create an .fla for each char. In that .fla, we have the char mc in the libraly. Just copy this mc to the cenario libraly.
- Then, we can acess all DisplayObjects (incluing mc's) that is on the stage. Take a look at the cene maker's timeline:

Code: Select All Code

import flash.display.MovieClip; import flash.events.Event;

var num:int = this.numChildren,
i:int = -1, mc:MovieClip;

this.addEventListener(Event.ENTER_FRAME, ef);
function ef(e:Event):void
{
   this.removeEventListener(Event.ENTER_FRAME, ef);
   look();
}

function look():void
{
   while(++i < num)
   {
      mc = MovieClip(this.getChildAt(i));
      trace(i, mc, mc.type)
   }
}

So, now the explanation:
- Import used class; num for the num of childs that the stage haves; i is the child index, so yeah, we can work with the child of any mc; and mc is an temp mc.
- Then we add en event listener, to execute only once. idk why, but then we can acess the mc's proprieties, like 'type'. So, the mc (in libraly), its timeline must have an 'var type:String = "char"', for example.

well.. so far, its going pretty good. That mean that the cene maker stuff its actually possible, and the scenario making should be easy. If some char have an update, you just DL that sinle char .fla, go to its libraly, copy its MC and then replace in the cene maker libraly.
__________________________________________________________________________________________________
edit: More planning progress:
Cene Maker:
note: Every MC must be exported to AS. The Class name & MC name must be the same.
- mc.type
- chars used
- Images used
- Boxes
(for char)
- char.name (example: CharA or CharB or CharA_CharB)
- char.x, char.y
- char.prop (speed, [actions keys frames])
- char.team (value, [allyTeam], [enemyTeam])
- char.collision (box for the collision check)
note: Every char has an 'walk'. For ''+'' chars, there's an 'end' key frame.
(for image)
- img.type (static or animated)
- img.child (layer)
- img.box (position and dimensions)
- img.speed (1 = player movement * 1)
{make cached img for each child; for each speed;
each for animated, one for static}
(for boxes)
- box.box (position, dimensions)
- box.event (can be null or talk or teleport)

Engine:
- cenes