Blog for Andrew Douglas at GarageGames.com

Cooperative Control: Hello Whirled!

Andrew Douglas — 2007-03-03T20:25:30+00:00

I believe it was 1983 when I first played TRON Deadly Discs on our Intellivision. It was, as most games were at that time, a pretty simple little game really but it had one feature that made it stand out from any other game we had ever played. Both controllers worked to control the same main character. I don't know for sure, but I'm guessing the design decision to do that was more to do with the combination of it being a single player game and the fact that it was hard to tell which controller was which than it had to do with designing the game to be played cooperatively. The controls for the game were actually pretty complex, especially for the time - there was a directional pad of sorts at the bottom of the controller that determined which way you ran, and it had essentially a number pad at the top of the paddle which determined the direction you threw your Disc. There was also a block button which I believe was the #5 key. Once you threw your Disc, you could have it boomerang back to you again by using the key pad as well. If you're having problems imagining this - you should check out this great write up about the Intellivision controller - www.classicgaming.com/features/articles/intcont/

Anyway, this meant that you could move and shoot independently of each other. And since they were independent, and each function could be controlled equally well with either controller - guess what we did? We played the game cooperatively, one person running (and usually blocking), which the other person was responsible for shooting. This allowed each person to focus entirely on an individual task which is really the way my mind works best. It was such a unique idea, that we played that simple, repetitive game for what I'm sure was hundreds of hours.

Again, I'm not sure how much cooperative play figured into the design process for TRON Deadly Discs, but one of the reasons it was so much fun to play cooperatively was that there was a single resource - the disc - that both players were in competition for. Being at the other persons mercy when it came to running around or when it came to destroying the enemies was one thing, but when one person couldn't "do their job" because of what the other one was doing with the disc led to a lot of the fun... and a lot of arguments too.

I was so profoundly impacted by TRON that to this day I go out of my way to find and play cooperative games. The trouble is, few really have rivaled the experience of TRON, with the very notable exception of Halo, which I'll get to in a minute. For example, we played a lot of games like Jackal on the NES, which was a cooperative shooter where each person controlled their own Jeep, or Contra which is really one of the gold standards of cooperative play even to this day... but none of them really tackled the cooperative experience in a way that caused both players to be controlling different aspects of the same on-screen character. And that one difference had a huge impact on the game play. Some may consider it limiting, but it was so important to us that by the time we got our first PC with a keyboard, we did everything we could to make single player games into a cooperatively controlled experience by splitting up the keyboard and having each person being responsible for different aspects of the game. Spy Hunter was one of the more memorable examples.

I know we weren't alone in this, as I've heard other people talk about doing it too, and I was reminded strongly of how powerful and fun this control scheme was when my wife and I first played Halo. One person driving the warthog while the other fired away on the chain gun - it was a riot. I wanted more and I got it as the last half of the last level was, as far as I'm concerned, the best ending of any game I've ever played. So it boggles my mind that it seems like game designers, even to this day, have largely ignored this control scheme. We're working on changing that. We've developed a prototype - called Whirled! using XNA and we entered it into the DreamBuildPlay Warmup Competition. This simple mod of the XNA Spacewar starter kit was most definitely inspired by TRON, but we want to take it to the next level. Obviously the 2 week development period we had to develop the game limited what we could do, but I think it demonstrates really well the concept of what we are calling "Cooperative Control".

The key elements of Cooperative Control are as follows:

- Two or more players are responsible for different aspects of the same in-game object. The most obvious example is Pilot/Driver and Gunner of a vehicle, but we want to extend this control scheme beyond the basic vehicle concepts as well. If you want to say this more abstractly, there should be an inseparable interdependence between the players.

- The control scheme is such that there is added depth to playing cooperatively versus controlling the object in a single player environment. I certainly realize that gaming is a solitary experience in many cases, so to be commercially viable, I think single player control is crucial, however there should be aspects of the control that makes it advantageous to play it cooperatively. For example in Whirled!, the Right trigger will fire your blade, by default, in the direction your ship is facing, but by using the Right analog stick to aim and then pulling the right trigger, you get much more control. Now, is it possible for one player to control both sticks and be pulling the trigger at the same time? Sure... but it's pretty difficult.

- There should be independent goals in addition to the mutual goal of survival/success. This is really something that is lacking in games that weren't designed from the ground up for Cooperative Control. What usually results is one guy is dodging/blocking while the other is shooting. And while those are independent goals, additional elements should be added to create a sense of accomplishment for each player. For example, running over an Elite while driving the Warthog. It's not simply about positioning the Warthog in the right place for the driver, it's possible to take out enemies all on your own. We are actually still working on this in Whirled and we'll hopefully have more to show with that soon.

- Ideally, the two players should be competing while cooperating - say for number of kills or competing for the same resource. This isn't strictly necessary. Halo, for example, really didn't have any contention between the players over anything except where the Warthog was going. So it's not a hard and fast rule, but it's something to bear in mind in your design.

I also believe that Cooperative Control needs to take place throughout the majority if not all of the standard single player experience. So while Halo may demonstrate aspects of Cooperative Control, and while it's great that you can play the entire single player experience cooperatively, I'd hesitate to categorize it as a truly a Cooperatively Controlled game. Bonus points go to the game that utilize Cooperative Control in a multiplayer competitive environment.

Okay, so for those that have made it this far and want to try out Whirled! - here you go: whirled.greatgamesexperiment.com

