Log in

No account? Create an account
20 July 2007 @ 11:08 pm
WEEK 1 - Pre-production  
I'm going to be keeping a log of Lobot's progress. Everyone else is welcome to post progress reports, information, anecdotes, and anything else Lobot-related here in the lobot_dev_team LJ as well. My posts will obviously have a slant towards code and game design, since they're the areas I'm working on, so it would be awesome if some graphics students could post about how they're going, too =D

Last semester, we spent a couple of design classes brainstorming ideas and getting a bit of a feel for the Lobot game, and on the very last day one wall of the graphics lab was stripped of posters, and concept art started to go up.

But this week, work on 'Lobot' began in earnest.


The graphics students split into two major groups - characters and environment. The character group was then further split into teams working on Belfry, Lobot, or assorted robot NPCs. The environment group was also divided into three, each starting to flesh out design elements for each of the three physical levels of the game.

Throughout Thursday and Friday, more and more pages ripped from sketchbooks were stuck to the wall. Designs for robots came thick and fast. Some of them were simple and cartoony, others were really intricate and detailed. A number of them were quirky and amusing, which is good - part of the game's charm will be its humour (if we manage to pull it off, anyway!)

The Belfry designs were slower to go up, but when they came, they were really varied. Some made him old, some young, but most of them captured the eccentricity that I was looking for in one way or another (the hair, the hair!) His clothing ranged from overalls, to labcoats, to business attire, to space-suit-like outfits.

People keep asking me what age Belfry should be, and the answer is - he could work at pretty much any age, as long as he has the right personality. I originally had a picture of him as an older, 'mad professor' type in my head (hence the name), with the labcoat and crazy Einstein hair. But one of the guys who drew me some concept art for the pitch drew him as a young guy with the overalls and spanner, and I suddenly had a vision of him as someone like Max, from Dark Chronicle, running around with his spanner. I like both versions, and think it would be really cool if we could take elements from both and somehow merge them. But I don't have an exact mental picture of him, which I think is a good thing - it means the artists can simply go sick and draw stuff until they get something that really works. I'm so loving having other people come up with cool stuff that I never would have thought of =D

