Marks Universe

The first game I wrote online - at least the first major game - was Universal Wars. I actually spent a great deal of time writing and then rewriting the game multiple times over. Often starting from scratch each time, it was never ‘quite right’. Each time it would take quite a while, and yet never see the light of day. But then, my partner had a big Uni assignment to do over two days, and I focussed - in just two days I finished (from scratch!) a completed and working copy of Universal Wars that actually went online! And it was great!

But, it suffered from scale. Eventually, a victim of both it’s own success and design flaws, the game became too slow. ‘Ticking’ once a minute used to be painless - then, started to take 10 seconds or more. Then 20. Eventually, the game couldn’t continue, and was taken down.

Fast forward a couple of years and I’m remaking the game using a powerful C++ server I wrote initially for the next version of Universal Wars. So scalability and speed is a huge issue for me this time around!

I’m testing to game with around 60,000 objects spread over a galaxy roughly 2,000,000 x 2,000,000 ’squares’ big. (That’s 4,000,000,000,000 squares!!). If it can cope with that, it can cope with a substantially smaller universe when we go live. But, it’s having issues - it has to do collision detection on a very large universe with a large number of simultaneously moving objects - and that puts it under a lot of stress. To alleviate this, I’ve reduced the number of coordinates by a factor of 10 - so each ship now occupies a tenth of the ’squares’ it used to, but it’s scaled up by the client to still look as smooth as it was before. Actually, it helps the client->server communication, because instead of having to transmit:
Ship 15 moving  from  3,5 to 3,6
Ship 15 moving from 3,6 to 3,7
Ship 15 mov….

It just sends:
Ship 15 moving from 3,5 to 3,16 over 11 seconds

And the client handles the rest. Much smoother!
This reduces the number of coordinates in the game down to 40,000,000,000- 100 times less. Still too much to store at once, so it’s stored in a different way (making use of 2 STL::map container’s, a vector of objects and a touch of magic!) but that’s where we are now Onwards as ever.

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!

Well,
I used DirectX and managed to achieve more than I expected - a beautiful, rotating planet, and a moving ship (a 2D sprite).

DirectX is powerful, I’ll grant that. Extremely powerful! But, some things they’ve made more tedious than necessary, and as I was writing my engine, wrapping up all the intricacies of DirectX API calls, I decided that there simply had to be something more flexible out there - why reinvent the wheel for the thousandth time … So, I had a bit of a search, and discovered Irrlicht; an open-source CROSS-PLATFORM (Nice!) DirectX/OpenGL wrapper. Amazingly, it usually works with OpenGL about the same (if not better, particularly framerates!) than DirectX. Win-Win!

So far, I’ve got a 3D ship loaded, a chase-camera following it, boosters that emit blobs of fire (quite nice, actually!) and basic keyboard control. Not bad for a days work learning the engine!

Onwards!

Hey,

Well it’s been a good few weeks since I’ve last posted so I thought I’d make an update for those who are still reading!

Firstly - since the last post, I’ve moved house - my girlfriend and I are temporarily living with my parents whilst we find ourselves some new accommodation. This also means my business has been put on hold temporarily whilst we relocate - I’m a self-employed computer technician and web programmer, so I’m flexible when I need to stop for a short while!

So the game! Well, the game has taken a different turn - as I knew it would. It’s not longer written in PHP. In fact, it’s not written in Flash / ActionScript either - which was the next (suspected) logical step.

It’s being written in C++. I originally aimed to make it cross-platform using Visual C++ on Windows, writing a cross-platform common library, and using SDL. So I tought myself SDL, got a good bit done and then realised a few things:

• SDL is not the fastest library in the world (not using OpenGL, mind you)
• SDL cannot do rotation without costly (as in speed) libraries (Again, not OpenGL)
• SDL is easy to use, pretty flexible, and cross-platform; but ultimately, fairly limited

Now I must say - I really LIKE SDL, and would consider using it again in the future. It has some smart features and I can see it’s appeal. But yesterday I changed my mind - and uttered those dreaded words that, in restrospect, I think may cause the demise of Humanity - “I’m going to remake this using DirectX”…

