Game Development Community

dev|Pro Game Development Curriculum

Juggling cats.

by Phil Carlisle · 09/21/2007 (10:11 am) · 31 comments

Balls

To me, part time indie development always feels like juggling. Trying to juggle work commitments with your indie life can be a very difficult thing.

images.wikia.com/uncyclopedia/images/thumb/1/14/Kittenjuggler.gif/118px-Kittenjuggler.gif

Almost like juggling cats.

Anyway, I wanted to post about how things have gone since last year, just so I have some retrospective next year to think about.

Around this time last year, we were working on Air Ace, our multiplayer dogfighting game. It was starting to look good, but we had a big issue with networking the flight physics.

Air Ace Screenshot (large)


To cut a long story short, after some deliberation, we realized that we couldnt ship Air Ace without the physics being fixed and we couldnt find anyone capable of fixing it. I know that many of you would have
probably fudged something together, we did consider that, but truthfully I had a very specific feel in mind for the game and without at least some semblance of the flight model I wanted, I dont think I'd have liked the game. I'm not about to make a game I dont like playing myself.

So, we took the decision to shelve the game until such time as we found someone to work on the physics again.

Our next plan of action, was to take the multiplayer aspects of Air Ace (team based combat, various game modes etc) and move it into a new game. This was to be a NON physics based game (lesson learnt there).
So we chose to use tanks, as they are very combat oriented, have less issues compared to humans when it comes to content and generally we like em!

And thus, Panzer Ace was born!

We did some initial work, getting a few tanks from 3drt, getting them rigged. Adding in all the Air Ace code. One decision we made, was that given we didnt need the vast horizon distance that we did in Air Ace,
we would use TGE instead of TGEA, in order to work with the more stable codebase and reduce our system requirements.

So we set about building Panzer Ace. Here I want to talk you through a few of the interesting problems we've come across in its development.

We started Panzer Ace by taking a load of the code we'd created for Air Ace, backend systems, scripting, plane choice etc. Ported it across to TGE and stuck it in. This saved us many months of work and seemed to go pretty well. However it later caused us some issues, which I'll go into at the end of this post.

Because we had to change to Tanks, our starting point for the new game would be to take the tank pack and essentially replace plane* with tank* in the game. Anywhere you'd have selected a plane, you now
selected a tank. Simple really.

Only, well, there are issues with the tank pack as it is now. Its still a great starting resource, but using it for a scalable multiplayer game is not really a good idea. Let me explain some of the problems we encountered.

* Treadmarks - This was a feature of the tank pack. It produced pretty nice looking treadmarks on the terrain as you drove it around. Unfortunately, the way this was implemented wasnt really suitable for
a multiplayer game, as it constantly emitted new decal objects. Essentially we'd see the object count in the game spiral as we added more players into the game. The result was that we had to ditch the treadmarks, although we do have a solution to implement further down the road (using a ribbon of quads).

* Control system - This wasnt really an issue with the tank pack so much as our own desire to have a system that felt "nice". I know this kind of thing is pretty subjective, but I think a big part of being a
designer/developer is that you have to take responsibility for how things "feel". I didnt like how the tank pack felt to control. The plan was to try out a scheme I knew I liked from playing Call of Duty. In that game, you control tanks using keyboard and mouse, but the mouse is essentially a free look (spun around the turret at its axis) and the turret turns to follow where the mouse cursor lands. After some playing around, I got this system working reasonbly well. It still has a few bugs but I didnt really worry about those once I felt the system worked.

Strangely enough, the control system led me to another issue. That of targetting, or rather, the ease of hitting the target. Its hard to explain this, but somehow the ease of targetting when you are firing fast moving projectiles with no ballistic drop simply doesnt make for an engaging game. It is simply too easy to line up your cross hair on a target and pull the trigger. It felt like there was no skill involved and a multiplayer game MUST be about the relative skill of the players involved. A skilled player must always be able to beat a lesser skilled player over an average number of games. This is a very subjective thing I know, but having played a lot of combat based games, I know that what drives people, is feeling thier skill get better and that somehow the skill involved has a direct effect on the outcome of any given combat.

