- AS3 Starling Tower Defense Tutorial – Part 1 – External File Loading
- AS3 Starling Tower Defense Tutorial – Part 2 – Game States
- AS3 Starling Tower Defense Tutorial – Part 3 – Play State and Config
- AS3 Starling Tower Defense Tutorial – Part 4 – Map Tiling
- AS3 Starling Tower Defense Tutorial – Part 5 – Enemies
- AS3 Starling Tower Defense Tutorial – Part 6 – Towers
- AS3 Starling Tower Defense Tutorial – Part 7 – Sounds, Stats, and Saves
- AS3 Starling Tower Defense Tutorial – Part 8 – UI Menu Components
- AS3 Starling Tower Defense Tutorial – Part 9 – UI Game Components
- AS3 Starling Tower Defense Tutorial – Part 10 – Bullets, Collisions, and Managers
- AS3 Starling Tower Defense Tutorial – Part 11 – Conclusion
We made it! Ten blog posts written in one month, averaging about 5,200 words per post (though most of it is code) is definitely a new record for me. I’m glad to be done with this phase of the code. My plan was always to get this demo working, write a tutorial series so that other people can do this easier, then take the same codebase and continue building with it to make a few games. So now it’s time to get to make a few games! Woo!
I wanted to wrap up the series going through some things I learned along the way. Maybe “postmortem” would be a better title but that sounded a little pretentious since I just made a little demo, not a real game like the big boys. I’ll get there though soon enough.
Thoughts on Starling
I had started a tutorial series before this on creating a straight AS3 game engine. I had made it through about 3 posts, discussing loading assets, enemies, and generating your tile map by blitting “by hand” (well, without Starling). It was going in a good direction then I remembered something called Starling and that it was supposed to make games faster, better, more FPS, less visual lag, all GPU-jacked-up and a hot new engine on the block. I stopped that series (and even removed it from the site) because I wanted people to focus on this series; I wanted to focus on this series. I wanted to take Starling for a spin and see how it did, then I wanted to write about it because telling Biscuit, my kitty, all about flattening Sprites and game ticks with the Juggler, he was not amused. Maybe he was? I dunno, he kindof has the same face all the time. Smile Kitty, damn you! Anyways…
Being a Developer, I know there’s a learning curve with any new language, engine, or library that you’re wanting to try out. For some of these libraries, the learning curve is stupid easy. Greensock’s Tweening and Loading libraries, for example, I can’t praise enough. He’s got excellent documentation, he’s built tools that Give you the code to paste if you want something to move on your screen, you really couldn’t ask for more. Sometimes the learning curve is steep… Assembly anyone? I guess it’s incredibly subjective saying something has a steep or shallow learning curve. If I had come fresh to AS3 and Starling, learning both at the same time, I’m sure the difficulty would’ve gone up exponentially. However, I was pleasantly surprised at how easy Starling was to incorporate into my project.
If you were reading closely throughout the series, you may have caught a few snarky remarks at Starling’s expense. Starling is growing and evolving, it’s relatively new, and all things aren’t exactly the way I personally was hoping for them to be. Oh well, get over it dude, because the positives of what Starling does for me outnumber those few quirks and gaps in functionality that I was commenting on.
It’s funny, last night I was checking out Starling’s github repo, just browsing through the commit log to see what the latest stuff was. It was impeccable timing as the latest commit said something about HOVER events. What?! I was just posting on how this was a pain, and clearly they’re actively working on adding new features and fixing bugs daily. These guys are on it. The community forums are thriving and they’ve got some great mods and users over there that make sure things get answered and people aren’t just hanging.
So, come on… what’s the real conclusion? Should I use Starling for my project?
The bottom line with any new library, tech, app, etc is that they are all tools. If what Starling does solves your project’s problems, then it sounds like it’s the right tool for your project. If your project is to make a 3D game then Starling is not right for your project. If your project is to make a platformer game, sure Starling can help, but there’s also CitrusEngine that builds on TOP of Starling, and has a lot of built-in functionality for platformer games.
I went into Starling with an unrealistic expectation about just what a GPU-accelerated Flash game would be like. I bought Particle Designer and started making some cool particle effects, nothing crazy, just 200 particles for a single bullet’s particle effect. Yeah… so with about 8 Towers on the stage shooting every second or so, 8-15 (200 particles each) bullets on stage at a time, with ~30 enemies being animated on the screen, I was incredibly disappointed to find that I was running around 4-8 FPS. That wasn’t some failure of Starling’s, but an unrealistic expectation of how things were going to handle. I scaled the bullet particles down about 90% to about 20-30 particles, and things obviously bounced back. Now, mind you, most of my “benchmark” tests were done in debugging mode with tracing to the console still turned on. Obviously not the ideal environment for testing things like that as once you turn off tracing and get the SWF into a browser, things change dramatically. But still, do not expect any engine to do everything for you and solve all your problems and keep you warm at night. Read up on what Starling does. Download and use Starling. Work through some tutorials. Starling gets a LOT of things right, in my opinion. Sure I may take issue with this little inconsistency or a little “why didn’t they add this functionality”, but at the end of the day, the reason I 100% completed everything I set out to do in this tutorial series is because I enjoyed working with Starling.
It was familiar and easy to work with. It gave me a very easy way to run a game consistently at 50-60 FPS with a healthy amount of entities rendering on the stage. It gave me a very easy way to handle assets via the TextureAtlas. I was really happy using the Texture Packer app and TextureAtlas. The package hierarchy was built exactly like Flash. You don’t realize how important that is to new folks incorporating Starling into their existing codebase. It just makes sense and makes things easy. Starling sped up my development by a decent amount. It handled a lot of things that I had previously written in my old engine, or was going to write, but now, didn’t need to.
I guess the point is, don’t think that because it’s GPU-accelerated that you’re home free, that you can code sloppily and the GPU will have your back. Because it won’t. You be nice to Starling… don’t feed it 2,000 bullet particles plus 30 enemies animating and expect that next game tick to be a happy one. It will puke right on your new pants, man.
Things I Got Wrong
As more people read the series, I’m sure I’ll have more things to add and update here.
After going through Starling’s docs (not sure how I missed this before), Starling does have a KeyboardEvent class. Apparently starling.display.Stage WILL dispatch keyUp and keyDown events as you would expect them to and in the same manner as you’re accustomed in AS3. I have not used them, nor gone back to incorporate them into my demo, though for the next project I may update that. I don’t think there’s anything wrong with having a flash event listener on the flash stage listening for a keyDown, but just to keep it all simple, might as well use Starling’s keyDown/keyUp.
TouchEvents were a tough sell for me starting Starling. I wanted my Flash MouseEvents. They worked. They did what I expected them to do. It took me a day or two of working with Starling to stop complaining about how TouchEvents were different, and just shut up and use them. You’re in Starling’s world… deal with it. And as I was mentioning before, it made me really excited to see the new TouchProcessor class in the Repo. There are no docs posted for it yet but if you know where to look you can find it. It *should be* the perfect blend of Starling/Sparrow TouchEvents with classic Flash MouseEvents. I’m really excited about this as it’s being written to be quite extensible.
I have to give a few shoutouts to a few Apps that just absolutely go hand-in-hand with easy Starling development. You see them in almost every tutorial, but they just make things oh so much easier.
- Texture Packer – They have great tutorials on their site. I don’t even think I even had to google anything about how to do something with Texture Packer. I just watched Lee Brimlow’s video tutorial, followed along, and that was that. I imported a few folders from my assets directory, set the settings like in the demo, clicked Publish and in a second or two it had generated a tile sheet and an xml file for me. Hell, I could leave Texture Packer running the whole time I’m working and as I save images from Photoshop into those folders, they’d automatically show up in TexturePacker, one click on “Publish” and now my sprite sheet was updated and I could run the game and immediately see the new assets. If you are serious about making Flash games using tile sheets and blitting yourself (not using Spriter or something), this was a phenomenally great purchase. Set it up, and it just works. And saves you loads of time.
- Particle Designer & Glyph Designer– The guys over at 71Squared are fantastic. I went to the site to get Particle Designer and saw they had a package deal where I could get Particle Designer and Glyph Designer for a slightly lower “bundle” price. The thrifty part of me clicked the mouse first and just bought Particle Designer. After a day of playing around with PD and doing a little research on Glyph Designer, I decided I also wanted GD. I sent an email to their support guys and within the hour they had me a little coupon so I could get GD for the bundle price. Saved me a couple bucks so I could go get me a burrito! Woot! They were just such a pleasure to work with. You always seem to have such bad experiences with companies and I always want to highlight the good ones. Anyways, both apps worked very well. I don’t think I needed Glyph Designer for this demo. I think I could’ve done without it and just used basic fonts, but it’ll be fun to play with on my future projects. Particle Designer had so many knobs and sliders, there’s SO much you can do with those particles it’s a bit overwhelming. I really recommend spending time with the HUGE library of pre-made particles that come from the user community. The only snag I hit with PD came when I was bringing the particles into my game. There’s something screwy with where Particle Designer says point 0,0 is and where Starling says it is. Watching a few more tutorials and some light Googling got me through this with no worries.
- Flash Builder & Photoshop – You know all about these. I couldn’t be happier with my Creative Cloud subscription. Sure it’s a bit pricey per month with the full suite, but I’m using Flash Builder and Photoshop all the time. Might as well pay a little more and get access to all the other cool toys… Illustrator, Audition, etc. I think I figured it out to something like, if I saved the monthly price, I’d be able to get just one of those apps in a little over a year. And that doesn’t come with updates and stuff. Anyways… not to seem like a huge shill for Adobe, but it’s also nice to know that you have licensed, legit software. You know what I’m talking about
- Flipz’ 2D Game Tileset – My two enemies are animated because of this tilesheet. It was very tedious cutting out each individual tile from the sheet, but beggars can’t be choosers and I liked the little sprites. Big thanks to Flipz for helping me out with the tilesheet.
So I think that’s it for now. I may update this post as things change or I realize I did more stuff wrong.
Thanks, and I hope this series was helpful!