Blog for Tom Bampton at GarageGames.com

GID23 and NPC Editor

Tom Bampton — 2007-08-20T03:06:35+00:00

Last weekend was GID23. Gary Preston and I teamed up again to produce a sequel to the old Teaminator game from GID 3.5, called Teaminator: Brew Isles.

As a base we used a heavily modified TGE 1.5 codebase that Ken Holst and I were working on over Christmas. The intent back then was to make Teaminator 2, but due to time and burnout it never got finished. It did, however, provide a ton of pretty solid tech to build upon.

This .plan is not about last weekend, so to read (a little) more about Brew Isles, and to download the finished game, have a look at our progress thread over on the Game in a Day forums.

Whilst on the whole the codebase was pretty solid, the weakest area by far was NPCs. We had most of what we needed for them, but it had not yet been battle tested. GID23 provided said battle testing, and this weekend has been spent fixing the issues. Gary has been working on improving the dialogue tree code, whilst I've been making an NPC editor. The former is probably more important, but the latter makes for better screenshots ;)

Stupid Beard the Stupid Pirate, from Brew Isles

Editing Stupid Beard the Stupid Pirate

The Blind Lookout, from Brew Isles

The character art is from Frogames' CS:Warriors and Commoners pack. The reason that the NPC editor was not only possible but easily implemented was due in no small part to Christophe's extremely well thought out artwork. Whilst working on Brew Isles, we found it to provide pretty much everything we needed on the art and animation side of NPCs. Actually, "NPC" is a bit of a misnomer as we are using it for the player as well. The "NPC" editor will also be repurposed as a player avatar customizer for the actual game.

Fun with Lua

Tom Bampton — 2007-07-25T19:19:28+00:00

Lua is a great little language. It's small and simple, yet powerful and flexible when you know how to use it. Embedding a Lua interpreter into an arbitrary application is easy, if requiring a little code verbosity.

There are many existing ways to expose parts of an application to Lua. However, most of them involve either writing a lot of extra code or running some external pre-processor to generate the extra code for you. For me, that is way too much extra work and additional points of failure.

Of course, if you wan't to expose C++ code to script, then it obviously requires some additional code that has to be written somehow. Whilst the external pre-processor route removes most of the impetus from the programmer, it requires another step in compilation and feels somewhat error prone. There are also meta programming libraries which do much the same thing, but make the C++ compiler do the work instead of an external pre-processor. They still require more re-definition than I was willing to put up with.

Wouldn't it be nice if you could make the C++ compiler do all the work for you ?

It was with that question in mind that I sat down last weekend determined to make it require no more then 1 line of additional code per function or method I wanted to expose to Lua. Oh, and I wanted to be able to do the same for calling Lua functions from C++.

Calling Lua from C++

Consider this Lua function:

function addSomething(a, b)
	return a + b
end

If I wanted to call this from C++, I'd have to do something along the lines of:

lua_State *L; // Defined somewhere

lua_pushnumber(L, 42);
lua_pushnumber(L, 69);
if(lua_pcall(L, 2, 1, 0)) != 0)
   // ... handle error ...

lua_Number ret = luaL_checknumber(L, -1);
lua_pop(L, 1);

Bit of a pain, right? Through some nifty template magic, I add one line of code to the application:

CppLuaDelegate<lua_Number, lua_Number, lua_Number> CppLuaFuncImpl(addSomething);

And I can then call the Lua function as follows:

lua_Number ret = addSomething(42, 69);

As an added bonus, I get full compile time type checking as if it was a normal C++ function.

Calling C++ from Lua

Calling C++ from Lua can be even more of a pain in the butt. You have to implement a function that gets the arguments from the Lua stack and then calls whatever existing C++ function you want. It's not rocket science, but it's boring and means you effectively have to implement two functions for every function you want callable from Lua.

So, instead, through more template magic, I do:

lua_Number addSomething(lua_Number a, lua_Number b)
{
	return a + b;
}

LuaCppDelegate<lua_Number, lua_Number, lua_Number> LuaCppFuncImpl(addSomething);

Then I can call it from Lua as follows:

ret = addSomething(42, 69)

Again, this is fully type checked and it only requires one extra line of code per function.

C++ Objects

Things get even more complicated when you want to expose a whole C++ object to Lua. Doing it by hand is generally not feasible, so you'd either have to use an external application or a metaprogramming library to do it. Either way is too much effort for my liking.