I'd love to get some feedback on the prototype or on games you've played that really qualify as Cooperatively Controlled (even if they weren't intended that way :) )

-Andrew Douglas
theoreticalgames.com

Torque X - Break through/Break down

Andrew Douglas — 2007-01-27T06:11:46+00:00

I really want to love Torque X. So many things are done right (finally), and yet there are some underlying issues (some of which are XNA related more than Torque related) that worry me.

GUI - Not having a GUI editor is really painful. Not having a fully fleshed out GUI system *still* is even more unacceptable since Avalon/WPF has shipped for the same platforms that support XNA. The really big deal is that XNA and WPF have major "air space" issues where you can't overlap or easily integrate the two. It's taken me a couple of nights and quite a few headaches to even get WPF dialogs to work and play well with XNA. Note: if you want to do this, I've found that letting the xna app be the "host" and simply have it create the WPF dialogs is a lot easier to deal with and resolves the issues of getting the xna app to get the focus when it should. If you need code samples, holler.

Networking - I realize the whole point of moving to Torque X is to give me the 1000% boost I need to get Jabber/XMPP integration in My Bogle, but knowing that it's going to be a custom solution that we're going to have to maintain is troubling.

Abstracting too far - I watched this great video with some compiler architects at Microsoft that were talking about how the were building in Functional programming language features into things like C# and VB. But the way they were doing it was not at the expense of providing low level/imperative programming methodology which meant that you get the best of both worlds - the high level, abstracted interface and the low level, "I just need to reference that handle" kind of code. The thing is, I've already run into issues where Torque X and XNA have abstracted out relevant details. The "Game" class is suppose to make life easier for people, but when I need to tell the game class exactly what device information to use (say, so that I can embed it inside my own hwnd), I can't because it's wrapped up and hidden away. Granted, I'll be buying the source (when it becomes available), but I should haven't to if the abstractions that had been done in a more "tiered" approach where I can work at the high level abstraction when I want to do something quick and easy, but when I need to I can still hook into the low level guts.

Mouse (and to some extent, keyboard) events - I've seen several people working on this here and there, in forums and projects.. and I understand the model that is being used.. but at the same time, if you're going to force me to use your model for tracking things like is my mouse over my sprite - then make the components that I need to easily track it. Certain use cases in a 1.0 product are bound to be more difficult and time consuming then others... but since there's not framework in place that's even half-way decent, it's going to be causing a lot of developers a lot of pain. I think this is one of the best examples that XNA has gotten fairly tightly focused on XBox 360 hobbiest and not at windows indie developers.

But the good news in all of this is that I am moving forward. I have gotten my dialogs, written in WPF to show up and integrate to a workable level and we'll be tightening the integration as we go along. I even have that screenshot I've been talking about - this is just a Programmer Art rendition of the login screen that I'm forcing you to enter before getting into Tank Buster. The great thing is, I can hand the xaml file over to someone who knows better, and they can make it look even better, add animations and effects, etc... without breaking any code. It should be noted, that although it may not be really pretty right now, it is all vector graphics with no bitmaps to be seen. And to think - I was *this* close to giving up on the whole WPF/Torque X thing - but instead of breaking down, I've broken through.. analysis paralysis is over and I can finally get some work done. Yippee!

Enjoy:

-Andrew Douglas
theoreticalgames.com

Online multiplayer on the brain

Andrew Douglas — 2007-01-20T02:37:42+00:00

So I just posted up a HUGE write up (and it's only the first in a series) on what Jabber is and why you should be using it in your online multiplayer games. If you have a few minutes you should definitely, definitely check it out. I didn't cross post it here because it's not really GG specific, though some of the source code that I'll be putting out may come in handy for some of you Torque X'ers.

The reason why I wanted to post here was because I really wanted to find out what you all thought about what was really needed to break down the online multiplayer game barriers that apparently so many indie games have.

See, my impression was that it was just the casual arena that was having problems with online games, but a quick check on Manifesto games proved that online multiplayer is still a sorely under-represented market in the indie game space. I think it's my "Garage Games" bias that multiplayer should be baked in every game, even if I've run into issues with the way Garage Games has dealt with the whole "NAT traversal" issue. It's really surprising how difficult it is for indie's to actually deliver a successful online multiplayer game.

Some of my thoughts - but please, I'd love to get feedback from you on why online isn't bigger in the indie game development scene.

1. No "universal" networking layer. Between NAT's and the lack of adoption of IPv6, the dichotomy of the UDP and TCP stacks and the plethora of poorly implemented or poorly documented networking libraries out there, it's really a mess. Things like Windows Communication Foundation (aka Indigo) is a really neat concept to try to abstract the networking layer, but it's essentially a proprietary system, which has it's own limitations and issues. Network layers should be better than this in 2007!
2. No easy to use/open "toolkits" for higher level online game features such as leader boards and friends management. I guess what I want is an open alternative to xbox live. Bits and pieces of it may exist, but show me one good indie game with online friend management. That should be proof that we need to do better. Live Anywhere may be designed to incorporate "casual" games on windows, but it certainly isn't designed for indie's. Argh!
3. We don't use the tools we have. Jabber has been around since, what, 1999 - where are the games built on Jabber? It's as close to a universal networking layer as you can get (especially if you sprinkle in Jingle) and it provides a great framework for building higher level online game features in a "federated" way so that your one online identity could be used across games for a true xbox live competitor. So why isn't anyone talking about it, using it or at least using some equivalent that I don't know about. Why are we stuck with making online multiplayer games the way we did back in the late 90's?

Maybe I'm just frustrated and feeling a little worn out by "blazing a trail", but what issues do you see that are preventing indie's from making great online games? How can we solve these problems? Show me some successes too, if you've got them, so I don't feel quite so alone in tackling these problems. Thanks!

(oh yeah, I promised a screenshot of the UI for My Bogle's "Friends Play Free" interface, but I've been busy building out our server architecture... which has really come a long way. I'm hoping to get back to the UI battlefield this weekend).

-Andrew Douglas
theoreticalgames.com

My Bogle moving to Torque X

Andrew Douglas — 2007-01-06T15:48:48+00:00

Yeah, you all are probably wondering what happened to My Bogle. It's been a few months of "light" activity due to other obligations. Work on the website is going very well and should be read to launch soon, but really, the big news is that My Bogle is moving to Torque X. What? Why! Well, let's look at the plan and hopefully it'll make more sense.

Build out Friends Play Free: (if you don't know what Friends Play Free is, it's the service launching alongside My Bogle that allows people who purchase the full version of My Bogle to send invitations to their friends and family to play My Bogle against/with them. And as long as the invitee is playing against the inviter, they can play as much as they want... no restrictions on time, levels, game modes, etc. If they want to play the game against other people (when the inviter isn't around), then they'll just need to buy the game themselves.) This is really the defining element of My Bogle and at least a few more games to come after that. In order for us to build this out the way we want it to work, with the skillsets that I have as a developer, and with the tools that are available... developing the UI and framework for Friends Play Free has to be done in .Net. I must be getting old because I've rarely made a decision that said "it's only feasible on this platform", but with time and resource constraints in mind, it'll be months saved by moving to .Net... and that's too big of a savings to pass up. So what does building out Friends Play Free entail exactly?
- Jabber as the network layer. I want presence, rosters, chat, invitations and game play to all happen over one consistent network layer. Jingle (which will introduce true p2p and voice chat (video chat?)) will have to wait until the tools and spec (which I believe just entered last call) stabilize, but building on the jabber framework has a tremendous amount of functionality now, with a great future in front of it. So why not use libjingle? Well, cross platform (and even just one platform) support in libjingle is a black art, one I don't have time to get the required knowledge to deal with. It may be that libjingle and projects such as tapioca will get some cross platform love over the next year or so, but I can't wait for that and I want to build games, not network layers. Why not use TGB's networking layer? One reason is the firewall issues involved. In order for one player to host another player, they have to work around their firewall, and that's just not pick up and play friendly enough for me. You can skip that and just code it all via http, but that leaves a lot to be desired as well. Combine that with things like presence and the work that's going to have to go in to getting invitations working and such, and it's a huge undertaking and would require multiple components to make work. No thanks.
- Next gen, intuitive UI. I want the best of all possible worlds and I don't want to spend a huge amount of time to do it. Eh? What that means is I need a great design environment, with an intelligent and well thought out toolset that gives me things like data binding, animations/sound effects and scalable graphics. So where can I find all of these tools in the .Net world? WPF. Xaml. Whatever you wanna call it, it's point and click easy with tools like Expression and gives me the productivity boost I need. The fact it launched in, what... November? means that it's official and supported so really this is about the first real opportunity to use it in a production environment for me and that, in itself, will motivate me to hack on it. Compare that to the helluva time I've had with the form controls and such in Torque and it's like a whole new world of opportunities opens up. Yeah, it's another deployment issue, but it's already installed on vista and the installation story on xp sp2 should be solved with clickonce. Maybe I'm being a bit naive. Maybe I'm limiting my target audience too much. Yeah, well... so be it.
- I want a reuseable platform in Friends Play Free that can be used for some time to come. While I'm not currently focused on making it available for licensing for other developers (as I want to make my games, darnit!), I want to be able to plug in a different game with the same engine and not have to think about the platform. It should save me considerable time for the next game or two at least. I feel like if I did something hacked together for basic online play for My Bogle, I'd be facing this same issue again and again and I'm tired of it - I just want it done. The opportunity to license the framework is just icing on the cake really.

Improve My Bogle: Besides Friends Play Free and a great "lobby", what does My Bogle get out of this?

Well, I have to admit that's the hardest part about this whole thing. But My Bogle was my first Torque game and my first use of TorqueScript. There are a lot of lessons learned and opportunities for improvement. The best part is that pretty much all of the core game logic isn't going to be hard to port to c#, so really, the "ugly" bits are the only thing that need rewriting and that's really the stuff that needs it:

1. Serverside logic that is unit test-able and reusable. I want a much more sane "game manager" that is reusable and will be easier to support. Nunit ftw.
2. Better animation management. The system we had coded up in torquescript for "queuing" animations was, for all intents and purposes, crap. It was extremely fragile and not reusable in the least. The component framework in torquex will mean a much more intelligent and reusable animation system (also unit testable?) that will clean up my second biggest torquescript mess.
3. So what's the biggest mess? Multiplayer support. It's about as hardcoded as you can get. Having support for more than 2 people would have been a nightmare. I'm not sure how many players the game will support (or that we'll want to support), but it's now "game driven" not torquescript soup driven.
4. I'd love to play with some of the advanced shader effects and such, but for the most part, the in-game content isn't changing all that much really. Dynamic light effects on the runes is a moral imperative - and they were already looking soo cool. I can't wait! :)

It is a shame that a game that was near beta has to go back and have so many changes made, however it's all good stuff that's going on and I'm really excited about the changes. The tools, the language/development environment, and the opportunity to refactor means that My Bogle and Friends Play Free have a very bright future indeed. I can't thank GG enough for what opportunities Torque X has opened up for us!

I'll be posting screenshots of the gui I've been working on shortly... but for now - you'll have to use your imaginations :)

-Andrew Douglas
theoreticalgames.com

Alpha and Dragon*Con

Andrew Douglas — 2006-09-06T17:54:03+00:00

My Bogle saw the light of day at Dragon*Con this past weekend. We put it in front of around a dozen people that ranged from close friends to complete strangers. Some sessions were simply demo's of what we've been up to and some were "shut up and watch them play" play-sessions followed by rigorous grilling :)

All in all it went incredibly well. Only a few bugs were uncovered and most sessions went off without any hitch whatsoever. The feedback we got was very positive. Some of our major concerns weren't an issue for any of the testers. Graphics and character designs scored particularly well which was a major relief. Not that I was worried about them to be honest, but you never really know, right? Especially after staring at them for hours on end like we have. The things that didn't score as well were the pieces we still are working on and didn't really demostrate this weekend. The only bad thing about demo'ing it at Dragon*Con was that some of the venues were quite noisy and demo'ing on a laptop without good speakers caused the sound to be quite soft. Those players who got to hear the great sound effects we've got really enjoyed the overall experience a lot more than those that couldn't hear it very well.

It was an incredible push to get ready for Dragon*Con (which is why you haven't heard much from me lately). We've gotten so much accomplished that's its hard to know where to start. We've gotten the fifth character in, whose animations and sound are probably the best so far. We've gotten a bunch of work done on tiles and set pieces for our levels along with a clear direction for our music even though it's not quite in game yet. We've gotten a lot more gui work done and a lot of cleanup and polish to the gui, characters and the gameplay. We also got the mac build working which means we should be launching for both platforms at the same time which is excellent news.

So we are officially in alpha testing, which is a nice milestone to be at but it just means there's an incredible amount of work to get done before we are officially in beta, though very little of that work is "in-game" but rather on things like Friends Play Free and such. The beta milestone has gotten pushed out a little ways based on where we are at and what we think we need to have so that we can get the most out of the beta. This weekend was great because it really confirmed that we are headed in the right direction. The whole experience has definitely gotten me more motivated to wrap this game up but at the same time I've seen just how much potential it has and I really don't want to screw that up by rushing through the last few tasks.

You may be wondering "what exactly did they get to see this last weekend?"... well, I'll show you.. only I'll have to show you slightly smaller than what it's designed to run at so this isn't nearly as good looking as it is in game:

Note the Runes on the right. They are like "power ups" for your characters.

Note the Initiative display on the left. The current character is on top, with the rest of the turn order below it. The active character also has a movement grid displayed and they can move anywhere they want in the grid. Also, the entire GUI shifts from Red to Blue when the player's turn changes.

So hopefully that makes up for not posting much lately. What do ya think?
-Andrew Douglas
theoreticalgames.com

My Bogle Sculpture

Andrew Douglas — 2006-08-14T03:06:58+00:00

It feels like it's been more than just a couple weeks since my last entry, as we've gotten tons and tons of things done. Sound effects, guis, lots and lots of characters are done and in game, initiative system, offline/hot seat multiplayer modes, we've gotten dozens of animations created for the Runes and the list goes on and on. That's not to say our to do list is empty however... we still have miles to go before we sleep, but just because I haven't been posting every few days hasn't meant our progress has slowed at all.

Tomorrow should have been alpha, but we've rescheduled things a bit. We don't want to wear out our best testers and there are a number of things we want to get right before we put it in their hands. So essentially, we've moved a lot of the features forward and back and ended up with a slightly better plan of attacking the last few "big ticket items" that are still on our list. Anyway we plan to have the first official beta come in just in time for Dragon*Con and the IGF competition. We have a second (possibly open?) beta planned for mid September and a full release right around IGC. If we didn't already have 90% of the game itself done, I'd be worried about the schedule (and I'm still a little worried about the schedule!), but we're already quite a ways ahead of the newly revised plan, so we should have quite a bit of cushion in getting this out the door. Most of what we've got between now and October is logistical and while it's time consuming it's actually the easiest part for me to plan.

I always struggle with estimating design and research efforts. How long does it take to come up with a good idea? How long does it take to solve a riddle? It's those sorts of things that can stretch a project/task to a breaking point. But if you don't get it right ahead of time, you end up with a heck of a lot problems - things like feature creep as development goes along or maintenance nightmares to name but a couple. I've learned a lot about game design from My Bogle, but one of the most valuable things I've gotten from the experience is just a greater sense of efficient design. In my other life, I've been largely responsible for shipping (or not shipping, but that wasn't my fault! :) ), multi-million dollar projects that have taken years of planning and development to bring into existence. My Bogle is infinitesimal in comparison (okay, not really), but it's been a truly amazing feat getting it to where it's at today.

