next »

[cijolly]

Hey everyone, I'm fairly new to the whole TIGsource community (as in, this is post 3). I've been working on a game for 6 weeks now, and have been logging my progress as I go. This puts me in the slightly unusual situation of having a 6 week buffer leading up to my current progress.

An alpha demo of the game thus far is available at
http://droneuplink.webs.com/download.htm

10 levels, 2 game modes, 15 weapons and 15 enemies.

Current screenshots and plot are available at
http://droneuplink.webs.com

Anyway, near as I can figure, the difficulty of putting this much delayed document on the internet is slightly less than the odds that someone could learn from or be interested in it, so the utilitarian in me insists I post it regardless.

Here goes!

[cijolly]

Developers Log.

Hey internet. I've been into game programming for a long time. In fact, I was probably 8 when I started playing with click and play and fooling around in the Qbasic that I was delighted to find came installed on my 486 (because of course, I had no internet with which I could have downloaded a compiler had it not been there). However, toolsets like click and play were too limited, and while tools like c++ and directX were extremely powerful, I spent far more time screwing around getting things to just work than I did implementing cool gameplay features.
Now XNA has come along. I'm just starting with it, but as far as I can tell, it's everything I'm after. All the power of code, without all the low level capabilities which I honestly don't care about or understand well enough to use to my advantage.
I'm going to write a paragraph each day about what I've done, the problems I've found, and how I've solved them (or not).
The goal is to have a completed 4 player on screen Robotron/SmashTV/Crimsonland clone within 12 weeks. The 4 players will each have their own viewport so be able to move independantly.
I will begin with absolutely essential features, and add more interesting but less vital features daily.
Whatever I can get done in 4 weeks is what will be included in the game. At this point I will take a step back and restart the code from scratch, making everything tidy, efficient, and polished. Well, that's the plan. The alternative would be to spend another 8 weeks working on my adhoc prototype codebase. I have a feeling that the former philosophy will yield a better result, if I have the discipline to stick to it. Watch this space 4 weeks from now for back peddling and rationalisation.

[cijolly]

Monday:
Today I found an excellent XNA tutorial at http://www.riemers.net/eng/Tutorials/XNA/Csharp/series2d.php
 It talks you through the basics of sprites, keyboard input, and sound. It also says a bunch of other things on more specific and advanced topics, but basically those 3 things are what I think are essential to make a game. I can always go back to the tutorial if there are more advanced features I want later.
Using the tutorial I managed to:
Start a project.
Display 4 character sprites.
Control one through keyboard input.
Play sounds on demand.
So, in one night I have accomplished what took me a kg heavy book and 2 weeks work under directx7. Certainly a good start.
Using google, tutorials, and microsoft resources, I figured out how to draw multiple viewports.
I wrote a function which checks how many players there are, and lays out up to 4 viewports appropriately.
Next, in the draw function, I added a line to subtract the current viewport's player's position and half the viewport size from the rendering. This locks the player in the centre of the screen, and moves the world around them as they go.
So: 4 players in 4 viewports who can move around. Not a bad start.

[cijolly]

Tuesday:
Today was collision detection day. My previous efforts involved in depth
physics engine where arbitrary polygons could bounce of each other, see
saws worked, etc. Great fun to play around with, but it took months and I
never got a game out of it.
So, I wrote a super simple collision detection function based on
pythagorous and the sum of two radii. This most absolutely basic of
collision detection routines will handle my character collisions if all
else failes. However, adding a simple physics engine and pooltable physics
is fairly high up on the feature list, so once the other essentials are up
this could be upgraded. But, for now, it's done and it works.
I grabbed a line segment - circle collision detection function off a
website. I'm not sure how it works, but it takes a line and a circle, and
it returns 0, 1, or 2 intersection points. This will certainly work to see
if a bullet collides with a player or enemy, and can likely be expanded
when pool physics enter the game.

[cijolly]

