Taken from the Internet Archive
Introducing Croc, an all new character in an original 3-D, free roaming adventure game with graphics and animation that should be seen to be believed. Developed by Argonaut Software for Fox Interactive, Croc will be available this fall for the Sony PlayStation, Sega Saturn, and PC CD-ROM. To give VGS users a chance to learn about the evolution of Croc, game designer Nic Cusworth will be providing a diary on the progression of the game and its development.
For even more info on Croc, check out http://www.foxinteractive.com.
Nic Cusworth discusses the early origins of Croc the game and what went into the first six months of game development.
The first idea for Croc arose in 1994 with an artist/visualizer in our company. The original concept was for a dinosaur platform racing game. In fact, we still have the original animations created to illustrate the game. However, once the team got started on it, they kept adding more and more challenges and platform-like elements. Simultaneously, our R&D; group did some work and said that they could deliver a full 3-D character game at 30 fps, which gave users unprecedented freedom to roam and explore. Finally, we merged these two ideas and put together a team with the mission to create a complete 3-D character game that transports traditional 2-D game elements into a full 3-D environment. The team has been working full-time on Croc since October 1995 which, by the way, was well before Nintendo demoed Mario 64. The strong influences are a sense at Argonaut that there is a lot more that can be done in 3-D. The central concept creating a beautiful, totally free roaming game that added true 3-D to the simple fun of a platform game. Our ambition was not to slap 3-D graphics onto a 2-D game but to give the player a new sense of freedom to move in 3-D. In terms of gameplay, we have been inspired by the long list of excellent 2-D platform games that have preceded it. Argonaut also worked with Shigeru Miyamoto on Starfox, which also gave them a unique perspective on how to make a great game.
Enter the world of Croc
At the time of writing we have eleven days to have a finished version of the Playstation version of Croc to submit to Sony for approval. For this diary I have decided to use a "Virtual Time Machine" to go back and detail an overview of just what it takes to make a quality video game. My VTM looks a little like a computer and has a basic text input system…
Login: Nic Cusworth - Lead Designer on Croc
>Look
You are in a room surrounded by hard-working, dedicated people putting the
finishing touches to Croc. There is a toy Crocodile sitting on your monitor.
>Squeeze crocodile
The room starts to spin... people are moving at great speed but backwards. Time
passes and the room stops spinning. You are in the room, but sat in a different
location and surrounded by even more people, some faces look familiar.
>Time
February 1996
>Quit
OK, so I am back at the beginning of Croc as we know it, but it wasn't always like this. Work started around August 1995. The two lead coders, Tony Lloyd and Lewis Gordon, initiated Croc as a technical demo on the Sega Saturn. Simon Keating was given the assignment of designing a suitable character for a 3-D racing-platform game. After many design refinements, Simon came up with the character of Croc and he hasn't changed much since. I was working on finishing another game at this point but kept coming over and adding my two cents.
An early look at Croc
Time passed and a team was assigned to expand on the technical demos that had been created and build a game. The Saturn 3-D libraries turned out to be evolving rapidly so the lead platform shifted to PlayStation and work began in earnest in late 1995. A large team was assigned to what was obviously going to be an adventurous project. The start-up team included three designers, three coders, two animators, two graphic designers, one previsualizer, one musician, one producer, and so work began on the strange and beautiful process of starting a major project.
A vast amount of groundwork is done in the first few months. This (in our case) was split into three areas: the core design team, previsualizer, and artists all concentrated on the design aspects of the game. This involved producing a substantial document detailing "Things we would like to do." It is interesting to look back on that document because at that stage we really didn't know what technical limits we would encounter. Roughly the design document detailed the following aspects of the game.
Story - Which changed many times
Character and controls - All Croc's moves were detailed with animation direction.
Environments - Ideas for environments were discussed
Enemies and interactive objects - We came up with literally hundreds of enemy ideas
Test plan - We knew at an early stage how important quality assurance would be
Meanwhile I had been in discussion with the coders about the tool set we would require to build the game. For this game we weren't just going to need OK tools… not even good tools… no, we were going to need great tools! You can have the greatest team in the world (and we have) yet without great tools, you complicate the development process and depreciate the skills of the team.
The tool tasks were broken down into three sections: level editor, strategy language, and conversion tools. I will talk more about the first two later, but it is important to stress how much work was put into conversion tools. We had artists using 3D Studio to create models that were then going to be animated in Wavefront, bitmap artwork which had to be squashed onto texture pages, sample data, map data, strategy data, animation files from both Wavefront and 3DS, etc. All of this had to slot into a developing game engine, not to mention all the extra work you have to do to get the game to run from a CD. It's a dirty job and coders have to do it!
The game engine was also being developed in conjunction with all the other work and at the end of our first three months we had a design, a basic tool set, and the start of a great game engine. Enough was done to enable us to produce a basic demo for 1996 E3. This was only shown to potential publishers but even in it's early stages, people were amazed by it.
[Broken image]
Building the world of Croc
The 1996 E3 was important to us as the first wave of 3-D "platform games" were to be shown. We had seen the early shots of Mario 64, Crash, and Nights, although we knew they would be something "different" than what we were doing. Luckily we had taken a different approach to all the titles we had targeted as competition. We had more focused gameplay than Mario, more freedom than Crash, and Nights was just plain amazing, but totally different. With renewed vigour we continued development.
Nic Cusworth talks about the development of Croc from its sixth month…to today, including the game editor, music, and art.
This stage was where the bulk of work was done. Loads of levels were designed; the engine was sped up; animation and enemies added; environments built; and music, sound effects, and ambience dropped in. The groundwork we'd done in the first few months served us well. As designers, we had a set of tools that allowed us to quickly visualize our ideas, tweak enemies, and generally play with the game until it felt good. We set ourselves a goal of a playable game by Christmas, and we made it.
Now's probably the time to discuss those tools I was talking about.
At the start of the project, the coders and I sat down to discuss just how we were going to build our 3-D worlds. We wanted to design a method that was flexible, yet expressive enough to have few limits. We expanded on the ideas developed for 2-D platform games. In a game like Super Mario World, artists create tiles (small 16 x 16 pixel graphics) that make up the landscape. 2-D level editors work a little like a jigsaw. A designer fits lots of little images (tiles) on a flat plane to produce a complete level. So if a 2-D platform game level is a picture, Croc's 3-D game levels are more akin to sculpture.
We took the idea of a grid-based system in the same way 2-D editors work, but instead of using a flat surface we extruded it into a cube, and instead of using 2-D tiles we created 3-D tiles designed in 3D Studio.
Let's have a look at how we build a Croc level.
Step 1: Pick a style. We have a choice of styles that we use in Croc, ranging from ice to dungeons. For this demo, we'll use the forest style. As you can see, Croc is standing alone on a single flat 3-D tile. Still, all levels have to begin somewhere, and ours starts here!
[Broken image]
Step 2: Choosing a style gives you access to loads of 3-D tiles. I'll start by adding a rocky border in our level. As you can see, it's still far from being a full game level. The black gap between Croc and the border contains no 3-D tiles.
[Broken image]
Step 3: Let's choose some interesting 3-D tiles to fill the void. Here you can see we've chosen to drop a small lava lake with a bridge across it. We have also added a rock and a few mushrooms, but it's still not complete.
[Broken image]
Step 4: Let's set a background, add some music, assign an ambient, and all the other polish. Here we have a nice, sunny background. We could alter the feel of this level dramatically by adding a more sinister background. We could add lighting and some strategies, but that's as far as this little demo will take us.
The main power of all our tools is the integration with the PlayStation development system. One the game is loaded, you never have to re-download or recompile anything. Simply hit a button to save the map, press start on the PlayStation controller, and within seconds your changes appear. This level of flexibility has allowed us to tweak the game to the nth degree with ease. The editor may not be a looker, but it's got it where it counts!
Argonaut is a great believer in strategy languages and, as a designer with some coding skills, so am I! So, what's a strategy language? Put simply, it's a custom language for the modification of objects in a real-time environment (simple huh?). Why not use C or whatever language the game is being developed in? Ah, well, there's a lot more flexibility to be found in a language designed specifically with your game in mind. Early strategy languages at Argonaut were more similar to Assembler language than a nice, readable, high level language; so we decided to change that.
The coders and I sat down again and thrashed out ideas about how it should work. We decided to use a syntax similar to BASIC since most people who have approached a computer are familiar with it.
The cool thing about the strategy language and all the other tools is you don't have to re-download the game. It has its own compiler that lets us independently make strategies, and once they are made, we simply hit a button on the PlayStation and the changes are there. It's also important to note that this system works on all three platforms we are developing Croc on, not just the PlayStation. The Saturn and PC teams instantly get changes to levels, graphics, and strategies all at the same time!
Everything in the Croc world that moves is a strategy, from the triggering sound when you walk up to a waterfall to Croc himself. The language itself is, effectively, a state machine driven by events and animation. This means that a strategy can wait for its state to change and respond to it. If it's required to alter its animation, this is all dealt within the strategy language. A good example is a platform that falls when you stand on it. Without giving too many of our secrets away, this is what the code would look like.
Strat Falling_Platform
SetModel LoadObject "Platform.mod"
waitevent stoodon_by_player
Fall
Remove
EndStratI don't even need to comment on that. OK, let's expand on that and show how strategies are integrated with the editor. Since all strategies in the world are dropped using the editor, we implemented a way of affecting their behavior from the editor. There are two main ways of affecting a strategy, the most basic being parameters. You can assign eight parameters to a strategy, and since they're just numbers, they can be used for almost any purpose. Let's change the strategy we wrote a little.
Strat Falling_Platform_With_Scale
SetModel LoadObject "Platform.mod"
Scale Param0
waitevent stoodon_by_player
Fall
Remove
EndStratWhen we drop the strategy now we can click on the parameters option and enter a value to scale the falling platform to. That is a very basic use, of course, and like I said, they can be used to affect almost anything. The evil "Dantini Zaps" in the game have two parameters that affect just how evil they are, these being "range from player to attack," and "time between zaps." This allows us to fine tune a "Dantini Zap" to any situation.
I mentioned another method of strategy/editor interaction; it's called waypoints. Each strategy can have a number of waypoints attached. This allows us to vary the movement patterns of everything from platforms to bosses. We could make our fall platform move around following waypoints, but, again, I don't want to give away all our secrets. Oh yeah - waypoints can have parameters as well!
So what is the moral of this story? Tools are very important in the creation of great games. Coders do ask the designers what they want out of tools, and if you deliver, your game will almost certainly be taken up a notch. Oh, and designers, get a bit technical and talk to your coders. It's in your best interest.
We did something very unusual after Christmas. We took a step back and had a critical look at what we had done. Hmmm...it could be better. We made a decision to reduce the team to a core that would polish the game for release. Yep, most people throw people in at a project in its closing stages, and we took people off. Also, about this time, a small test department was installed in the Croc room. These three dedicated men and women helped us by giving feedback and finding those dreaded bugs. It turns out that we almost completely redesigned every section, every level, every monster, every strategy - anything and everything to polish this game up. We were very lucky to have this time. Not many developers get six months of tweak time, but we did and it shows. You are always fighting deadlines in this business and I must take this moment to thank our publishers, Fox Interactive and Media Quest, for having the patience, the commitment, and confidence in the team to let us have this time with few distractions.
I haven't really talked about the art and music side of Croc. Let's start with music. We have three musicians, a music coder, and a sound engineer on the project. That may seem like a lot of people, but the music in Croc is something else. For starters, we have over three hours of original music in the game. That alone is mammoth task, but they still wanted to add more to the audio content of Croc. As well as music in every level, we also have ambients. These are short MIDI tracks that trigger sound effects instead of playing music. For example, in the bright forest section you can hear birds tweeting, in caves you can hear dropping water, and in the castle you can hear the Baron laughing at your progress.
A lot of time was spent tracking down suitable sound effects that people wouldn't have heard before, adding a third layer to the audio experience. And if you have a Dolby setup, all the sound effects and music are in 3-D. If an enemy is chasing you from behind, you'll hear him behind you! It all makes for a great audio treat that adds a lot of atmosphere to the game.
Artwork is split into two different skill sets: animation and model building. We have had a total of three animators working on the game animation using Wavefront on an SGI. They quality of animation in Croc is unparalleled; it is truly magical. Croc himself is what we call a morph object. What this basically means is we use the smoothest method of animation possible to animate our hero. Since the player mainly sees Croc from behind, his tail had to move as smoothly as possible. A morph system takes more memory than the standard animation system used for 95 percent of the other game objects, but if you're going to blow some memory, you may as well do it on the main character.
We were lucky enough to work with top industry animator Pete Day on the story scenes in Croc. If you've seen a copy of Creature Shock, you had to have been impressed with the animation - and most of that was our boy Pete. One thing we decided on at a very early stage was that we wanted no FMV sequences. Instead we wanted to use the game engine to tell the stories. This challenge was taken up by Pete, who was used to creating million-polygon rendered sequences, and he was given a limit of 2,000 polygons per animation frame. The outcome was spectacular. OK, so we haven't got all those SGI effects, but what we do have is a seamless transition from story to game and some fantastic animation. We even built the backgrounds up in the Croc level editor!
[The rest of the article is missing.]