I thought I’d write a little about my take on AS3 and Flash 9 for games.
Flash 9 and AS3 bring a lot of speed enhancements, which is obviously very much needed for games - especially the newer games and even 3D games, which are starting to appear more and more for Flash (which is amazing in itself, it’s quite a feat for Flash to be able to push that kind of processing!).
For me, the actual turning point the started me learning Actionscript 3 was the Sockets support. No longer was XML or a ‘file-based’ transfer mechanism needed - I could directly interact with a socket server and start transfering data at high speeds with low latency. The overhead of ‘file-based’ methods - such as XML, communicating with PHP, etc - are too much to make even remotely ‘real-time’ effects possible. Chat is possible, as is turn-based games, but anything beyond that not. The game I’m developing is actually turn-based for all intents and purposes, although it’ll be quick enough that it should feel almost real-time. Getting absolute real-time was considered - but the packet rate simply wasn’t high enough to achieve this. (That would be, controlling each ships with the cursor keys and be able to fight battles completely manually. As soon as the speed picks up, discrepencies in lag, packet loss, sync, etc, make this impossible, sadly).
Broadband has also moved the bar up a large notch - now, transferring a few megabytes of game data is possible - almost expected. Music, heavy graphics and other effects can make up a game that was otherwise restricted a hundreds of kilobytes or less. My game already takes up 500Kb and that’s without assets - so I’m going to have to reduce this - but it’s not a show-stopped. Not to mention anyone with less than broadband will probably have a less-than-perfect game-play experience.
To anyone deciding if AS3 is capable of the particular game you want to make, the chances are it is. When it comes to high-speed real-time communications over the Internet, you’re going to have your work cut out no matter what language you chose - and AS3 isn’t going to help matters, for one thing only TCP/IP is supported - no UDP support here, I’m afraid.
A few things have been settled upon; namely, a name (!), the domain name, and a few game-specifics. The server will be the C++ server I wrote, and the front-end is Flash Player 9 using Actionscript 3 with Flex 2.0. That’s what this Blog will continue to focus on, so stay tuned!
As it happens, I’m now looking into previewing the Flex 3.0 pre-release beta. I was reluctant - mainly because I’ve only been learning AS3/Flex 2.0 for a few days - but figured that it could be benefitial to move over now, rather than trying to port a mammoth application later on! I will keep you posted whether or not I am successful! 
I’ve fixed a huge memory leak in the game - which was causing IE or Firefox to crash, at worse case, or use up vast amounts of memory (and swap file, of course) at best. That means that the game no longer drastically slows down after a short while of scrolling around the map. Plus, a clipping problem where stars overlapped planets is now fixed, and shouldn’t come back again.
The chat window has been officially (and probably permanently) scrapped - it didn’t fit, and doesn’t fit the logic of the game, either. That’s not to say there won’t be communication - in fact it’s one of the biggest factors - but not in a ‘chat room’ sense. Imagine broadcasting messages to nearby ships, and communicating directly with single ships or planets - that’s where we’re going. A full chat room doesn’t fit - plus opens us up to moderation, advertising, etc etc. I want the game to be very ‘natural’ inside - so, punishment will be dished out by the games Police, an actual set of units operating within the game like everyone else. Plus, there’ll be mercinaries available to hire to carry out your own dirty work, and I’d imagine there’ll be a fair few interesting characters to meet along the way.
Lest we not forget - this is an MMORPG but with a few significant twists.
Although the game is very much in the infant stage, I would like to begin getting alpha testers as the only way to properly see how well this game’ll work is to have proper people testing - testing with bots is not nearly as effective.
Testers OS is not important - although I’d like to have a nice distribution of OS’s. Connection speed (dial-up or broadband) shouldn’t be important - as it’s written to work with dial-up - but that is untested and so I won’t guarantee it works. Testers *must* have Flash 9, although this is a very very simple upgrade that you shouldn’t really need to do much to obtain.
E-mail me (use the contact form at http://www.hughesdigital.co.uk) if you would like to be an alpha tester, or simply reply with a message here. Alpha testing won’t be required for at *least* a few days, but the sooner people contact me the better - please list your computer specifications (Operating System, CPU speed & memory, browser and version, screen resolution and size if known, and connection speed - anything else if you know it and consider it important) - I will be asking a few people to test things before Alpha testing if they have specific useful computer systems available, as I only have a couple of Windows XP systems and a Linux OpenSUSE box that is very slow!
Thanks,
Mark
So - ActionScript 3 does not support UDP. That’s interesting, and annoying as hell. I had hoped it would to take off some of the load and overhead of using TCP so I could do more real-time ’stuff’ with AS3, but apparently that won’t be the case. Getting 3 - 5 packets a second seems about reasonable, which should be fine, but under load I fear that would go down to 2 - 3 and then I’m starting to struggle with any kind of resolution. Heck, that’d mean that the lag on responsive actions would be huge - otherwise the client has to predict what’s happening, and when that involves other players it’s near impossible.
But that’s not a problem - I’ve decided that I’m going to do a turn-based game using real-time connectivity. The fluidity of the game will be superb - no page reloads or anything - and it still allow for some nice graphics and even real-time moving (once the tick has occured) - even battles could be played out for real.
This also allows me to develop the game without worrying nearly so much about things like timing conditions - something which could quite honestly dominate the coding for quite a while, as it’s a highly sensitive area - fail to get that bit right and you open yourself up to cheating, hacking, some huge and very hard to spot bugs, and all manner of complaints. Heck - even the “Big Boys” that develop games like Half Life get people moaning when “He missed me and then I died 5 minutes later from a laggy shot!” and the likes. No, lets use the best of what we can with Flash, and lets not use it for what it’s not meant for - for the time being!
On another note - I hope to actually start showing what I have available very soon. Because the client is no longer in C++ it means deploying it to users becomes significantly easier - I just upload it and you visit the web page! So stay tuned!
I’ve now decided (!! Wow !!) on a technology I will move forwards with.
ActionScript 3, with Flash 9 and using Flex 2.0 as the compiler. The compiler is the free Flex compiler, and I’m using a trial version of Flash CS3, although that’s until it runs out - after then I’ll use a text-only editor and the Flex compiler solely, so I’m not compiling using Flash CS3 to avoid getting into habbits I can’t afford to keep up!
I’ve done the code that handles Client <-> Server communication, using Flash 9 Sockets (amazing stuff! Very impressed!). I’ve now abstracted a basic Sprite class that’ll handle rotation and positioning, although it’s quite a straightforward additional to the built-in Sprite.
The C++ server (Linux) has been revived and is now talking with Flash nicely. It already handles tens of simultaneous connections happily - and, supposedly, would work with hundreds or even thousands, but I haven’t tested it with that yet but see now reason for it not to work!
Onwards!