Is it possible to combat the speed of a library that you don’t control?

As mentioned in Welcome to The RainEngine, I’m using the ASGE (AwesomeSauceGameEngine) for my 2D engine (which will be taking up roughly 80% of my time on the assignment, but I believe it’s worth it). The engine is extremely basic and isn’t optimized, that means that it can be slow when faced with a load it wasn’t explicitly designed for.

Take one million objects for example.

With 1m objects, the engine’s speed decreases to around .25 frames per second. This can be combated by running the built program in Release mode instead of Debug mode (where that increases to 43 frames per second, which is workable) but of course that means that it’s not possible to (easily) debug the program.

The problem lies in the engine’s renderer, specifically a loop in the render API function override where I loop over all 1m objects and tell the engine to render. This isn’t something that can easily be fixed on my side as utilizing threading wouldn’t work as it would require cross-thread communication, and detaching the thread from the main thread so that the slowness of the renderer (which will happen regardless) doesn’t slow the pre-render down. That also means that other techniques such as CUDA are out of the question.

That doesn’t rule-out the use of these techniques to speed-up other parts of the program, such as the simulation of each rain particle. I’m considering using Nvidia CUDA for that, but that would also mean that RE wouldn’t be able to run on computers not equipped with a Nvidia GPU.

For now I’ll settle with the 43FPS for production (showing off the engine) and I’ll simply have to decrease the amount of particles when working in Debug mode…

 

Welcome to The RainEngine

For a university assignment on game systems I’ve chosen to do regular good ‘ol rain… with a twist. The assignment calls for creation of one of four systems (rain, sand, sound, text-based game) to be implemented in at least two game engines (I’m using one 2D and one 3D).

In the 2D game engine, ASGE, I’m having to create everything from scratch as it is primarily a rendering engine and does not have anything else such as a particle or physics system. Thus RainEngine is born: a particle system for rain, where each rain particle is contained in a group and this group is controlled with parameters that links it to the wider system.

Simulating rainfall isn’t too difficult; render the particles, adjust their angle and slide them down the screen, and perhaps add a small variable bounce effect when the rain hits an object (such as the ground). I intend to do that but I also intend to add some liquid dynamics by allowing the rain to flow down objects, such as sloped surfaces.

I also intend to add environmental attributes to allow the rain to adjust to the environment, for example:

  • Weather will affect size and density of the rain, which will affect its physics (i.e. its “splash physics”)
  • Temperature will affect the physical parameters of the rain at a molecular level (aka, turning into ice, snow, etc.). Each rain particle group will have its own temperature that will determine what the particles in that group are, and how it transforms.
  • Humidity- high humidity combined with a desert environment will result in a violent rainstorm with large dense raindrops.

Graphs, Graphs, and Data; an expansion of Wildfire

As you guys may know, I haven’t exactly been on the ball with updates to the Wildfire system, until now that is.
I’ve been working on an update to the system that utilizes an external database system instead of SQLite, but the biggest part of the update is to recording of statistics.

‘Recording of statistics?’ I hear you say; fear not for it’s actually for a greater purpose- public server tracking.
The ‘biggest part’ of the update I mentioned before is actually adding tracking & server browser functionality to wfstat.us. All servers will be tracked (when a connect request is made, Wildfire will store the server name, time, and other stuff), and this tracking will be reflected on the website as graphs.

The server browser isn’t finished yet (which is why those exclamation triangles are there- the data can’t be retrieved at the moment as the data is not present).
I’m hoping to add direct connect functionality (aka, launch straight into a server from the site).
There will also be graphs similar to those on the Overall Network Activity page (perhaps in more detail).

All this is done via the new Wildfire API, which I will also be making public on (or shortly after) the new update is applied.

Any ideas for graphs that you’d like to see?
Let me know!

Wildfire: 6 Month Review

The current instance of Wildfire has been running for 6 months now, so I thought I’d compile a small review of Wildfire so far…

There are currently 248 registered users, with an average of 54.3 new users each month (up from <30 in January, February, and March) in the last three months.

This statistic alone is impressive seeing as Crysis Wars is almost dead.

44.8% of players are Russian, while 39.9% use anonymous addresses:

  • Russia: 44.8%;
  • Unknown: 39.9%;
  • Poland: 7.3%;
  • Hungary: 0.8%;
  • Europe (General): 0.4%;
  • Spain: 0.4%

Wildfire sees around 50 billion queries each month from its users and servers!

I was surprised at this one too, but it makes sense given that each query is around 32 bytes with 200 or so of them coming in each second (can rise to around 10,000 per second on a busy day):

Thoughts on Game Design: Why use UDP for multiplayer?

It’s common knowledge in the games design industry that many online multiplayer games transfer data via UDP instead of TCP, but why?

To answer this, we’ll have to dig deeper into how TCP & UDP work, and the specific scenarios that online gaming has to deal with. To start with, TCP is slower than UDP; this is because UDP is a continuous data-stream and doesn’t care if the other end exists or not, meaning that UDP doesn’t have to wait for a response from the other end in order to send the next packet. TCP is ‘polite’ and waits for a response from the other end of the connection, and as a result is more reliable as data is guaranteed to arrive(with UDP there’s no guarantee that data will reach its destination) from one end of the connected socket to the other.