I’ve looked at DirectX / Direct3D before, briefly, and then ran away quickly. I’ve got a bit more time now, so thought I’d give it a proper try. So far, I have a rotating sprite on the screen, using DirectX 9 via Direct3D - so no DirectDraw or any old rubbish like that! (On a side note: I’ve seen lots of mention about DirectX 10 and losing a lot of features of DX9, oh dear oh dear! Just when you decide to learn one thing, another ambushes you with a steeper learning curve! Needless to say, I’m sticking with DX9 - I’m not, yet, interested in high-end features or graphics card).

I’m writing the game using my trusty EasyNote laptop - Celeron M 1.4Ghz, Windows XP, and half a gig of RAM. No graphics card that’s worth mentioning (!) but I do have a few other PC’s with better and worse specs - so the game will be fully functioning on a low-spec machine, that’s important to me.

There’s a learning curve with DirectX, a big one. What originally started as a simple space adventure & trading game is developing into one that should have a decent spread of action, strategy, adventure and mystery. It’s gone from a 2D Sprite game to a 2D game with a couple of 3D effects (like the background planets and lighting being 3D) to a 2D game using entirely 3D models - enabling some very funky effects, but still retaining the 2D playing field I wanted - the only game I’ve had the time to learn and LOVE that was a 3D space game was Elite: Frontier. 2D space games are easier to learn, easier to grasp what’s going on, and easier to make HUGE! And scale is extremely important to me… Hopefully that’ll become clear in due course!

Anyway, as ever comments welcome, feedback essential, and looking forward to having at least a basic demo of what’s-to-come in the next few days or weeks!

That’s what I’ve decided to do; or more, that’s what I’ve been recommended to do by Kate! And it’s a good idea.

Many people find projects start and do not ever get to completion - and I’m certainly one that’s experienced that a few hundred times. So, little and often is the key for Zelborg. If you leave it a week, you can’t be bothered to ‘get back in to it’ - and then a week becomes a month, and the next time you look at it you spend a good couple of hours just understanding the overall structure - let alone the specifics - of how you put the game together. Does that suggest bad coding style? I don’t think so - I’ve actually maintained a very similar coding style for a while now and believe it works well, but that’s not to say that code that’s older than a couple of months doesn’t become hard to understand on first glance.

It doesn’t start tonight though. No - I started a couple of weeks ago, so there’s already something to see on Zelborg.com. Although, I’m actually torn between two methods of doing things:
- Do things using PHP’s GD libraries - it’s flexible, pretty fast, capable of quite a lot, and more importantly - I know how to use it, and can whip up a game quicker with it
- or -
- Write the game using Flash. As I don’t know Flash, nor ActionScript, this is a venture into the unknown - but the result would obviously be smoother and probably more engaging. And since this is the new Web, are people going to be so interested in a game that has to reload a new page everytime you scroll the page along? Methinks not so much. A fluid game written in Flash would also provide the framework that could be used for dozens of other games in the future. So Flash = Good. GD also is good, but I’m starting to believe that it’s had it’s day for the online browser-based gaming market.

The game is currently planned to be Isometric - and that’s what the game is so far that’s written using PHP’s GD library. As the mathematics (relatively easy - once you’ve got the pixel-precision sorted out!) is pretty much the same, it’s not wasted time having devised and written a PHP class to do Isometric maps in GD!

Today’s half-an-hour - learning some of the basics of Flash. I’ve actually done a bit before using Flash, but in reality I’m a complete novice - and given my usual ability to pick up a programming language in no time, it’s quite a deviation from the standard forms a language takes. I did dabble with ActionScript a few days ago - and failed - due to not fully understanding the entry points for the ActionScript (as in - which frame it should be on, how you handle multiple scenes, etc). I know there’s power in them there Flash … This ‘blog will probably be me documenting my discovery of Flash, ActionScript, Isometric maps in Flash, and (argh!!) Flash Internet programming to begin with - before we even get into the real meaty parts of Zelborg. But that’s all part of the ride!!