See, it's like making your first sculpture. The building blocks and tools are different than almost all other media, so it takes time to learn how to use them efficiently. How long it takes to pick up a vastly different set of tools and techniques is something that is extraordinarily difficult to predict. Without a clear sense of what you can and can't do with the tools means that it's almost impossible to come up with a clear vision of what it is you're actually going to be able to make. You have to start small, iterate often, experiment and iterate again. Once you know (at least think you know) what you can do, then you have to imagine what the best sculpture is that you can make with your knowledge, skills and abilities. When you envision the completed work in your mind's eye - you can see all the little pieces that it will take to make it whole. You can break down the imaginary sculpture a dozen different ways to try and find the best way to put it together. But how long will it actually take to make it? Will you really be able to make it come out alright in the end?

My Bogle is a lot like my first sculpture... It's not my first game or my first software product, but it's essentially my first video game product. I've created many, many applications in many different languages, using many different tools for many different industries, but I've had to learn a whole new set of tools and a whole new industry. I've successfully distributed and marketed my programs to the public, but instead of convincing my users that my program is useful, I've got to convince them that my program is fun. I've loved (nearly) every minute of this process as it's kept me on my toes. I would never had expected to be as whole-heartedly pleased with my first sculpture, and for it be so close to finished as it is, as close as it is to our original schedule, and for it to be, in my own humble opinion, more beautiful and fun than I could have possibly hoped for... it's really just too much to grok.