On Friday, Eve asked the artists to work on designs (especially for Lobot) even more broadly, well outside the box defined by the original pitch. The designs for Lobot had mostly focussed on robots with tracks up until that point (since in the pitch, Lobot's inability to climb stairs is actually a puzzle element), but nobody had really nailed his look yet, so Eve wanted even more varied ideas to choose from. I think in the end, Lobot will be a bit of a mix-and-match character, with elements from a number of designs.

His face is particularly important, since it needs to convey his attitudes and emotions, but his body design will also be important. Lobot uses body language to communicate, and how he is able to move will define many of the game mechanics. His method of mobility will be a large part of that, especially when we get further into puzzle design.

We ended up with a large number of ideas for mobility. Different numbers of wheels (I saw designs with four, three, two and one), different numbers and configurations of legs, tracks, hover units, even a robot that hooks itself onto a moving conveyor attached to the roof. Today produced some weird and whacky stuff! Hopefully even more designs will go up next Wednesday and Thursday, and then we can start picking out the elements we're definitely going to use and refining them. Fortunately, the designs that don't end up being used for Lobot can be salvaged and used for NPCs.

One of the problems we had on Thursday was with level design. The game setting/environment was almost completely changed, but it had happened after the detailed pitch had been completed, and had only been transmitted orally. Without documentation, we didn't really have a reference to work from, so there was some amount of confusion happening.

Essentially, the factory setting was expanded into an enclosed colony. The lower level will contain many of the elements of the original factory, with areas for maintanence, robot assembly and repairs, the foundry, etc. The area should be grungy, grubby and noisy. A lot of things are only half-finished, or are broken beyond repair. This is the level that the robot shanty town is located in.

The middle level is more residential. This is where, until very recently, humans lived and bustled about. It's fairly cramped, with space being very valuable. There may be some food stalls, laundromats, etc. Things on this level are designed for practicality, rather than aesthetic. Think Corbin Dallas' living space in Fifth Element.

The upper level is business and recreation. It's much quieter than the previous levels, more spacious and somewhat serene. The colours should be lighter and more airy. There might be parks and trees on this level. There may also be a mall, which is much cleaner and brighter than the small stalls on the previous level.

I'm going to write a revised environment section (based on the paragraphs above) to replace the one in the detailed pitch, so when I have it finished and approved, I'll email it out and post it here as well.

But the environments on the wall are really looking good so far, with most of them focussing on the lower level. Environments are one thing I find particularly difficult to draw, so I'm in awe of people who can make places come to life simply with black lines on a white page.


On Thursday, the programmers officially moved into the graphics lab. The first challenge of the day was actually getting something to compile, which we discovered was impossible, as the computers in the graphics lab hadn't been set up for programmers yet. So, we ended up moving back to our lab for most of the afternoon, disrupting the poor art students who had ensconsed themselves in there thinking it would be a nice quiet place to work - sorry guys!

The programming students were split into three teams - one each for PC (ie, Lobot), NPCs, and environment. I got in first and claimed a PC slot, and the eventual line-up ended up being: Shane and I on Lobot, Peter and Daniel on NPCs, and Ben, Shane and Wayne on environment.

We started out with some confusion over what each of the three groups was actually supposed to be doing for the week. We eventually muddled it out (with a little direction from Paul). Both the PC and NPC teams need to work on figuring out how to load models and animations, and trigger changes in animation. The PC group also needs to work out how to hook user input up to the model, and work on the camera. The NPC group needs to work on AI, pathfinding, etc. The environment team needs to work out how to load the environment, load models, build the collision models, implement physics, do lighting, and make objects that can be interacted with.

Having already decided that we were going to re-use parts of the Aporkalypse code to give us a bit of a head start with creating our code base, we began work by trying to wade through it and figure out how everything was connected, and where the thread of execution goes (not so easy when you can't actually run the code and set breakpoints everywhere). We quickly abandoned the idea of building a class heirarchy diagram - there were simply too many classes and they were interconnected in all sorts of ugly ways.

So Ben and Shane sat down and went through the code line by line, and built up an awesome thread of execution diagram which will save the rest of us a lot of time when we try and figure out when and where things are actually loaded and updated in the main game loop.

We also discovered the difference between 'Pig Cooker' and 'Pig Slayer', the two separate programs that comprise Aporkalypse. Pig Cooker is simply a program that converts PML files to NovadeX files - basically, it loads the physics world model from text files. Pig Slayer is the actual game itself. It was separated out because Pig Cooker is so slow to compile and run, and it would suck to have to run it every time you wanted to run the game. So they wrote it so it only had to be run once per machine, and once the assets were created, Pig Slayer could simply load them whenever it ran.

On Friday, we finally got the Aporkalypse code compiling. Shane and Peter even got it running (it wouldn't run on my machine, just crashed during loading, taking the entire PC with it), and started to experiment with changing values. Shane got the debug settings turned back on, so we could see the models running around with wireframes of their collision models over the top of them. We discovered that the collision models for the PCs only went up to their knees - we have no idea why. But it does explain why players can walk straight through rails at waist-height.

Peter tweaked the values for gravity - for some reason the gravity was set to -20, instead of -10, and downwards movement was increased by adding a force vector on top of gravity, again, we have no idea why. Our best guess is that they simply set the mass of the player models too low and were trying to compensate for it. After poking through the code, there are a number of things we'd like to ask the Aporkalypse programmers, but unfortunately, they left behind no documentation whatsoever, so we're pretty much working from scratch ^_^; Anyway, we had fun tweaking things - Peter actually set gravity so low that he could jump out of the environment entirely and wander around outside of it.

One of the major problems with the Aporkalypse code (apart from being virtually undocumented) is that the networking code is so integral to how the game works. It's threaded through everything - player creation, input/output, etc. It's going to be quite difficult to extract without totally mangling the code, which gives us even more of an incentive to start with our own simple codebase and just take the pieces of Aporkalypse we need.

One of the first major problems we hit was the poblem of software incompatibility. In Aporkalypse, they used Max 7, with two add-on exporters: one to export the models and animations in a format that could be read by Renderware, and a different one to export to the collision model used by the physics engine, NovadeX. The collision model was exported in PML format (which we discovered actually stood for "Physical Markup Language" not "Pig Markup Language", as we had surmised ; ), a format based on XML.

The problem is, this year we're using Max 9, while the Renderware exporter only works with Max 8, and the NovodeX exporter is for Max 7. That means major headaches for both programmers and artists. The original plan was to have a dedicated machine that converted models from Max 9 down to Max 8, and then exported them for Renderware. It's possible that the NovadeX exporter will work with Max 8, but even then, it would mean that when the art students are building the physics model, they can't test the physics in Max - they'd have to export, load the game, and then test their stuff in-game, every time they wanted to tweak anything.

The problem is that neither NovodeX nor Renderware are being supported or developed any more - Renderware has been completely abandoned, and Ageia (who made NovodeX) have replaced NovodeX with a new physics engine called PhysX.

So one option is to use Ageia PhysX, which we can hopefully get working with Max 9. Last year's project, Snak Vac, used Ageia PhysX. The problem with Ageia is that it needs to be installed before the game will run. NovodeX, on the other hand, doesn't require an install and will run on anything. The problem with requiring an install is that it makes it more difficult to take the game places and show people, since you'd need permission to install stuff on whatever machine you wanted to demonstrate it on.

The other option is not to use a physics engine at all. Renderware does have the ability to work out collisions using a world collision model. We can do simple physics simulation in code, and as long as none of the puzzles require any real physics (like tossing something to an exact location) we should be ok. The fact that the PC can't jump is one advantage of our particular game design.

So the physics engine is still undecided, and we still haven't got the Max 8/9 converter set up. Hopefully we'll get them nailed down in the next week or two, though. Personally, I'd like to use a physics engine of some kind, but it really depends how much hassle getting one working with Max will be.

In the afternoon, we had an impromptu technical design meeting. We realised that we couldn't even start designing the code structure until we had a better idea of what kinds of classes/objects we were going to need, and how they were going to interact. Of course, that's dependent upon the types of puzzles we were going to have, and the environments, which are all in a really nebulous state at the moment (especially since we hadn't even had the first design meeting by that stage).

So we went through the different kinds of objects we might want, and then separated them into different groups, depending on what they needed to do, and how Lobot could interact with them. The technical design is still pretty non-existant as yet, but Ben's already started coding a small platform we can use to experiment with loading models and animations, and hopefully he and Shane will be able to get a rough code skeleton down on paper, and then the rest of us can start filling in the bits we're working on.

Game Design

On Thursday, Paul sent out a mass email asking for people interested in game design (the mechanics of the game, rather than environment) to volunteer. On Friday, the design team was finalised (being me, Geoff, Terry and Brent) and we had our first meeting.

The first order of the day was figuring out exactly what the design group would be doing. We weren't quite sure how our job differed from that of the level design guys. Paul told us that essentially, it's the designers' job to work out the game mechanics, and how they relate to the levels and environment. So the game designers work out how the player is going to interact with the world, and then how to teach them the skills they need, using the game itself.

It won't be just the four of us doing the design, though - we're pretty much just a filter. Everyone else throws ideas at us and we work out how they fit into the game. Next week we're going to go around and start collecting all the ideas that the level design and environment people have come up with, so that should be really interesting.

Terry made a good start of his first day on the job, rocking up to the meeting with two sheets of paper - one containing a list of different rooms/sections of the lower level, and another with a rough floor-plan of how the rooms and sections could fit together. Even if it's not the exact layout we go with (it may be a little too ambitious in terms of the assets and geography that would need to be made for it), it at least gives a nice example to start working from.

I'll put both online tomorrow and link them up from here.

Terry and Geoff also spent some time tossing ideas for the deactivation mini-game back and forth, all of which I really liked. I'm looking forward to getting some example 'screenshots' of the mini-game down on paper, since I have a rough idea of how it will look in my head, but I'm still slightly hazy on specifics.

Since it will be such an integral part of the game, we really need to get it right.

Overall Progress

At the moment, everything seems to be in complete chaos and I'm feeling quite overwhelmed, but Paul assures me that this is completely normal for the first week of pre-production ^_^;

Between now and Wednesday, I'm going to start putting lists and other bits and pieces here in the LJ, and will keep updating them as people send me things via email.

Next report will be posted a week from now!

Current Mood: optimisticoptimistic