class LuaTestA : public LuaObject
{
   typedef LuaObject Parent;

public:
   lua_Integer mValue;

   LuaTestA() : mValue(0) {}
   DeclareLuaObject(LuaTestA);

   virtual void SetValue(lua_Integer val)   { mValue = val; }
   virtual lua_Integer GetValue() const     { return mValue; }
};

ImplementLuaObject(LuaTestA);

LuaCppMethod<LuaTestA, void, lua_Integer> MethodImpl(LuaTestA, SetValue);
LuaCppMethod<LuaTestA, lua_Integer> MethodImpl(LuaTestA, GetValue);

Which gives you an object that can be created in C++ or Lua and used/passed around in both. Using it from Lua would look something like:

foo = LuaTestA.new()
foo:SetValue(42)
print(foo:GetValue())

What's the point ?

The code will port to Torque reasonably easily, which would make ConsoleFunction() and ConsoleMethod() obsolete. Instead of writing a console method and a C++ method, you'd just write the C++ method and 1 additional line of code to expose it to script.

There would be no more worrying about converting things to or from strings, as that would all be done automatically. There would also be no more functions or methods that behaved differently depending on whether you called them from C++ or script. Oh, and all those useful console functions you currently can't call from C++, would be callable from both C++ and script.

Furthermore, since none of the implementation behind the templates or macros is exposed, the same interfaces could be used with any scripting language. This would mean that replacing TorqueScript with Lua would be a pretty simple matter of changing the wrappers and recompiling. That, of course, assumes that Torque has been fully moved over to the wrapper.

Whilst the Lua specific version of this is being used "now", the Torque version of it is a little more long term. I'll be starting the port once the Lua interfaces are more complete, but changing all the existing ConsoleMethods and ConsoleFunctions will be time consuming. It will also mean that the semantics of some functions/methods will have to change; there's quite a few that behave slightly differently depending on whether they are called from script or C++.

How NOT to make a game

Tom Bampton — 2007-06-11T01:38:45+00:00

In a previous .plan I ranted about Need for Speed: Most Wanted. At the time, I vowed never to play that game again. I also vowed never to buy another game from that franchise. Now, over a year later, I have stuck to that and will continue to. Another not quite so deliberate side effect is that I haven't bought any other EA game since, and likely won't do. How much of that is me being pissed off with the game and how much is me being pissed off with EA's output in general is another question entirely, but I suspect that both play a part.

Anyway, this blog is not about NFS or EA. It's about Test Drive Unlimited, Atari (publisher) and Eden Games (developer).

Today I stuck the game into my 360 to burn about a bit, only to be met by a complete lack of hardcore mode and the game thinking I don't have 6 achievements that I blatantly do. Yep, it fucked up my save. This by itself was enough to send me ballistic, but is not the end of the story.

After calming down (which took a flagrant disregard for the continued sim-life of anything that moved in Crackdown and resulted in me accidentally getting the Rampage achievement, which I thought was extremely apt timing), I figured that re-doing 6 achievements was not as bad as redoing the entire game. So, I took a deep breath, stuck the disk in the drive, and sat down to be bored shitless re-doing things I have already done and don't want to do again.

Then the game popped up a message saying something along the lines of "You're playing with an old save. Please don't do it again, or we'll restrict online play." The only reason I was trying to play with an old save was because the game fucked up both my current save and it's automatic backup. So, now I have a choice: don't play online, which sucks balls, or redo the entire game again, which sucks even more balls.

Accordingly, I would like to take this opportunity to welcome Atari and Eden Games to my "never play, reccomend friends never play, and tell everybody on the Internet how much they suck" list. Thanks guys, you have really made my day.

Whilst this is mostly a rant, we are all game developers here and there is one important thing to take away from this: Piss off your customers, and they will piss on you. And that is going to hurt an indie far, far more than EA or Atari.

Thinking Outside the Box

Tom Bampton — 2006-11-18T18:44:31+00:00

The Problem

This is the box. Within the box are all your preconceived ideas. Unfortunately, the box is also used by dog owners to clean up after their dogs. Since it has infinite storage capacity, nobody ever empties it. That's why dog owners use it ... nobody likes emptying boxes full of crap, and since it's infinite nobody has to.

The Bomb

I don't like boxes full of preconceived ideas and dog crap. The only thing they are good for is containing infinite amounts of dog crap and useless ideas. Some people have trouble thinking outside of the box. They are forever stuck in there, doomed to churn out crap ideas that smell of the box's contents.