In an online game, do players with high latency seem to jump around the place? That’s UDP. What’s happening here is that the data the player’s client is sending isn’t complete (or packets are congested), and as a result the server makes it seem like the player is ‘teleporting’ in the world. With TCP, this wouldn’t happen but on-wait sockets will consume CPU time and as such it is theoretically possible to crash a server that uses TCP in this way. Remember that the number one rule is to never assume the client is well-behaved- program in some protection!

With TCP, the operating system handles the connection in its entirety; if the destination is unreachable the connection is instantly dropped. This is practically useless for online gaming as connection hiccups are common; if TCP was used just a single ‘dead’ packet will result in a disconnection.  In UDP, the application decides when to ‘drop’ the connection; this is useful as it allows the game to wait for more data if the connection is intermittent. This however turns into a disadvantage as it is possible for an unprotected server to crash if a client sends a packet of greater than 65,535 bytes. Implement DDoS protection to scan the size of a packet before it enters the server properly.

This vulnerability exists in Crytek’s Crysis 1 and Wars online multiplayer games (unsure about Crysis 2 and 3); this meant that any UDP packet sent to the server’s IP and port resulted in the server crashing. With online gameserver trackers this lead to a widespread spree of attacks in 2010-2011 where someone (might add that I know exactly who this person is…) kept crashing Crysis servers via this vulnerability,
Via the game SDK I was able to patch this by adding a function that dropped packets greater than 65,535 bytes, which instantly protected my servers from this attack. Please, if you’re going to develop an online multiplayer game, ensure this vulnerability is patched.

Also remember that if we had 16 players connected to a gameserver, every time something happens to a player the 15 other players need to know about it; imagine if we were using TCP and one of the packets dropped. Yes exactly, we’d have to wait until that packet is resent and the server gets a reply for the gameserver to continue processing data, and this in turn holds up all the other players. The packets coming in while the dead packet is dealt with will have to be dealt with too, resulting in congestion. With UDP, we have none of that (the most recent packet is dealt with, and the older ones are simply dropped).

Automated Load Balancing & Auto Scaling

I’ve just discovered the load balancing & auto scaling functions of AWS EC2, and I immediately put them to use for Wildfire.

love the feature; it scales automatically depending on the amount of activity Wildfire is having.
The servers in the screenshot were created by the auto scaler and not me.

I don’t have to worry about the capacity of Wildfire’s infrastructure either, as the load balancer balances the load out to all running instances equally (this is the main reason I put Wildfire on a full database server rather than SQLite). All instances (at the moment) are t2.micro instances as my account’s under the free tier (so I get 750 hours free per month), but this will probably change as the popularity of Wildfire grows. The main issue here is the financial cost; although auto scaling reduces costs as it only creates new instances on demand, it still costs money.

Restoring & offering online multiplayer services is something that developers/publishers of the games should be paying me for, but I do it for free (note that this doesn’t mean that I don’t accept donations). I have to pay for the server infrastructure & development out of my money & my own free time (not that I don’t enjoy doing it, which I do as Wildfire is an interesting project).

Always backup, backup, and backup. Did I say to backup?

I replaced the SSD in my system a week ago and sold off the old SSD, which had an encrypted local partition with Wildfire’s source-code on it.
Now, Wildfire’s source-code (as well as the source of some of my other projects) is stored on an encrypted drive on my server, so I didn’t need the data on the Wildfire partition on the SSD. Of cause because I use a Windows domain everything was backed up to my server, so I went ahead and wiped the SSD clean before sending it off.

I use AWS (Amazon Web Services) to host Wildfire, and AWS protects passwords to instances with private keys, and the private key for the instance Wildfire was running on was stored on the same partition on my SSD that the Wildfire source-code was stored on. You probably know the rest.

At the moment I’m rebuilding the instance that Wildfire was running on, and service should be restored shortly.
The big problem was that I thought that I’d backed the private key up onto my server, but that didn’t happen. Part of data security (especially to comply with data protection regulation, which I broke!) is to ensure the backup is accessible. It just happened to be that everything except the private key file was backed up, due to how Windows and the cloud storage service I use handles certain file extensions (files are backed up onto my server, which then uploads everything onto cloud storage).

Within the next couple of weeks I’m aiming to migrate Wildfire onto Microsoft SQL Server, away from its current SQLite implementation. This would mitigate at least some of the data issues.

GameTracker: Tracking the money, not gameservers

As some of you might know, GameTracker’s GameSpy V2.0 querying is broken, so I opened a post in the support area of their forum giving them all the details they needed to verify that it is a GameTracker problem and requesting that the issue is fixed (it affects other games as well).

I recieved a reply this morning, which comprised basically of ‘it’s not our problem, go away’. I never requested in reference to the game developers as it’s not their problem, so I opened a new thread.

It seems that all GameTracker care about is the money they get from ad revenue, and not any gameservers tracked.
Noticed lately that they haven’t added support for newer games yet?

Please, GameTracker, don’t turn into a rubbish service like many of the other gameserver tracking services.
You were good when I last used you four years ago. Right now? Not so much.

Oh, and another thing GameTracker… ban me and I’ll be seeking a refund for the GT Premium Gold service that I pay for each month (not that it’s worth anywhere near what I pay anyway).

FIX YOUR STUFF