TIGSource Forums

I've been developing a game in AS3 for a year or so now. It's a 2d platformer that uses raster graphics, although it also uses Flash's 2d drawing routines for UI stuff, which should hypothetically make it a bit more portable. I have most of the foundational components of the game in place, but I'm seriously starting to question if I want to finish the project, which still has a substantial ways left to go (probably at least a year), in Flash.

The impetus for this is that, having just discovered Pixel Bender, I found out immediately after that Adobe gimped its functionality in Flash, making it run in the virtual machine and slowing it by a factor of 5+. I was briefly really excited by the idea of a shader language that wouldn't force me to work with AS3's monstrously awful 3d API, but apparently it was not to be. Between this, the ongoing absence of controller support, and Adobe's recent sprint of questionable business ethics, I'm not feeling too comfortable about using this tool any more.

Which is a real goddamn shame, because FlashDevelop is fucking awesome.

So, here's my question: Where should I go from here? The foremost candidates thus far are: C++ with OpenGL and some set of appropriate libraries, HTML5 + WebGL, and, of course, Unity. I'd kind of like to use as much of my existing code as possible, but the most important thing is getting the game done and making it good.

I don't know. I feel shitty about this because for a long time I've been driven, to some degree, by knowing how awesome a Flash game could actually look, if programmed efficiently and cleverly: However, at this point, I don't really feel like making Flash look good any more. The past months I've spent working in it... are looking somewhat misguided, now.

Oh well. Ideas?

Every platform has its pros & cons. If you're ( truthfully ) halfway in development .. ride this project out using Flash, and then consider jumping ship for your next project.

I just have concerns over whether I can make it the game I want it to be on this platform. If I can take one or two extra months amongst the 24-36 it's taking me to make this game, get a stable 60fps while not having to keep a strict particle budget or entity limit, that alone seems like a worthwhile trade to me.

Plus... Like, I'm used to Flash having kind of shit support, but this is the first time they've basically patched it to be WORSE. Will it be the last?

If you can't create what you want within your desired system requirements, looking elsewhere might be worth considering yes :) How important is web-based ( since you do mention C++ with OpenGL )?


This is a dangerous thought .. don't obstruct yourself simply because you're frustrated with a ecosystem.

Web isn't important at all, I was targeting an AIR projector anyway.

And it's not that I'm interested in limiting myself -- quite the opposite, it's a LOT of work milking performance out of Flash, and if I can use those same programming resources on a platform with fewer inherent limitations I may be able to achieve even better results. To the contrary, what I meant to say is that some of the reasons I've been staying with Flash at all may have been more sentimental or conservative than actually practical, and I'm thinking it may be time to move past them.

Alright, as long as a switch is ( purely ) practical, it's all good.

Anyway, you're in luck. Unity 4.3 ( with integrated 2D toolkit ) has just been released ;)

Yeah I'd just noticed that, looking at some tutorials now. I must admit, moving to something as high level as Unity worries me a bit... I know there's access to shaders and stuff, but I worry about not having control over particulars of timing and orders of operation. I don't know enough about it yet to know whether I should be worried or not, though.

As others have said, I'd suggest not dropping everything on the floor midway through the project. Have you looked into HaXe/OpenFL (http://haxe.org). I've been using it for a while now, and it has multiple targeting platforms (Flash, native C++ win/mac/linux, android, IOS, etc..) and it has pretty good AS3/Flash.

Most people code using C# in Unity. Whether C# is too high level for you, is up to you ;)

Will look into it, thanks. The main reason I'm considering dropping a lot of my existing work is because I feel like a fair amount of it will either be made redundant if I switch to a robust tool like Unity (IE level editor stuff) or will be something that with some cleverness I can port to another platform (like maybe this thing you're linking me to). I dunno, I'm still looking around, but I definitely think it's time I put in the leg work to make sure that, if I DO stick with AS3, it's because it's actually the right choice, and not just due to laziness or ignorance.

Well I'm okay with garbage collection and stuff, I'm just paranoid of some unspecified situation where I don't have access to something I want access to. I guess I'm just curious how often that happens to other devs.

If you can program in Actionscript 3.0, then C# is not too high level for you. While C# does have a few features that make it a bit more powerful, and a bit more difficult to handle than AS3, a lot of its basic concepts and structures are very similar. If you can handle AS3, the transition to C# is not overwhelming. The biggest difference is not being able to reference functions automatically. (and dealing with delegates instead, although the Action class provides a great shortcut)