It's funny, in January I knew I wanted... needed... to do something different, but I had no idea what it was that I wanted to do. I looked at this as a unique opportunity... possibly a once in a lifetime opportunity to do something I've always wanted to do, I just had to figure out what it was that I wanted to do with it. Given that opportunity, what choice did I have but to make a game company? I thought about what will happen when I'm 70 years old and look back on my career, and I look at what opportunities I had that I wish I would have taken advantage of, and realize what things I should have done but didn't do. And I knew that I wouldn't be able to be live with myself if I hadn't at least tried to make our game company a reality. Notice how I said our game company. This was not my vision alone. This was not my dream alone and I certainly wouldn't have been able to make it happen alone. Since childhood, my brother and I have been making games. We've planned out, strategized, executed and even managed to sell a few of them (mostly to friends :) ). But to actually make a game that was more than just something for ourselves and friends was outside our reach when we were younger, and that meant putting our hopes of ever actually making a game company on hold as we went about the process of becoming responsible adults. We make pretty good adults but we make pretty darn good game designers too. The only way I could fail was by not doing it. From that point of view, it was really a no-brainer.

So now as I look at our little sculpture in it's near finished form... it's hard to imagine that 7 months ago I wondered whether it was even possible. It's hard to imagine I had thoughts like "if we get 10,000 downloads I'll be happy". I'm so very proud of our My Bogle sculpture. I'm no long worried about being happy based on the number of downloads. I've certainly not given up wanting lots and lots of them... but I'm happy regardless of the download and conversion rates. As cliche as it sounds, this is about as close as it comes to having a dream come true. See, when you're building that first precious sculpture, it's not about how much you're going to sell it for once it's done, it's about whether or not you can really make it as great as you dreamt that it could be and in that regards it's far surpassed my wildest expectations.

-Andrew Douglas
theoreticalgames.com

P.S. no image?? well, if you haven't bothered to stroll over to our site in a while, you may have missed some of the newly announced creatures and a write about who they are over in Jonathan's blog - here. You must check it out... it's a moral imperative. :) I'll make up for a lack of pictures in the next post... I promise.