* Ballistic trajectory - The outcome of this, is that I decided to have a look at the difference between direct trajectory (i.e. fire projectile along a straight line) versus ballistic trajectory (where the projectile drops with gravity). Well, I can tell you, for a tank combat game, introducing ballistic trajectory really helped the feeling of skill! it is a minor change for the code, involving twiddling the projectile datablock, but it sure makes a hell of a difference to the feel of the game. Where as before I could just blam away at targets, now I had to consider the flight time, distance, relative motions etc. I had to lead the target, had to consider the
drop of the shell, in essence it added a much lacking element of skill.

* Optimisation - this will have to wait for another post to go into in more detail, suffice to say that often times, performance can be gained from tweaking the details and considering what really matters to the game. I've done some tweaks recently that have sped up the game immensely and took almost NO time to do the tweak, but took a LOT of time to figure out how and what to tweak. I want to pass on some of
that process, but it'll wait.

www.militarygarage.com/gallery/main.php?g2_view=core.DownloadItem&g2_itemId=1835&g2_serialNumber=1
Early Panzer Ace screenshot

So back to the history...

Production on the game was going pretty well at the start of summer. Barring technical glitches, we could definitely get a multiplayer tank game working well, so we were looking at the various options of how to
monetize it. Around this time, a few of us got into crunch in our day jobs, production fell off quite a lot. In fact a lot of the early summer was that way. As with any spare-time thing, it can fall off quite quickly when large projects happen at work. Both myself and Thomas had major gigs happening over the last year and at times that has hurt the game development rather more than we'd have liked.

So a few months back, as we both got free from the projects that had been eating away at our time, we had a good long look at the project. It had come some way from the Air Ace changeover, but looking at it as
a commercial venture, we knew that we had a long road ahead. Given our time available, we had to make a big decision about how well we could deliver what is essentially a service based game. Online games must always be thought of as a service in my mind, because they require a longer term commitment to keep the game fresh, add content, make sure servers are up and running etc. Add to this, the problems of building a player base, keeping forums alive, billing etc. It all came pretty clear that we simply didnt have the time to finish the game we wanted it to be. There simply wasnt any way of building up the game with
enough players, managing the community etc. We could technically complete the game, but we simply couldnt find the time to work on the business and marketing side of it post release.

So we decided that rather than push forward with the online game. We'd take what we had from that game and push on with a scaled down offline version of it. Taking what we had produced and scaling the game down in terms of its back end business requirements and essentially produce a more intense single player combat game from it.

Since that decision, we've been working on AI to flesh out the singleplayer game. I'll post another post soon about how that AI has been working and the fun challenges it produces. We've also been working on mission designs and scripting. It turns out that its actually quite fun doing singleplayer mission design. Although actual level design for singleplayer has quite a lot more to it than multiplayer, you can at least isolate the requirements and build mission specific helper code (for an example, I built a message into the AI code recently that allowed me to tell a whole platoon to move or stop moving from the mission script).

So we're pushing on with this COD like singleplayer combat game with gusto, even the early completely unpolished mission scripts feel like they could eventually be quite nice. Hell, even the tutorial scripts Thomas put together showed some promise! So we're pushing this forward and we're aiming for a chrismas release, with as many highly polished levels as we can muster. Push push push.

And then the IA thing came out.

Now there's a spanner in the works. A service that seems to offer the business logic of multiplayer games a shot in the arm. A service that kind of fits in with our old plans for Panzer Ace.

Our goal right now, is to really put our all into getting PA singleplayer completed. After all these years of not having a product completed, it really is do or die. To do otherwise would just be insane. Even if there is a business case for going forward with a multiplayer version again. I think at this point, we dont really care
about the business issues anymore. Its about shipping. No matter what.

Longer term, we will have to wait and see how the IA plans pan out. How that its with what we were working on with Panzer Ace multiplayer (or indeed if Panzer Ace fits in with IA), but it sure would have been
nice to know six months back :)

Anyway, thats where we are. I'm not going to show you more shots as we still need to flesh out the issions and get theme playable and script complete before we hand them over for artwork (the method we're working on right now, is that we script up the mission gameplay, using whatever stand in art we need. Then we'll hand that almost competed version over to the artists in order for them to complete the level design and assets for the missions. But getting the missions to feel right in terms of pacing and action is the main goal right now.