Wednesday
Today was fairly unremarkable. I didn't meet my targets for the first
time, but that was mainly due to reevaluating my feature list. A grid of
terrain isn't essential. It's quite high up there, but other things are
more important first.
I made a projectile class. This is created, travels, and dies when it ages
or strikes a player. I made a function which takes a line and a circle,
and gives back a struct which says if a collision has occured, at how many
points, and what those points are.
I did my first work with lists. Very easy to make, slightly harder to
remove objects from. I solved the problem by iterating backwards through the list of
projectiles, and deleting the projectile from the list by reference if it
was flagged for destruction. I don't know how clever c# is, so I'll have
to make sure this isn't causing a massive memory leak.
The weapon class was fairly straight forward. At the moment it exists as a
repository for the values that projectiles are created with.
Weapons need to be added to a list, linked to players, and set to update
with regards to firing delays, ammo, etc. Need to actually plan how I'm
going to handle this. It looks like I'm getting into pointer territory...

[cijolly]

Thursday
Again, today didn't go exactly as planned. I created a zombie class, and they track players as intended. When I implimented the code to allow bullets to collide with the zombies, I hit a problem I'd been expecting: With every bullet looking for a collision against every zombie, the calculation goes exponential.
So, time to impliment broad phase collision detection.
The two ways I've seen this described are grid based, and spacial partitioning. I initially tried to go with a grid based approach, but couldn't find any hand holding tutorials on making a two dimensional array of lists to put the objects into. Also, I've always hated the thought of restricting myself to a certain world size.
Fortunately, I stumbled across a very good ziggyware tutorial on sweep and prune. All I had to do was make a sweepandprunedata struct, and load it with each zombies left and right edge, which edge it is, and an ID number.
C# can sort structs by a value in the struct, so I sorted by the 1 dimensional point. This leaves me with an ordered array of every left and right edge of every zombie in the game. Then, I iterate through this list: Every time I find a left edge, I enter a sub loop that iterates through the list again. When this second loop finds a left edge, it performs narrow phase collision detection. It ignores right edges (Because, if there is another objects right edge between the current objects left and right edge, then this objects left edge would already have been processed, and checked for a collision with the current left edged object). When it finds it's own right edge, the sub loop exits, and the main loop iterates through the list looking for the next left edge. Using this method, I can easily get 1000 densley packed zombies colliding with each other with no slowdown. Certainly plenty for players with a quarter screen viewpoint. If I can constrain the ai to cluster them less, I can get more.
However, this is just zombie zombie collisions. Zombie projectile collisions would require an enourmous amount of coding. Also, the collision detection between circles is functional, but ugly and jerky. To do a good job, I will need a better circle circle algorithm, and physically accurate collisions.

[cijolly]

Friday:
I took the afternoon off coding. I am fully aware that if one were to draw
a graph of what I've achieved each day this week,  it would be a linear
decline hiting 0 today. So, if I was going to follow the trend, I'm due
for negative productivity tomorrow.

[cijolly]

5 Weeks later.

Well, it looks like the low level, day to day trials and tribulations aren't particularily interesting. Fair enough. I'll try to restrain myself to just talking about the most interesting elements.

Two weeks were put into Artificial intelligence. This was fun when it worked, maddening when it (frequently) didn't. Some of the ideas I played around with were:
Enemies who flanked the player, spreading out to fill the screen while narrowing in all the time. This took the most time and elaborate experiements, as well as the most embarrasingly brief amount of code when I had a revalation as to how to get it to work.
Experiments with: Beziers, Enemies who control flocks of Boids, enemies who plan, jumping enemies, sumo's, healers, generals, and more. After gleefully throwing away 75% of my work, I'm left with:

Flanker, Charger, Cowardly sniper, Ambulatory Bomb, and Bomber.

The next two weeks went into level elements and the level editor.
I'm still not certain this is the best approach, but it's what I've got. There is a big bank of switches. These are triggered by various events, and game items key off them.
At the end of the two weeks, my level elements consist of:
Walls, pits (the AI could use some pointers on not, you know, plummeting), enemy and item spawners, multiple level exits, and level specific briefing and debriefings.

With the truely, truely dull task of the level editor behind me, I've gone onto more fun jobs.
I had a go at building a website. For an evenings work, it was pretty rewarding.

