|
-
Flash 9/AS3 scrolling engine, preview version
Here is a first version : http://gamesquid.com/TileSQUID/TileSQUID.zip
It has one type of layer implemented (TileLayer), and two types of tiles (Tile and SuperTile). Check the Game.as file to see how to work with it. This has an array with the map, but I plan to add support for at least one map editor (Tiled), which uses an xml format, so you'll be able to import your maps from external files. But that might take a while.
Keep in mind that it's the first thing I ever did in AS3 (not even a hello world before it), so there is definately room for improvement. There's also almost no comments in it, which I know is bad, but you'll have to live with that for now.
It doesn't compile when you set actionscript 3 to strict, I'm not sure if I should try to fix that or not.
And I know the example implementation sucks, just a few boxes.
Any comments?
Last edited by Fall_X; 07-05-2006 at 07:12 PM.
-
Ow yeah, about the cache option on layers, this will use cacheAsBitmap on the layer. This is not very efficient when the layer is update a lot, so you should probably only use it when you have large tiles (so they don't have to be replaced as much) - or supertiles.
So when you want a map composed out of a lot of small tiles (for instance, I'll be using 24x24 tiles in one game), you're best of to group them in larger supertiles of about, say 128x128 pixels or more, depending on the scrolling speed, and use the cache feature. This should make sure that it won't have to update as much tiles when scrolling, and the scrolling itself should be faster because of the cacheAsBitmap.
I'll probably add a loadMapFromGrid function which uses a 2 dimensional array as input, and with an option to automatically create supertiles out of it, with a size you can specify.
But first I'd like to know what you all think.
-
Heli Attack!
It looks nice, from the looks it's extremely similar to Squize's scrolling implementation (keeping all the tiles in one array, and then using a smaller boolean array to flag visible objects), props for being what looks like the first to port it to AS3!
-
Senior Member
This is some what off topic..
Now that every one will be getting into the swing of using AS3 do you think this will bring the market value up... To me it almost seems that its going to be alot harder for (Sorry to say) no-hopers game developers to make crud games with crud code.
Learning any programming languge takes some amount of dedication, AS3 will take alot more of it to learn, im was just wondering if this might up the quilty of flash gamming...
92.7 Fresh FM for all your South Aussies - Doof Doof music FTW people!
-
M.D.
i was also thinking that, but basically if there's crud games now, there always will be, no one is enforcing people to use AS3, some might not even care, i think its going to be something that a serious game developer will tackle and not the others who just want to get something on new grounds.
So yeah, quality will go up in areas where it due. Gaming portals will probably stay the same, except for the od programmer that has decided to laern the language
-
Senior Member
Cant see how AS3 itself improves Flash games. Just because it follows ECMAScript standard or is OOP doesnt make games any better. I actually see leap from AS1 to AS2 bigger then AS2-AS3. Pretty much everything you can do with AS3 can also be done in AS2. I also have not yet seen any significant speed increase in AVM2, the perfomance in drawing the graphics is same as before and while the code executions may be faster there are very few games running so much code that it slows down the game.
The main problem with making AS3 complex and "mature" as every other programming language is that when someone is able to write AS3 code he can write same code in any other programming language too. And if he can program in other language why would he choose to use Flash? The AS1 was much easier then other programming languages allowing people with no previous programming experience to write games. AS3 is not something you pick up in days and when you need to decide to spend next couple of years learning AS3 or some other programming language there isnt many good reasons to go with AS3.
-
It looks nice, from the looks it's extremely similar to Squize's scrolling implementation (keeping all the tiles in one array, and then using a smaller boolean array to flag visible objects),
Never seen how Squize handles scrolling, but I am aware that my engine is similar to Strille's approach (I even credited him in the source for one important function). To my defense, my AS2 engine was something I came up with entirely on my own, and it was also pretty similar. Turned out it ran just a bit slower than Strille's engine, so I decided to look at his tutorial and learn a few tricks - which is what it's there for, right? 
Thanks for the props!
Cant see how AS3 itself improves Flash games. Just because it follows ECMAScript standard or is OOP doesnt make games any better.
Well, you need to be a slightly better programmer to work with as3 - but a better programmer doesn't necessarily mean a better game.
However, in AS3 it's easier to organize your code properly, which will benefit all of us.
I actually see leap from AS1 to AS2 bigger then AS2-AS3. Pretty much everything you can do with AS3 can also be done in AS2.
There is one significant addition - being able to re-parent movieclips. It's like my prayers have been answered. If you don't see the big deal, I can give you an example where it's very useful and even necessary.
I also have not yet seen any significant speed increase in AVM2, the perfomance in drawing the graphics is same as before and while the code executions may be faster there are very few games running so much code that it slows down the game.
Path finding and complex ai, amongst other things, will benefit greatly from faster code execution. I haven't done any comparisions, but sprites are supposed to be faster than movieclips, even if it's just a little, it can make a world of difference.
The main problem with making AS3 complex and "mature" as every other programming language is that when someone is able to write AS3 code he can write same code in any other programming language too. And if he can program in other language why would he choose to use Flash?
A) Because you can play your games on the web without extra plugins (flash penetration is higher than java if I'm not mistaking).
B) Your game will be cross platform
C) You don't have to worry about a graphics engine, it's already there
D) Are you telling me the only reason you're making games in flash is because it's simple?
and when you need to decide to spend next couple of years learning AS3 or some other programming language there isnt many good reasons to go with AS3
Come on now, it's not that difficult to learn as3. This scrolling engine is my first project in AS3, I just looked at a few examples, looked up a few things, and I was ready to start coding. Took me a few hours to get this engine up and running. And granted, I don't know everything there is to know about AS3, not at all, but it's more than enough to get started.
Whether you like it or not, OO is just better and defintately a lot cleaner than AS code intertwined with your frames (which I only ever use for a simple gotoAndPlay to loop an animation or similar things). In AS2 it was best practice to use OO, now it's a necessity. It's a natural evolution to me.
Plus, you can always just stick to AS2 or even AS1. AS3 is there for when you need more power etc.
Anyone else want to comment on my scrolling engine?
Last edited by Fall_X; 07-06-2006 at 03:53 AM.
-
hmm
I like the name . Looks good, I'll give it a play when I get home.
Didn't know you could reparent movieclips, that is an amazing feature.
Last edited by Pugger; 07-06-2006 at 03:54 AM.
Reason: Fall_x made points.
-
 Originally Posted by Pugger