Man, it is an interesting time to be working on this stuff. Singleplayer design is a blast and totally different from the multiplayer stuff.

It would just be nice if juggling those cats were a little bit easier.
Page«First 1 2 Next»
#21
09/22/2007 (6:52 am)
Tim: at the time we switched there were a few unresolved issues that pushed us over the edge. That and of course the lack of shader support requirement kind of made it work. Hindsight might say if we chose right or wrong, but it was a rational choice.
#22
09/22/2007 (6:56 am)
Phil, trust me, I understand ;)

I don't own TGEA and just wanted to know if it still had the older TGE terrain included (and if it worked) as advertised, that's all.

If you don't mind me asking, which physics engine were you trying to use for AA?
#23
09/22/2007 (9:20 am)
Lol, I didn't mean to start a TGE vs TGEA debate. I wasn't implying that any game shouldn't be built with TGEA. AA should definately be TGEA because of the larger terrains. For that type of game support for vast terrains is a must. And he aimed for that platform from the outset.

What I was getting at is that the situation must be judged in terms of how much it costs you. Any action has an associated cost in time. The statement that other guy made, that he couldn't see any reason why everyone shouldn't port their projects, shows that he doesn't have this mindset.

Saying something is "the future" is meaningless. Being "the best fit" is a much better goal. TGE is the best fit for me, and for Panzer Ace, because of it's superior terrain editing tools. And because of how limited my time is. If I want to move a hill left a bit I don't want to leave the program, build it in L3DT, jump through some other hoops, etc. The price is the terrain doesn't look as great, but compared to the cost in time, judged against the aim of finishing, it is worth it.

@ Phil : With the whole IA thing and GG talking about helping devs, why not talk to them about helping with AA ? They got some sort of stable multiplayer physics into marble blast, and AA seems like a great candidate for their aid. It could even go on their browser thingy, maybe ;)
#24
09/22/2007 (9:22 am)
Hehe, no, didn't understand it that way, just only that sentence the other guy made caught me. Nevermind :-)
#25
09/22/2007 (10:59 am)
Tim: We contracted a guy to do the physics engine. It was actually shaping up pretty well, but had issues with networking. Basically over time some instability would build up. Unfortunately the person involved got a lot of contract work, so often we'd not hear from them for a few months.

Basically, it ended up being impossible to proceed that way.

Gareth: I dont think a marble's physics is going to work out to replace an aircrafts physics. Of course we'd like to see somone come on board and give us a nice flight physics engine that works well in TGEA and over a network. Given that AA would be a breeze.

It was a great learning tool and at some point, if we have the right person for the task, we could definitely get it back into shape. But honestly its unlikely. I think the skillset is kind of niche for that kind of thing.

Incidentally, I did try and license the flight model from other older flight sims (Air Attack for instance), but the creators werent interested in having competition :)
#26
09/22/2007 (11:06 am)
@Phil: try posting a request here: OpenPlaneSim
This is a very old fan site for Fighting Squadron: Screaming Demons Over Europe from former Parsoft company.
This missed game led them to a complete company failure.

I don't remember names of people on that forum, because I've been in contact with them almost 10 years ago, but I know there are few good programmers here, and at least as released a WW1 flightsim, using the so called OpenPlane technology (another failure from Parsoft).

You will also notice a few good modelers. :)

Hope it helps.
#27
09/22/2007 (12:37 pm)
Phil : I know they aren't the same, but I meant more that they will have some experience with keeping physics synced over a network and suchlike.
#28
09/22/2007 (2:27 pm)
The best thing about being an indie game developer is the freedom to be proud of your work. If you don't have that, what's the point of being an indie game developer? I admire Phil and the rest of the AA team.
#29
09/22/2007 (9:16 pm)
Quote:
I admire Phil and the rest of the AA team.
Me too. I always enjoy reading Phil's blogs and usually learn something from them.
#30
09/26/2007 (11:06 am)
Here's an interesting story:

http://worsethanfailure.com/Articles/The-Cool-Cam.aspx

Maybe you need a cool cam ;)
#31
09/26/2007 (11:16 am)
Cool story Joshua! ;-)
Page«First 1 2 Next»