A much larger hurdle for Unity is just learning how it's component system is designed to operate. The average AS3 framework usually relies on standard inheritance. You'll see plenty of that in C# Unity, but the core of Unity's scripting is based around a component architecture. Learning to use this methodology is the biggest challenge I faced.

Higher level as in more abstracted away from machine language, that is, not meaning more difficult. Does writing components in C# give you access to most/all aspects of the Unity environment? I had assumed that the scripts mostly governed entity interactions, can you actually access or replace core code?

I've been talking a lot in abstract terms, but here's a specific example I've been wondering about: Can you switch between a locked frame-rate, with slowdown if the comp can't keep up with it, and a dynamic frame-rate that just skips frames as necessary? Or is it always dynamic? Can you lock the frame-rate at something non-standard, like 24 frames a second?

Application.targetFrameRate = desiredFrameRate;

That line of code in just about any script will adjust the target frame rate for your Unity application.

Generally speaking, Unity usually doesn't bother with frame rate. The default behavior is to render as many frames as it can. But you can direct it to shoot for a specific frame rate. There will be slight fluctuations based on performance. But if you want it to do 24 frames per second, you can tell it to aim for that.

Most animations in Unity are handled using various approaches to time duration. The timescale for the entire Unity application can also be dynamically adjusted through scripts, allowing for slow-mo or speed-up effects.

I'd move to html5 and webGL probably with a nice 2d rendering engine like pixi.js (https://github.com/GoodBoyDigital/pixi.js/) from goodboy (http://www.goodboydigital.com/blog/)
that said, I prefer building tests, hacks and small prototypes and play with architecture.
 
Probably the smart thing to do is just stuck with it, make it as good as you can, finish it, actually finish it, then really finish it! and only then move on to your next project.


By the time you would be as far in development rewriting your game in X language with Y library there will be other and/or better alternatives too.

There actually is controller support for the latest version of flash in their new GameInput api: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/ui/GameInput.html (http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/ui/GameInput.html)

This is also a pretty good wrapper/handler for GameInput I found on github: https://github.com/arkeus/as3-controller-input (https://github.com/arkeus/as3-controller-input)

Also, if you've been working with Flash/AS3, I +1 for switching to haxe. The syntax is nearly identical to AS3, so porting your current project might not be too horrible if you really need to. You also get the benefit of being able to target many different platforms, including Flash (people are also saying that Haxe's Flash compiler builds better performing executables compared to Adobe's compiler: http://www.splashdust.net/2009/10/as3-vs-haxe-performance/ (http://www.splashdust.net/2009/10/as3-vs-haxe-performance/) ). I just started recently working with the ported Haxe version of the FlashPunk game framework called HaxePunk, and so far it's been pretty smooth development.

Another huge plus is that FlashDevelop fully supports Haxe development, so you don't need to switch to a new IDE (and I agree that FlashDevelop is fucking awesome).

I started implementing something with GameInput only to find out that it, at least at the time, didn't work on the PC. Have they fixed that? That at the shitty 3d API were two things that made me want to switch.

I'm currently in the process of looking at haxe and unity. Rebuilding the project in Unity would be a far greater endeavor, but might be worth it in terms of providing for free the sorts of level and entity editing tools it would take me an extra few months to develop in AS3 -- it might even out. If Haxe can do the same thing AS3 is doing for me but faster, more flexible, and more future-proof, then that's also obviously pretty appealing. I may just try an AS3/Haxe code conversion into a FlashDevelop Haxe project and see how that looks/works to start with.

GameInput worked fine for me on PC when I tried about a month ago with a test air application, however it didn't seem to work when I embedded the swf in a browser. Not sure if it was due to flashplayer or the browser itself, but I didn't really investigate it for too long before I just switched over to Haxe.

Okay, I've been thinking about this and I think the smart play at this point is to go with Haxe. I don't need to reinvent any part of the project, but I get a performance boost, a less ass-backwards 3d implementation and shader language, and the ability to jump ship and build into C++ if I have to. I'm tempted by Unity's extra tools, but I think it's probably a real bad idea to change the nature of the project so fundamentally right in the middle like this.

Thanks for the advice, guys!

Sounds like the right call, given where you are.

I've been programming HTML5 with Google Web Toolkit (GWT) for couple of years, and I have good experiences working with it. I haven't faced any major problems with browser combatibility or performance. Web games made with GWT work on every modern browser that I've tried, even on cheap touch phones (with lousy FPS, though...).

The GameInput API is only for AIR

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/ui/GameInput.html