Didn't know you could reparent movieclips, that is an amazing feature.
This is amazing, but it has a downside too - when you remove a movieclip from it's parent, it still exists, it's just not parented (displayed) anymore. So you'll have to rely on the garbage collection to remove it. So make sure you always delete or null your references, and also references to any children (or "unparent" the children). Plus it's only removed when the GC does a sweep, so all events on it will still be triggered, so you'll have to remove those too.
But for me personally, the new movieclip-model is great. In one game, I wanted each enemy, character, etc to be in an external swf and only load what I needed in a level. Unfortunately, you couldn't duplicate a loaded mc, until now. So what I did was load an external swf with a movieclip of the enemy (or whatever) inside, and duplicate that enemy within the loaded swf - which had one downside : I couldn't change the depth of enemies individually, only within their parenting movieclip (so all enemies of type A could have their depths set relative to eachother, but all enemies of type B were always in a seperate "layer", which sucks for top-down games). So I had to group all types of enemies and other sprites in swf's per level. Now I have a lot more flexibility. If that makes any sense.
-
M.D.
yes, that re-parent feature would be good, my tile engine i made in AS2 which was going to be based on areas needed this feature to be able to operate. Now i can have only 9 areas and detect when an object has moved into an area, remove that object from its current area into the next one, within each area there are multiple depth levels (layers)
It makes sense in my head anyway
-
Senior Member
Maby its a me thing but,.. why is it just a green screen? I only looked at the swf... and yes im running fp9...
92.7 Fresh FM for all your South Aussies - Doof Doof music FTW people!
-
Did you unzip it? It needs an swf from the data directory. I did it this way to show how you can load tiles from an external tileset-movieclip (which just needs the tiles in the library).
Last edited by Fall_X; 07-06-2006 at 08:47 AM.
-
Senior Member
kk it worked now...
Thats a preaty good effort for a first project in AS3... good stuff
92.7 Fresh FM for all your South Aussies - Doof Doof music FTW people!
-
Ok, fixed some small but important bugs (got some x and y coordinates mixed up in a place or two), and introduced a way to load grid-based maps, with an option to split the grid up into supertiles of a specific width and height.
So go download it again!
In my "demo", I use a grid for the back layer, which is turned into 3x3 supertiles. Seems to work, but I'll have to do some more tests.
Yay.
Last edited by Fall_X; 07-06-2006 at 03:52 PM.
-
Just added another tile type : BitmapTile.
You'll need to add a bmp property to your layer to make use of it. This can be any DisplayObject, but will most likely be a Bitmap or a Loader.
The tiles are cut out of this DisplayObject using their index and size, and the size of the bitmap. Basically, if you have a tileset image, the first tile will have index 0, the one next to it 1, etc.
A layer that uses these bitmap tiles can still use normal tiles like other layers, and bitmaptiles can be placed in supertiles just like other tiles - so it can all be mixed.
Some feedback would be nice.
Edit : transformGrid isn't working properly - the displayed result it okay, but still needs to be fixed.
Edit2 : Think I fixed it, fixed version in the download.
Last edited by Fall_X; 07-06-2006 at 08:26 PM.
-
hmm
This is advancing real fast 
And it runs pretty fast as well (I tested it on my old MAC at work and ran pretty good)
Besides the xml feature, do you have plans to add anything else?
-
Yeah, I do have a few things in mind :
A SpriteLayer. I'm not talking about the new Sprite displayObject, but the traditional meaning of sprites - players, enemies, etc. But I haven't thought much about how to implement this yet.
Being able to move tiles around. This would mean I'd need to give tiles an identifier name, so you can reference them, and I'd also have to move tiles from one "screen" to another.
Splitting up the setup calculations over multiple frames, to prevent the player from hanging. I'd have to reorganize large parts of the code, but it might be worth it because it would allow larger or more complicated maps.
A level editor. This level editor could do some of the pre-calculations and deliver the map in a slightly different format, so the engine would know it wouldn't have to do these calculations up front.
Not sure when I will (try to) implement all of this. I might even port my platform engine to AS3 using this engine, but I don't think I'll be giving this away.
And it runs pretty fast as well (I tested it on my old MAC at work and ran pretty good)
Cool, but I'm guessing it will slow down a bit when more tiles are used. But it will hopefully still be fast enoughto run at a decent framerate.
If anyone plans to use this, I'd like to know. Rolling your own scrolling engine might be more rewarding, but this is there for anyone who wants it, and I think it runs pretty good, and it has a lot of features already.
Last edited by Fall_X; 07-07-2006 at 03:48 AM.
-
Just realized that the way I store bitmapdata for BitmapTiles isn't a very good way to do it, memory-wise - for each tile, I cut out the needed part of the bitmap, but there will probably be a lot of tiles that need the same part. So I'll need to rethink this.
Last edited by Fall_X; 07-07-2006 at 10:26 AM.
-
Okay, fixed the inefficient way I stored the BitmapData tiles. I know have a BitmapDataCache object per layer, which keeps copies of bitmapdata I cut out of tilesets, and my actual tiles just store a reference to this. Neat
-
Whey, another update!
I split the pre-calculations over several frames using events. I doubt it was a problem doing it in one frame though, but for very large maps, the Flash Player will have it a bit easier.
It does mean that the engine only starts working after two frames, but that shouldn't be a problem for anyone.
I should start thinking on how to handle a sprite layer now. My initial idea is that this is just an empty container to which the programmer can add DisplayObjects himself, using some functions.
When one of the sprites leaves or enters the screen, an event would be dispatched, notifying the sprite that it should do something - remove or add itself from/to the layer, but it could be a number of other game specific things. I don't want to automatically hide/remove sprites, because there may still be things going on offscreen, like collision detection etc, so it should be the game that handles this.
I might also add automatic but optional Z-sorting for top-down views, but that may be a bit too specific to add to the scrolling engine.
Any thoughts or advice on this?
Last edited by Fall_X; 07-07-2006 at 08:28 PM.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|