My Bōgle: Rules Rules Rules

Andrew Douglas — 2006-07-24T21:57:04+00:00

As I've mentioned in past articles, My Bogle is essentially a conversion of the Gladiators tabletop game. In this article and (at least one or two more upcoming articles), we're going to discuss what we used from Gladiators, and what we've had to adapt, add or take out entirely in order to have a rich video game that is not needlessly complex.

Background:
Gladiators was created to be a "user-friendly RPG", and the rule book that was created for it was miniature sized with only about 60 pages in it, just to prove the point that it was really very simple to learn. Everything was based on six sided dice, and the characters only had a few combat related stats:

Constitution - Determined Hit Points and a Strength modifier that adjusts the speed of the weapon used.
Dexterity - Determined Movement Points and an Initiative modifier to help determine the turn order.
Offensive Skill - Used to determine how many six sided dice you got to use when you attacked.
Defensive Skill - Used to determine how many six sided dice you got to use when you defended.

And then your character's chosen weapon would determine the following:
Range - how far away you can be from the enemy and still hit them.
Motion - how much movement would be used up when you attacked.
Damage - how many six sided dice you got to roll to determine how much damage was done if the attack succeeded.

Besides the character's name and experience point, that was pretty much it. The character sheets for Gladiators fit on a 3x5 index card. Of course, that's an over simplification. There's armor, shields, a monetary system, races and classes, but they were all very simple additions to the core attributes listed above.

