Since Cale has been creating all the blog posts in here, I felt it's about time I contribute to the Developer Journal. For those who don't know me, I am Daniel Miede, Venom's primary Level Designer. I have been working on creating the fun and exciting maps you will be able to play in Penguin Smash. Currently, I am working on a Village map for Penguin Smash, which will feature very "cartoony" looking buildings. The map will feature the Capture the Egg game mode Cale was previously talking about, so expect the map to be rather large. I cannot show you any screenshots or concept art at the moment, but perhaps in a not so distant future, I can show you what I have been up to recently.

 

Alright, I don't have any screenshots of this yet, but I figured I'd talk about it. It isn't exactly "front page" worthy news either. So last week we successfully implemented Angel into Penguin Smash. It works perfectly and as expected. There are a few bugs in the inner-workings of it, but not in the functionality. I was running around in Penguin Smash testing out our new gameplay mode: "Capture The Egg"--which isn't really like it sounds, it isn't CTF-style. So on every egg capture, the game makes a call into Angel to increment a "TotalEggCaptures" value for the player. I had the game open on one monitor and the Angel dashboard open on the other. Every time I captured an egg, the dashboard would flicker with activity, which is really neat. I could see the session being created, the commands being issued, and the transactions being performed. It is really pretty cool. I'd like to see how it looks on a larger scale with more players.

Early tests show that the average transaction takes around 20ms to complete, from the time the Angel Service accepts the SOAP XML to the time it responds to the client. That time does not include "time-on-wire" or any game-related functions. We'll most likely have to multi-thread this so it won't block the game's main loop thread and possibly halt rendering for a few milliseconds--that would be bad. Right now, Angel causes thread-blocking.

So we've still got some work to do with fixing some of the inner-workings, possibly making it faster, adding multi-threading, and changing the way the games interface with the Angel client DLL. We'll be pluggin away at this for at least a few more months I'm sure. The bottom line is that the proof of concept is there, it works, and it works well. The data collected by the client DLL and the web interface for administration and reporting work very nicely together.

Well, during my short vacation for the holdays, I worked on Angel a little bit between being at an airport, on a plane, and visiting with family. Just minutes ago, I conducted yet another semi-stress test of the Angel web services and database and was able to open 10,000 sessions in just under 2 minutes using the C# client. The C++ client is still lacking some error handling functions, but they will be easy to overcome.

I've added sessions and access keys to the Angel web service now so only authorized customers are able to execute commands against the system. The sessions are used for authorization control and tracking while the access keys map specific customers to specific games registered in the system. I can't go into too much detail on how they work without revealing proprietary information, but what I can say is that this system has been written in such a way to be VERY scalable. Most functionality can be added/changed/removed without the need to recompile and deploy the web services or alter the client libraries. This is truely one of the most complex and scaleable peices of software I've ever written. It will prove useful to our customers once it is ready to market. I get giddy just thinking about it.

So, I spent all day yesterday and already a little bit this morning working on Angel. Angel went from a service-only proof-of-concept to a server and client proof of concept in just under 12 hours. I've been stress-testing it a little bit this morning and it ran 10,000 "AddUser" commands in just under 3 minutes. Sounds slow? Well, let me explain everything that goes on in a single "AddUser" command (subject to change):

 

1. Build the SOAP request (translate Angel data objects to SOAP-compatible objects). Request contains user information (Name, Alias, etc.)
2. Connect to the Angel web service
3. Send the command parameters to the web service
4. Service writes a log entry to a text file (very verbosely)
5. Service executes a database statement, storing the data
6. Service checks for errors, if none, grab the user ID back out of the database (room for optimization here). If errors occured, put error description into the response object.
7. Service builds a response object and sends it over the wire back to the client
8. Client converts the SOAP-compatible object back to Angel data object types
9. Client checks  the response object for success/failure from the server
10. Client tears down SOAP connection

 

Now do that 10,000 times. 

This is my first time building a C++ SOAP client and I must say, with the help of gSOAP, it works great. It is the first time I've gotten a C# web service and a C++ client to play nicely together. We initially tried this with raw sockets, but it proved to be WAY too much of a hassle and there's too much that could go wrong. This has worked 1000% more reliably than anything else I've tried. I've sort of been having that "mad scientist" feel about me the last few days since I've gotten this work--talking to myself, mumbling, swearing at my code, and then screaming "IT'S ALIVE!!!!!" when it finally worked.