The Solution

I lied. There is one other thing the box is good for. Blowing up.

The Stragglers

If you stay in the box, this is you. Sure, you might get something done. You may even ship it. But it will smell of the contents of the box.

If you have read this far, you may be wondering what the point of this blog is. You're not the only one, I don't know either.

Alive and Ticking: Now with exploding ants

Tom Bampton — 2006-11-03T08:45:40+00:00

When we were originally working on concepts for Alive and Ticking, Nauris sketched up some concepts for critters. After getting the A-Star code running, I threw together some simple AI using some past GID assets for placeholder.

At that time, it didn't really work properly and I since rewrote a bunch of the AI code. Whilst the critters have been there for most of this year, they were disabled. The other day I finally got around to making them work again so there was something to do in single player games.

If I remember correctly, the ant was made by Ben Chavigner and animated by Matt Mitman. The anthill was made by Logan Foster.

The AI is pretty simple. The ants run around aimlessly until they see a player, then they home in on him and explode. They will respawn at their anthill if it hasnt been blown up.

Screenshots don't really do it justice, so here's a video.

Click for video, ~9.4MB Zipped WMV

Fun with zips

Tom Bampton — 2006-10-28T09:36:26+00:00

As some may know, I maintain a "useless todo list." This list includes all the mostly useless things I intend to do someday, maybe. The problem with the useless todo list is that whenever I end up actually doing something on the list, it turns out to be useful.

One such item is the Torque zip code. I've been meaning to rewrite it for years. Since I am taking a break for a few days to recover from transatlantic travel, I figured I may as well mess around with the zip code.

So to cut a long story short, and get right to the interesting bits, the new zip code supports multiple compression methods (Deflate and BZip2 for now), the old Zip2.0 encryption and WinZip's form of AES encryption. It's also now a seperate library (well, kinda) so it can be used from outside the resource manager easily.

After completing the new zip code, I met with a problem. What to use it for? Clearly, the only sensible course of action was to zip up everything the game needs (including all mods and the top level main.cs) and run it straight from one big zip as a virtual file system. But wait! If I'm going to run it from one big zip, I may as well put the zip in the .exe. Then all I need to play the game is one file.

Since it's a bit hard to post screenshots that show this off, I'll just upload a build instead.

Stock tutorial.base, Win32 only, ~3.5MB

Alive and Ticking gets to Beta .... err, almost. (Warning: Screenshot Heavy)

Tom Bampton — 2006-10-02T18:31:02+00:00

It's been a while since the last .plan on Alive and Ticking. Many thousand lines of code and quite a lot of art later, we're finally getting really close to beta. I had hoped to get it to beta by IGC, but it's closer to a late alpha.

Boom!

We have two types of bombs, normal timed bombs and remotely detonated bombs (with the antenna). Remote bombs have an arming delay, the antenna flashes when the bomb is armed.

The crates break when blown up with a bomb. Blowing up crates is not only good stress relief, it also gets you power ups.

Both bombs are equally deadly.

Power Ups

There are a number of power ups available: Extra lives, bomb power increase, multiple bombs, remote detonators, diseases and invincibility.

When you pick up a disease, causes something bad to happen to you or a random player. There are three diseases: invertitis (inverted controls), personis firstitis (forces you into first person) and teleportitis (teleports you with a random other player).

Game Modes

There are currently three game modes:

* Deathmatch
* Team Deathmatch
* Capture the Penguin

HUD

The overview map displays the location of crates, players, power ups, bombs and flags.

The power up HUD shows your current power ups. When you pick up a power up, the icon bounces. The icons also rotate slowly.

The scoreboard shows the player's current scores. It also colors the names by team color and displays team scores in team games.

When you run out of lives, observer mode lets you watch the action from the point of view of any of the surviving players. This is a great way to pick up new strategies.

The craptastic lobby allows players to choose their team and chat, and the admin to setup the game. All clients GUIs update when the admin changes any options.

The Levels

I bet by now you're thinking "damn, that looks really blocky." That's because the above screenshots came from a gameplay test level. The levels are capable of so much more:

DTS shapes can be used for both "walls" and as an additional prop for the floor.

They can also be rotated have particle emitters mounted to any node in the DTS shape.