Combat:
Gladiators combat took place on a hex grid (of varying dimensions). At the beginning of each turn, all of the characters would roll initiative to see who went in what order. Each character would start their turn with full use of their base movement points. Movement from one hex, to an adjacent hex required 2 movement. Attacking used up movement points based on the amount of motion required for the weapon (modified by the attacker's constitution bonuses). In theory, you could move, attack, move some more, attack again and attack a third time if you had enough movement, but generally a characters turn consisted of a move and an attack, or in some cases, two attacks. You determined who you could attack by the Range attribute of the weapon you were holding, so if you had a long sword, with a range of 3, then you could attack a character that was up to 3 hexes away from you.

Once an attack was declared, the attacker would roll the number of six sided dice determined by his Offensive Skill and the defender would roll the number of six sided dice determined by his Defensive Skill, and the winner would be decided in a manner similar to Risk - the highest die roll of each was compared first. If either person was the clear winner, then that was that. If it was a tie, then you compared the next highest die rolls, and so on. There was also a neat little rule about 6's. Any six would first be "rolled up" to see if you could determine a winner. This rolling up effect was also possible for certain types of weapon damage rolls. If the attacker won the roll, they would roll the number of six sided dice determined by their weapon's Damage attribute, and the total of all the dice would be subtracted from the defender's life points. Rinse. Repeat.

Oh, and one way we kept things fair and balanced between teams was to take pre-gen'ed character sheets and then have the teams "Draft" the characters they wanted. This was fairly effective, even if it gave me cold sweats from horrible 7th grade gym class flashbacks.

My Bogle:
When we decided to make a video game using the Gladiators system, we knew that we would have to make some changes (concessions?). While it was easy for a pen and paper type game to mix up the variety of armor and weapons, for example, it becomes exponentially more difficult to do it (well) in a video game. The art work alone could take more than the 6-8 month schedule we were working on. Having a multiplayer online game also meant that in order for it to be "fun" for everyone, we had to come up with a fair way to balance the characters and teams so that someone with a set of decked out/maxed out characters could fight a fair fight against a newbie (not that the newbie would win, but it would at least be fair). One thing that I really pushed for was point and click simplicity, and that meant that attacking had to be greatly simplified. With all this "redesign" it became clear that this wasn't exactly Gladiators, so we stopped trying to fit My Bogle squarely into the Gladiators framework. We would use what we could, but the official port of Gladiators to a PC game would have to wait. This gave us a great amount of freedom for My Bogle, but it also meant that the more we modified the rules, the greater the chance would be that we would "break" the game that had worked so well. It was really quite scary.

Well, this hasn't really been an interesting article, so let me jump into some juicy details about what changes and additions we've made to the rule system for My Bogle that we think have turned out just as good, if not better than the original. Some of these pieces are still a bit of a work in progress, but in general I think we are on the right track.

1. Each type of Bogle will have a pre-genned set of character stats that are based on the Gladiator's system. The stats are calculated as if we had pre-equipped the characters with weapons and armor, and balanced carefully so that no one character type is clearly dominant. We will have at a minimum 6 types of Bogle. We're also working on some unlockable character types.

2. Each type of Bogle will have a total of 3 levels. When you create your Bogle, they will always start at level 1. They will level up based on combat experience. Each level will cause the appearance of the Bogle to change slightly and it will cause their attributes to raise by a pre-determined amount. The downside to this is that it will effectively "cost more" to play with a higher level Bogle. Let me explain. At the start of the game, you choose which of your Bogle you will use for this battle, but you only have so many "points" to spend. If you are going to have a 12 point battle, then you can spend all your points on, say, four of your level 3 Bogle. Your opponent may choose six level 1 Bogle and three level 2 Bogle. Lower levels are great because they give you lots of warm bodies and therefore a variety of strengths and weaknesses (and tactics), but choosing a level 3 Bogle will mean that you can kick some serious tail. It's all balanced though so that whatever your strategy, there isn't a clear advantage one way or the other.

3. Ranged attacks are decreased fairly significantly over Gladiators. This makes combat animation easier/possible, but it also means that giving a character "Range" is a great tactical advantage. Variety is the spice of life.

4. Runes. These are like mini-power ups. They are collectible "tiles" that are used to increase the stats or abilities of the active character that generally only last until that characters next turn. There are just too many cool things about runes to talk about in this space, but it gives us back all of the combat tactics we had to "simplify" in order to give the user point and click game play... and then some.

5. Attack Attack!! Defend! Gladiators had shields for increasing defense. It also required the user to do a lot of math to figure out if they could move far enough to get in range and still have enough movement left over to attack. Trying to build a shield mechanic that worked in My Bogle was difficult, but expecting our players to do the math for attacking and moving just raised the barrier of entry way too far. It was a challenge to come up with a design that worked, to say the least. What we've come up with is to split "movement" and "actions". Your movement points go entirely to how far you can walk in one turn. The actions that you can take during any one turn are essentially:

- Stand still, and have two attacks (assuming the character you are attacking is in range).
- Move as much as you want and attack once. After attacking, you are allowed to keep on moving, if you still have any movement left.
- Move and defend. Defend increases your defensive dice by 1, so you have a better chance of surviving an oncoming attack. It also gives you something to do when you can't attack anyone :)
Defend ends your characters turn.
- Stand still and Attack once, then Defend. This allows a character with low health and low movement an option to try to stay alive when in close combat.

And of course anywhere along the way you can use a rune or three.

All of this is point and click so where you can move, who you can attack and whether or not you can defend are all perfectly clear. For example, if you move and then attack, you won't have the ability to attack again, or to defend, because you've used up all your actions for the turn. It's about as simple as can be and it's easy enough that it doesn't require a lot of detailed instructions to the user.

We also created some fun additions and made some really important design decisions that took advantage of the fact that we were making a video game.

1. Character stat tracking. One thing we couldn't put on those little 3x5 index cards was how many @sses your character has kicked and how many times he's had his own @ss handed to him. It's just another simple way of adding depth without adding complexity.

2. All the rolls are handled behind the scenes to speed up game play and make it more immersive. You aren't pulled out of the combat by waiting for the roll of the dice. You're waiting for the character to swing and waiting to see and hear the defender's reaction. Will it be a knock out or will the defender live on and have a chance to properly thank you for attacking him?

3. Down with hexes! Long live the hex! Hex movement is great because it's much more accurate than allowing (or disallowing) diagonal movement on a square grid. The disadvantage is that it's a little difficult to work with for the end user and it definitely has a stigma attached to it in the minds of some users. If you see a hex on a map in a video game, it shuts a lot of doors. So we turned to "Chinese Checkers" for the answer. The active character is provided with a "field of dots" with where they can move for their turn. Are they in a hex pattern? Yeah, but it no longer feels hex like. I can't tell you how pleased I am with how this has worked out. It's so much more immersive and yet it still has kind of a simple, boardgame charm.

Okay, wow... to all you that stuck around to read that, there's more where that came from! We've got game modes (you didn't think we'd only do "deathmatch" did you?), characters, runes and more to talk about. But I'll let you rest your eyes and let your brains buzz for a bit and I'll jump back into finishing this game. I hope this has whetted your appetite for My Bogle. If you have any questions or comments, just holler. We'd love to hear from you.
-Andrew Douglas
theoreticalgames.com
andrew@theoreticalgames.com

Funniest Game Ever?

Andrew Douglas — 2006-07-21T12:56:04+00:00

What's the funniest game you've ever played? Why was it so funny? Have you gone back and played it because of the humor alone? I think comedic talent is very hard to come by in video game development. There are a few truly funny games, Ratchet and Clank and Stubbs the Zombie come to mind. I've not played, but I've heard both good and bad things about Conker. Most of that is just very witty writing, which is great, but can you remember the last time you laughed at a "slap stick" moment in a video game? Has a game ever made you roll on the floor, cry, and have difficulty breathing like those classic TV Shows and movies?

Can stuff from sketch comedy translate into video games? What about stand up comedy? Can you make a game as funny as a Bill Cosby routine? Can you cause an image to burn into the psyche of the player from a video game the way I will always remember "There's a wainbow hanging from the pbottom of my libpbp!". Would it be possible to do a video game version of a sitcom (instead of a sitcom about video games)?

What's your favorite funny movie? The Ghostbusters game in the eighties never made me laugh the way the movie did. Why not? Some of it just comes down to talent. Bill Murray is just darn funny. Who's the Bill Murray, the Robin Williams or even the Woody Allen of video games?

Quote:
Comedy is tragedy plus time. The night Lincoln was shot, you couldn't joke about it. You just couldn't do it. But now, time has gone by, and now it's fair game. See what I mean? It's tragedy plus time.

I don't know about you, but I think video game developers have a tendency to shy away from comedy because of their fear of failure. It's scary as hell trying to make someone laugh and there's nothing worse then trying to make someone laugh, and failing.

Some things to think about:

1. Laughter begets laughter. That's what the laugh track in shows is for. Do any of your characters laugh?
2. Physical comedy was a key element of cartoons' success as an industry... sure they had some sly adult humor thrown into the mix, but they didn't need to be entirely vulgar like south park to be popular. Video games haven't really touched it, from what I've seen.
3. Comedic timing is hard. Comedic writing is hard. But we have a couple things going for us: We have moving pictures and audio... comic strips don't even get that, and they come up with funny stuff every week... mostly.
4. You know what one of the funniest games is? Halo (and Halo 2). Laughter releases tension, it breaks the monotony and provides a great hook to keep the player wanting more and then to play it all over again. My wife and I played through the last level of the original several times on Legendary, just to get the hilarious ending. You're game doesn't have to be a comedy to be funny.
5. Don't be afraid to laugh at yourself. One of the funniest things I've ever seen in a game wasn't in a game. It was a little in engine footage from the RPG Summoner on the PS2. You can catch the video here: video.google.com/videoplay?docid=840960313659062542&q=summoner

Now, I have no idea if anyone will find what we're doing in our game all that funny. I hope so, but regardless of the outcome, I've had a blast putting it together. There are certainly places where we've worked on being overtly funny, but some things are more subtle. For example, let me introduce you to one our concepts now that you may or may not recognize. He was based on the infamous mythological creature: the wookalar.
Half pig, half human...

Quote:
suck your brains right out your nose.

What do you think? Should we add a little pig tail? :)

-Andrew
theoreticalgames.com

Maized and Corn-fused

Andrew Douglas — 2006-07-18T23:13:00+00:00

Alright, so I'm going to break from my usual routine of actually having a "point" in these little blog entries. My current state of mind after an all out, no holds barred battle through the weekend to get My Bogle into a reasonable state (that lasted all the way through until 3 am Tuesday morning) has left me in a very odd, and not completely lucid state of mind. So I'm not going to attempt to wax theoretical or philosophical or anything. If you were expecting something profound, move on now...