Next up was a graphical update. Having little to no artistic ability, it was down to code to make this thing shine. Observe:







Then pathfinding. These morons will never pathfind their way out of a wet paper bag, let alone a maze (or even a particularily confusing corner). But, they can get around obstacles well enough, and only fall into pits when pushed by their uncaring comrades.

Most recently, more content and balancing.
I added a number of new enemies: Fire trailer, Splitter, Thief, Teleport trooper, Turret, Stealth trooper, and souped up, miniboss versions of the original 3.
The failed experiments are still interesting gameplay concepts, so will probably be revisited at some point.

So, all of the major hurdles have really been overcome. From here on, it's just about getting the most bang for my buck with regards to content generation.
From what I've seen so far, the most value can be gained by working on the area that the game is weakest. I know it seems obvious, but the quality of the game seems to be the literal multiplication of every factor going towards the game, with items of a low percentage quality dragging the rest down. For example, when the graphics were awful, all the hard work in the other areas went to waste as there was a times zero on there. One days work on that has made the whole game much better.

So, from that point of view, where are the zeros in this game?
There are no levels, no story, no music, no sounds, no powerups, and no visual feedback.
The beta of the game can be quite happily be released with only the onslaught mode level and no story, so I guess music and sound are up next!
After that, more visual upgrades with particle effects and animations.
Then, features I have to quantify before I can do the levels: Powerups.
Lastly, the meat of the matter: Levels and the story!

[FishyBoy]

Sounds interesting! 4 player co-op is always excellent.

[cijolly]

Thanks, I certainly hope that will turn out to be the case!

[cijolly]

Metrics:

Well, with most of the structural code in place, I'm still bashing away at polish and balancing before I begin work on the levels.

As an experiment, I graphed the damage per second done by all the weapons, taking into account as many factors as I could. This is the result:



The equation is:
shots/second * damage/shot * barrels * hits/shot (eg, piercing rounds, explosions) * (timetoemptyclip / (timetoemtpyclip + reloadtime).

At the moment, the game feels a little...well, light, or brittle. This could easily be due to the fact that the best weapons can kill 10 enemies per second.

However, even using the super weapons, the player dies fairly often. The sheer number of enemies means they can die in the reload time.
So, the next job is to make everything feel more solid. Less, Healthier(so they don't go down as quick), slower (both in moving and aiming, so the player doesn't go down as quick) enemies, and a more even distribution of weapon damage should help. All and all, an informative exercise.

[Jóhannes G.]

railshotgun = 

[Tenderfoot]

Looks good, man.

I laughed a bit when I saw "monday, tuesday, wednesday... 5 weeks later." good devlog.

[KennEH!]

This is looking good. Can't wait to see more.

[cijolly]

Thanks for the replies, guys!
The rail shotgun is indeed made of pure win. Balancing something that can shoot through lots of enemies, as well as walls, makes it so situational that it's a pain to get just right. If you nerf it too badly, it becomes useless against anything BUT big hordes. I guess two weapon weilding should solve that, though.

Yeah, I didn't really get the log off to a great start. But, with just major milestones now, it should be a bit more interesting!

And, on the topic of seeing more...well, there isn't much more to see, per se. The past few days have been devoted to work of a more aural nature, which doesn't lend itself terribly well to screenshots.
On the other hand, with that part done, I've begun work on making levels. I'm going to get 10 arena levels and a play til you die onslaught mode ready for release. The content will definately be made this weekend, and will be released for playtesting, barring any unexpected "oh my god, I've but all this time to something that only runs on my own computer" bugs.

[cijolly]

Well, the sound effects (except music) 10 arena levels, and an onslaught mode which sends randomly picked waves of enemies is all done. It's worked on all the computers in my flat right off the bat, so it seems to be bug free in that regard.

So, without further ado, with 10 playable levels and 2 game modes for yourself and between 1 and 3 friends to enjoy (ok, maybe just a little further ado), Drone Uplink!

http://droneuplink.webs.com/download.htm

Any feedback is much appreciated. Too hard? Tell me, myself and my friends are probably too good at this game by now. Too easy? Well, maybe we suck more than we think.
Stupid features which exist in the game, or good ones that don't? I'd love to hear about them!

With 5 weeks to go until the end of my elective, I'm going to concentrate on content and polish from here on in. So, a story mode, more weapons, enemies, powerups, and sparkle.

[cijolly]

4 player design challenges.

I've begun working on the levels proper, and thought I'd share some of the foibles of designing a game for a variable number of players. If anyone's ever thought "why didn't they make Game X coop, you've just got to chuck another player in!", then this might be enlightening.

Level considerations:
4 player design experienced by 3 or fewer players.
This is an interesting problem: You've designed an interesting level which has puzzles or combat encounters that require more than one player. However, making a game that is only playable by 4 players somewhat limits your audience. A simple example is a door that requires 4 players to stand on switches at different points in the level to open. Only 3 players means the puzzle is impossible.
The way I've been soliving this is a little blunt, but effective. Each trigger in the game has a minimum number of players. If less than that number are playing, it will either be set to always be off (eg, an enemy nest wont produce enemies if there aren't enough players) or always on (eg, the button will always be pressed with less than enough players).