The level code also supports animated blocks. This is a bit tricky to show in a screenshot, so I'm not going to try. DTS animation will be used to make the level respond to explosions as well as ambient animation.

Ticked

I'm not ready to talk much about Ticked yet. The above screenshot is of the prototype, and thus is only intended to illustrate the basic functionality.

Thank Yous/Credits

Without the art team (Nauris Krauze, Craig Fortune and Matt Mitman) the game would still be a very early alpha and a very different game. Their ideas have been just as important as their art.

Paul Dana has been a huge help whenever I've needed a sounding board or had issues with 3D math, which has long been my weakest area.

Justin DuJardin has been a big help with Ticked, and with some nifty things that are currently secret.

Everybody who has helped playtest this since day 1. There are too many of you to list, so I won't try just in case I miss someone. You all know who you are, anyway.

Where next ?

I'm not telling yet :)

Internal Name Operator

Tom Bampton — 2006-09-08T00:03:43+00:00

There's been some discussion for a while about internal names. They were originally implemented in TGB to make GUI code a little easier to write ... but findObjectByInternalName() is long and irritating to type.

I think it was Paul Dana that suggested a new operator for referencing objects in a group by their internal name. After talking with Justin about it today for the umpteenth time, I finally got around to implementing it:

Ben mentioned that -> could be confusing to programmers used to C++. He does have a point, but is it worth worrying about ? If so, what would be a better operator ? All I can think of is "#", ".." and ".>" ... but they all feel a bit strange.

Learning C# the insane way

Tom Bampton — 2006-08-31T11:50:11+00:00

Learning C# is one thing that I've been putting of for a long time. The only reason for that was I haven't needed it and I knew I could pick it up really quickly.

After finally getting some code working that has been seriously annoying me for the past week, I figured I'd push my luck and see just how quickly I could learn enough C# to be productive.

It is obligatory when learning a new language to write a Hello World program. You are not a real programmer if your first program in every language you know was Hello World. The only problem with Hello World, is when you have learnt as many languages I have Hello World gets really boring.

So, how do we spice this up ? It's obvious! Write a BrainFuck interpreter in C# and implement Hello World in BrainFuck!

I did actually do Hello World before BrainFuck just to make sure I had the project setup correctly and because, well, it's the done thing. Here's a time breakdown:

* Learning enough about C# to get started: 6 minutes
* Project Setup/Writing Hello World: 5 minutes
* Skimming docs to learn what I needed to know for BrainFuck: 15 minutes
* Total Time: 26 minutes

It took me a little over an hour to implement the interpreter, but that would have been the same in terms of time regardless of what language I'd used.

If you want to play around with it, you can download the interpreter here. You'll need .NET 2.0 installed to run it. I haven't included the source because since it's my first C# app and I'm a C++ programmer, I've probably done some things that would cause C# programmers to swear ;-)

It's a command line app, for details on how to use it, see the screenshot. I ganked the example BrainFuck code from the Wikipedia article linked earlier.

A game in 20 minutes

Tom Bampton — 2006-08-17T01:39:36+00:00

So far, this week has been filled with debugging hell which culminated today in the discovery of a bug in BitStream::writeBits() - but that's a completely different story, and one that's being dealt with appropriately.

On Monday I was feeling the need to make something completely pointless, in around an hour. So I asked Paul if he had any ideas, and he suggested implementing Conway's Game of Life. After a bit of umming and ahhing, I figured it was a pretty good idea and set about implementing it in Ticked.

A time breakdown of the initial "GID" is as follows:

* Neighbour Counting Algorithm - 8 minutes
* Game of Life Algorithm - 8 minutes
* Adding the HighLife variation - 1 minute
* Haxing the level code - 2 minutes
* Talking to Paul and pressing F5 - 1 minute

Total time about 20 minutes. It even worked first time, so no debugging required.

Unfortunately, because Ticked is currently semi-secret, I couldn't post a blog about it. So, I spent a couple of hours spread over yesterday and today copy/paste/hacking the Game of Life into a standalone "game."

You can download the game here: Win32, Zip, 2.15MB

I couldn't be bothered to do a Mac build, sorry ;)

WASD and the Mouse Wheel control the camera. Use the left mouse button to paint living cells (blocks), and right mouse button to paste dead cells. Then you can either use the Step button to single step or Run to step automatically every 500ms. If you want to try out the HighLife mode, check that box.

You can modify the game state at any time (running or not) by painting with the mouse.