You play as a castaway on a desert island, enjoying a peaceful life with your magic box, which supplies you with anything you want--including unlimited rum! One day, though, pirates get wind of it and come to steal it out from under you. Armed with the tools in your magic box and your wits, you must set traps to stop them before they reach the box and carry it off!
I want to take a moment to apologize for the GUIs. They weren't optimized for use in the Unity Web Player so they're all way off. Rest assured that they never appeared like this in the original build.
I'd like to take another moment to point out the biggest limitations that our projects typically suffered from in our 3D game design class before I go into the game itself.
So we have a group of overextended but enthusiastic and ambitious students working on 3D gaming projects in a program that's only available part of the time, and it's a very limited amount of time already...
Frankly I'm impressed we even got this far. The time was four weeks for each project, but realistically I'd say it'd be generous to assess any of them as having been coded in about 48 hours. Art assets had more time because we didn't have to use that specific lab.
The game is simple enough. You're on an island, you have a box, there are emplacement points scattered around the island, and you move from point to point, build traps on them, return to the box for more supplies, and then go build more traps in the hope that you can outlast the waves of pirates as they travel along a series of paths towards the center of the island in order to steal the magic box. If enough pirates reach the box to carry it away, you lose. If you antagonize the pirates and they kill you, you lose. It's like an Atari 2600 game protruding into present time using a Mac as a conduit to our reality, which is about as depressing an analogy as can possibly be made but is true nontheless. You'll have to keep in mind as I relate the tragic story of this game that I'm really not trying to be negative about it. We ran into many more mistakes than successes in the class that this project was for and I'm just being honest about them. I should know as I was responsible for my fair share of them.
The original plan was not to make it a 3D tower-defense game with an avatar but to make it feel like Home Alone but with pirates. The player would have at his disposal a host of steampunk-flavored traps as well as a "groin kick" which couldn't kill enemies but had the ability to stun them briefly, rendering the player able to make a quick getaway. Players were also was supposed to have a slingshot that could be used to draw enemies' attention away from the path and to themselves. By misleading the pirates from the path players could keep them busy, lure them into traps, ease up the flow of enemies moving past traps directly on the paths to the box, and buy themselves time. Unfortunately both the groin kick and the slingshot got axed when it turned out the programmer wouldn't have time to make them work on account of his capstone class, leaving the mere act of approaching the pirates as the only means of distracting them and no means for the player to defend himself but to run away. This wasn't the biggest loss in the world but it deprived us of both a means for players to act aggressively and a means for them to get themselves out of minor slip-ups or trouble and ended up turning the avatar into a device that just constrained the number of emplacements players could realistically operate and added a second lose condition. The emplacement constraint is intentional, a departure from the traditional tower-defense tradition of omnipresence but limited resources, but the second lose condition becomes a much greater burden on players without the other actions players should've had.
I'd really envisioned this as being the sort of game where you start at a tree house at the center of the island and use a telescope to spot the incoming pirates and plan what traps you're going to set on which paths. There were supposed to be six possible paths total, but the island that our level designer made--in spite of the hand-drawn map he'd made indicating a huge scale--turned out extremely small and he had no interest in making it larger. Unfortunately the pirates' behavior was designed with a large island in mind and in order for them to perform plausibly they need about two to four times more space so that they can spread out. What's worse the player has to flee the pirates in order to avoid getting killed, but more often than not the limited size of the island forces players to run headlong into a different group of pirates; there just isn't anything to run to.
Meanwhile since the AI had to be able to get anywhere that the player could go and we didn't have the time to make it able to move around obstacles the gradation of slopes of land has absolutely no effect on either your mobility or that of the pirates--which it was supposed to be able to so that players could act strategically and use the landscape to his advantage, climbing to places the pirates couldn't go intentionally in order to either activate traps or just take a breather and plan things out a little in their heads. These faults I honestly don't blame anyone for. I knew if anything was going to be cut back from my vision it was going to end up being the AI and that other casualties would follow. As it is I'm really happy that it can find its way back to the original path if it loses the player.
The traps themselves suffer from a number of implementation problems. They all work but the man-eating plant comes out head-and-shoulders above the rest because it's the only one that was implemented the way it was supposed to be. The idea behind the traps was to have a nature-themed set and a machine-themed set and each would have an automatic trap that would continuously function and a manual trap that would require the player's direct activation after it was set up. The manual traps would be much more destructive but expend themselves as they were activated, forcing the player to use careful timing and coordination. As we're all well aware by now, though, we didn't have enough time to implement a lot of things within the four-week span of this project, let alone something this complex.
The last thing I want to address is the models, which I had a hand in. In an attempt to learn a new skill as long as someone else was taking the project management hat I decided to try Softimage XSI, which I fell in love with within my first few hours of using. The rigging and weight painting setup was what attracted me especially. If it worked it meant I'd be able to save a lot of time by transferring the pirate's skeleton to the hero with GATOR. Unfortunately XSI wasn't compatible with Unity. As it turned out the fancy IK chains and controls didn't translate well into FBX format. Either something was wrong with Crosswalk or something was wrong with Unity's importer. Determined to figure out what was wrong and not wanting to waste some very fluid animations I'd made for both the hero and the small pirate I proceeded to waste a whole lot of time, fooling myself into thinking that there couldn't POSSIBLY be anything wrong with XSI and that there HAD to be a way to make this work. I eventually was forced to admit defeat and re-rig everything in Maya. Happily my other models turned out a lot better than these two since I did those completely in Maya, but I think the last-minute rush becomes very clear when you look at either of them. The sad part is that they both got modeled within the very first two or three days of the project. At any rate, inasmuch as trying to learn a new software package was a noble goal it was also a stupid decision as it rendered both myself and Dave Diggs, the other modeler on this project, unable to exchange assets after the rigging phase--which came back to bite us when the texturer wanted new UVs, I was too busy messing with my rigs, and Dave couldn't take over UVing my models for me when he ran out of stuff to do. Boy oh boy, I am never, ever using a different software package from everybody else on a team ever again.
Communication isn't key, coordination is. We communicated like crazy, with various group meetings and Skype conferences to check up on everyone's progress. But we didn't really plan anything past the high concept and there were a lot of miscommunications about things like the scale of the island and the effects of the traps that should have been clarified in a more hardbound design document. We had someone keeping track of everyone's progress but nobody ever really enforced anything when we started getting behind. Frankly, someone should have been yelling at me when my UVs were more than a week late, but they just went, "okay," took a note of it, and basically put it in a drawer. Meanwhile our class's biggest weakness by far has always been developing a good pipeline for art assets. Since Unity makes it incredibly easy to pull them in there is no room for doubt that the faults were on our end, and I think I've made it clear why between this and my other project, O2. Otherwise Pirates Attack! suffered from all of the usual problems that previous projects did: lack of time, overextended team members trying to work on multiple projects simultaneously, lack of team structure since we'd all essentially been randomly assigned together with no regard for our skill sets, backgrounds, or common interests, lack of ability to coordinate since all our schedules and majors were wildly different, lack of leadership as no one could say with total confidence that they felt like a leader when we were making projects like this one, and, worst of all, lack of access to the actual engine.
Apart from obvious caveats that I should've known better than to ignore I learned from this project what to axe versus what not to axe. If you need to sacrifice two turrets for basic functionality that you know the game needs in order to be balanced, like the groin kick in this situation, by God sacrifice those turrets! You need to think about things like that from the perspective of what you have to gain from losing them. Losing a couple of turrets just means less balancing problems between them, for instance. That's the kind of question I just didn't think to raise prior to this project.