1. David Jaffe, who made a point of wanting to make people cry, has changed directions. While I fear having to compete against a downloadable PC Game by Mr. Jaffe, I also think it's quite ironic and almost cathartic to here him say such things as

Quote:
I think somewhere in the last year, I realized that electronic games have always had an amazing ability to evoke emotion. They are not the emotions that many of us- including me- have been pursuing. But they are emotions nevertheless; they are feelings that the best pure games can always evoke. Feelings of tension and release, feelings of fear and anxiety, feelings of triumph and defeat, feelings of confusion followed- sometimes- by joy at having overcome the challenge.

.

God that sounds so freaking familiar. But it's great to hear him say it. I feel validated :)

2. One of my little pet projects - a dynamic image/button control for asp.net developers called "ArtForms" - came back to surprise me. I was surfing around and just decided to do a search on it to see what it's been up to. See, I haven't it really touched the thing since 2003, when we released a free version of it. I did a bunch of guerrilla marketing, posting it to different sites and such, talking it up in forums.. and for a developer control, especially one that was for a fairly new market of asp.net developers back then, we got quite a bit of interest. It was free, but we had plans for building out the control's features in order to sell a "professional" edition. So when we had something like 10,000 downloads and we were getting linked to by foreign web sites and put on a cover disk for the Italian PC Magazine.... it was really cool. Well, the project was unfortunately hibernated but it's limited success is still a good memory and quite confidence inspiring.

Well, I ran across a link to ArtForms on download.com. Apparently they had posted the thing back in 2003 and had gotten an additional, like, 8000 downloads, but I had no idea about it until last Friday. Thinking that 8000 people said "hey, that's a cool idea" and downloaded it ... all through no exra effort at all on my part gave me a crazy boost of confidence that "yeah, I can do this!" Now, a free dynamic image/button control is a long way away from a top down 2D online multiplayer tactics game, granted. But who cares about using things like logic and reason... My first product was listed as "popular" on download.com! And I don't intend for it to be the last.

3. When we first started this little endeavor, I accepted the fact that the chances for success (especially financially) were heavily stacked against us. I accepted the fact that, more likely than not, the only reward we would have was to be found in the journey itself. But as we close in on a completed project, I can't help but to get my hopes up.

I'm crazy excited about where we've gotten to in the game and the pieces keep falling into place. We'll officially be hitting alpha in a week or so and should be in a closed beta by mid-August. There's tons and tons of things to do, but I'm more excited and energized now about doing all those little tedious details than ever. I expect to see a lot more of 3am as we head into beta and then onto release. In the mean time I'm not sure how coherent my blog postings will be but I'm more certain than ever that when it's all said and done that it will all have been worth it.

4. As I showed off the latest bits of animation to my two boys last night before they went to bed, the youngest one said, very matter of fact like: "Daddy, you are really good at making video games." ... "But it sure does take you a long time." I think that pretty well sums it up, right there.

Oh.. I almost forgot my obligatory image. Well, I've got a new character but I haven't gotten her "glamour shot" ready to show off yet... so instead I'll send you over to this great google video that represents our target market:

video.google.com/videoplay?docid=7521044027821122670

Quote:
Mercy?? You want Mercy??? I'm chaotic neutral!!!

Speaking of which - anyone going to Dragon*Con this year?

-Andrew
theoreticalgames.com

2D Art Tips: Learn From My Mistakes

Andrew Douglas — 2006-07-16T01:01:29+00:00

Don't let me fool you. This is not an exhaustive list of all the stupid things I've done, but they are the highlights which may prove useful to have listed all in one place. My trials and tribulations the last few weeks with wrangling our game into shape on TGB have taught me a few lessons that I thought I would share. If you have suggestions or corrections here, please let me know. I may actually try to and get a bigger list with more people's input into a resource in TDN but that's for another day. I'm now a bit behind my self-imposed schedule so this is as good as it gets for now.

Note: As far as I can tell, I've not violated any of the EULA. Some/most of these tips can be pretty generically applied to either TGB or any other similar 2d engine, but it's heavily skewed towards TGB. TGB is the best of the bunch in my opinion, and I'm amazed at the power that's running underneath the hood. Kudos to the TGB team and the rest of GarageGames for putting together such a fine engine.