1 player design experienced 2 or more players: The presence of 4 players makes scripting much trickier than you'd think. One way doors, things collapsing behind the player, ambushes, cut scenes triggering...anything that happens over a limited locatation is a pain when you throw more players into it.
So far, the main solution that I have been using is to make triggers that are number of player sensitive, so the ambush will only be sprung when all players are standing in the correct area. This gets tricky though, because players have a tendency to wander off. So, anything like that has to be designed with a coralling method (eg, one way doors that let players into, but not out of an area. Of course, it didn't take much testing to find out that players don't like being trapped on the wrong side of a one way door, so will get their allies to let them out from the other side, rather than all being stuck). This kind of coralling kind of broadcasts what's going to happen though, so it's not something to use all the time.
The other broad solution would be teleporting waypoints, like in Halo. If you want all the players in the same place, force them. This gives you single player scripted event triggering with multiplayer consequences.

AI. The AI has to be able to prioritise, target, track, and respond to multiple targets. It doesn't sound like much, but it's certainly harder than just tracking one player.

[cijolly]

After a bit of a break after getting a something playable out there, I've gotten back into development. Note that none of these features are in the release demo yet.

The past two days have been pretty productive, with me suppressing my urge to procrastinate and doing what always seems to be the most difficult part: Adding entirely new features. Building on old features always seems so easy. You know the code is working, a lot of the decisions have been made, and you make a lot of quantitative progress.
Something about starting something new always seems to lead to procrastination on my part. Even though, to be honest, the framework for a new feature is really only half an hour, or less, of work. However, it adds something qualitatively different to the game, giving brand new faces rather than polishing existing ones.

So, I've now added:
1. Powerups. If your idea of realism includes becoming faster, stronger, ethereal, or some gaining some other super characteristic from stepping on an orange circle, then this game is extremely realistic now.
2. One shot items. Your standard Little Bomb, Big Bomb, Lightning Storm, Newtons Ball, and other "too powerful to let players just pick up and use whenever they want" items. These items are pretty satisfying to use, due to the fact that they use the players direction when they fire. So it's not enough just to run to the super weapon, you have to side step it and cartwheel back to send it flying in the chasing enemies direction.
3. Vehicles. The core groundwork for the vehicles is done, and a simple motorbike with dual machine guns/rapid fire shotgun is up and running. Next up will be vehicles that multiple players can pilot simultaniously, mechs, vehicles with rotating turrets, and whatever other ideas I come up with. I'm thinking of a 4 player tank where everyone controls one of four wheels. Wheels can move forwards or backwards independantly, with the four players needing to cooperate to steer the tank and aim the big murderlicious beam cannon. On top of that, each player would be responsible for a single weapon system, utility feature, or a big glowing arrow which directs the other players which direction they should steer towards.

[oneup]

i'm on mac, so i can't play your game,
but looking through your website
i am amazed by the backstory / atmosphere you created through the texts.
woohoo!!

[mokesmoe]

I can't get your game to work, and it's probably vista.
Do you know if theres any way to get your game to work on vista?