Background: My Bogle is not physics heavy, is not a platformer and isn't even real-time, so it may seem odd that I think my experience is relavent, but what we do have, and what we will be adding a lot more of in the next month or two is a lot of animations. We've recently incorporated the complete set of animations for just 2 characters into the game. Each of the characters will contain the following animations - Attack, Taking Damage, Dodge, Move, Rotate (clockwise and counter-clockwise as the characters aren't symetrical), Victory, "Death", the Selected Character animation loop and a small "idle" animation. Each animation is a different length, but in total there are over 150 unique frames of animation for each character. We intend to have 18 characters/variations, which gives us just shy of 3000 frames of animation. Some animations are oblong (like attack and move) but most are displayed on screen at around 113x113 square. Our source animations were created at 226x226 from Toon Boom as we wanted as much detail as we could get when we "zoomed" the camera in. Oh, and we currently have few particles and sound effects in, so this is going to focus on image related topics. If others have suggestions for sound and such, please feel free to send 'em our way as I'd rather not have to learn the hard way :)

Okay, so with our 2 characters in, and with pretty much all the default setting when creating the image maps and animations, the game was running at over 300 megs of memory. Clearly we were going to have issues if we were going to hit 18 different characters... and 300 megs was already 2-3 times my original target memory utilization. And that was without much sound and with few particle effects. And with a small map without any animations in it yet... So you can understand the state of panic that I was in. Now, without further ado -

Andrew's Helpful List of 2D Tips Created Based on His Close Personal Experience of Doing Everything Wrong at Least Once.

1. Don't preload all your image maps unless you are creating a truly trivial game. You know your imagemaps are all preloading when you hit your peak memory utilization before you even load your first level. :)

2. Allow unload on your image maps where you can. This can be slightly dangerous as loading and unloading imagemaps constantly is bad, but if you wonder why, once you hit your peak memory utilization, you never seem to get your memory back down no matter what's on the screen, it's because you aren't allowing anything to unload. When a character dies, let that bad boy go!

3. Don't create graphics that are larger then they will ever appear on screen. Now, we have some great graphics to use for close ups, but most of the animations will never be zoomed in on, and so keeping an image that's essentially 4 times bigger than it needs to be (113x113 is a quarter the size of 226x226) is the worse kind of wishful thinking. Besides, linear filtering isn't a great way to show off your graphical assets. Some day, when the market allows for extremely high memory requirements for games, monitors have densely packed resolutions and taking up a half a gig of ram for a 2d game is okay, then we will go back and use all those 226x226 animations we did... but until then, we're down to 113x113 for 90% of our animations now. The great thing is they look better than ever.

4. 800x600 or 1024x768 background imagemaps. Don't just throw a big old imagemap in as the background of your level. Your standard ImageMap needs to be a power of 2 in height and width (so 32, 64, 128, 256, 512, etc.), and TGB will do it's darnedest to keep the size in memory small, but it can't do much with one big old image. Which means the image is will be padded out the nearest power of 2, and that means a bunch of wasted memory. Try out a ChunkedBitmap as they'll most likely solve your problem. They don't need to be power of 2 and so you don't waste any of that space. If you really need a big image map, you may be able to get better utilization by slicing it into power of 2 sizes and just displaying multiple images as the background. Just beware of #5.

5. Beware the filter padding. TGB does a great job of removing those nasty edges around images caused by the linear filtering done on the graphics hardware, but if your expecting your image size or your cell size inside your images to be X pixels wide by Y high, bear in mind that if filter padding is enabled, then they'll be X+2 wide and Y+2 high. So your nice 128x128 image that fit so well in the texture will now be loaded into memory as 256x256. Ouch!
Turn off filter padding and add your own border or just create your images/cells just a couple pixels smaller and you'll be all set.

6. Size Matters. Stick with power of 2 sizes or as close as you can get for your animations as it will be far less stressful in the long run. See, we needed our images to be 113x113, so we were able to fit 9x9 cells into a 1K by 1K image, which is great. But originally we had 226x226 images, and they fit very poorly into a 1K square texture. We ended up not only wasting space in each texture, but with longer animation sequences, it meant we needed to use linked image maps. And so we went from bad to worse.

7. Avoid linked image maps unless you really know what you're doing. I clearly didn't know what I was doing, and I was just asking for it. You have to have the base image maps loaded in memory before you can use the linked image maps, and that means that you've got a bunch of memory potentially going to waste. They are a great feature, but in the hands of a fool like me, they can cause some serious memory problems down the road.

8. Aspect Ratio doesn't matter for your images in TGB.. The only thing that matters is the center of the image must be the same, relative to the other animations. See, we originally got confused. Okay, I got confused. In order for our rotation animations to work correctly with all our oblong images mixed up with our square images, I simply made all our square images into oblong images with white space. Poof! They worked, and our memory utilization shot straight up. Once I realized that it wasn't the aspect ratio that was making it work, and that all we needed to do was make sure the character was in the same relative position, we were able to cut all our square cells back down into squares and just pad the couple of oblong images so that they had the character in the same relative position as the square images. That was a huge savings and meant that we could throw all the square images into one 1k texture for each character. The oblong sequences are handled as separate textures now. I have trouble explaining this one well, and it's not clearly documented in the imagemaps documentation that I can see... if you want more info on this one, just holler.

9. Being ignorant is no excuse. Take the time to actually turn the preference settings on for tracking what's going on with your imagemaps every once in awhile.
$pref::T2D::imageMapDumpTextures = 1;
$pref::T2D::imageMapShowPacking = 1;

Look at the resulting games\imageMapDump directory and console.log. If your wasting more than 10% of the space for any of your imagemaps, or if you are surprised by the sizes or number of images in the dump directory, then it means you probably have some easy savings available to you. You should take a close look as well on the remaining images and packing details in the log as little bits of inefficiency repeated many times add up really quickly.

10. Run without the editors every once in a while. The editors are great, but you need to realize that your application may very well perform quite differently when the editors aren't doing their thing. Tuning memory can be especially difficult as the editor is loading up imagemaps and such that normally wouldn't be loaded. This is potentially good but also possibly bad for your application. It's great to get a drop in memory, but if your application starts chugging when you aren't running with the editors, it's probably because your imagemaps/textures are swapping in and out of memory more often. See, when the editors run, they'll force those textures to stay in memory, using up memory, but potentially significantly improving runtime performance.

11. Now that you've got the application running well, you're ready to ship it (okay, we've not gotten to that point yet, but it doesn't hurt to be prepared, right?)... but you've got all these huge images that don't compress well that will make your download size astronomical. Well, one quick way to reduce your png's is to convert them to indexed images. In memory, they'll still be as big as ever, but on disk they'll be, potentially 1/3 the size of the originals. Depending on the content, you probably won't even notice that they are indexed instead of RGB.

12. Now that you've deployed your application, you've got people complaining that it doesn't run on their computers (okay, that has happened to me). It's probably because your textures are too big. Here's a handy site for finding out which video cards support which size textures. zp.lo3.wroc.pl/cdragan/wizard.php - Choose D3DCAPS8 and choose MaxTextureWidth and MaxTextureHeight.
It would seem that if you are going to go with larger 1K textures, then there's little reason not to look at using 2K textures as only one integrated intel chipset and the old ATI Rage cards appear to be limited to 1K.

Okay, so I hope that helps. What did all of these lessons do to improve our games' memory utilization? Well, we are down to under a 125 megs on average with a peak of around 150 megs, and there's some more room to be had. The best part is that the additional overhead of each new character should be fairly low, so I'm hoping we'll be able to ship with around 150 megs peak memory utilization once we finalize our optimizations and get sound and music in. Feel free to throw in your 2 cents or just laugh and say "how come you didn't read the imagemap documentation"
... but we live and learn... or at least we live. While there's truth to the statement about not optimizing code too early, when it comes to designing your game's images and animations, an ounce of prevention is worth a pound of cure. Alright, enough with the cliches. Back to work.
-Andrew Douglas
theoreticalgames.com