?

Log in

27 July 2007 @ 09:32 pm
(Backdating this, it was mostly written on friday but I didn't quite get around to posting it until today!)

Well, we're now more than halfway through pre-production, which is a damn scary thought.

I spent most of the day in the presentation room, so I didn't get to keep tabs on what everyone else was doing as much as I usually try to. I'd say that it's part of my job of 'creative control' to oversee everything, but the truth is, I'm just curious and kind of in awe of everyone who can draw so well and actually make head or tail of Max/Ageia/C++ (Aporkalypse-style) ^_-

Programming

In the morning, Ben got the Ageia plugin working with Max 9! He created a box and it fell to a ground plane. He also discovered that the Ageia plugin exports physics data in binary form, instead of in PML. This means that we won't have to do the "pre-cook" that was required with Aporkalypse, which is definitely a benefit.

In the afternoon, when I next saw him, Ben had managed to get his basic framework reading in the data exported from Max/Ageia. A cube appeared, and it fell onto a plane! It might not seem like much, but it was very encouraging. I feel like we're actually starting to make some headway into what seemed like an inpenetrable frontier of unfamiliar programs and code. I'm even beginning to think that we might actually get the game to a decent standard by the deadline!

But Ben's away for the next week and a half (off skiing, lucky sod!) so it's up to the rest of us to pick up where he left off next Wednesday.

One issue that cropped up with Ben's experimentation is that of 3D orientation. For some very strange reason, Max seems to use Z as the vertical axis, instead of Y. This is a very odd convention - I don't know of any other program that does it like that. I asked some of the graphics students, and they said Maya doesn't do it, so it can't be just an art program thing. Anyway, it means that we're going to have to turn our brains sideways when we're looking at models, and probably put in some transformation rotations when we load everything, since Novadex and Renderware both use Y as the vertical axis.

Meanwhile, Peter and the NPC team continued work on the AI ruleset (frequently popping up to ask the design team questions on NPC behaviour that would be required).

As they started to think about actually implementing the AI, they hit what will probably be their biggest implementation issue - how to implement pathfinding nodes. The AI will use both pathfinding (navigating paths by travelling from node to node) and steering (avoiding objects in the local vicinity) behaviours, neither of which were used in Aporkalypse, so we're really working from scratch. But the biggest problem of pathfinding is how to set, store and extract the node locations and connections.

We spent a while debating various potential methods. One suggestion was to use the physics engine to store the information. Each node could be created as a physics object, and then nodes could be attached to each other using Ageia's 'joints' method. The physics loading code could be programmed to not load any physics objects with a certain prefix (ie, the pathfinding nodes), and then we could have a different loading module to extract only those particular nodes from the physics model and feed them directly into nodes in the actual code. Daniel was much in favour of this method.

The other method that Shane-the-graphics-lecturer-not-the-programmer suggested was using objects in Max to store and connect the nodes, and have a script that extracts that information and then dumps it in a format that the pathfinding loading code can read. I'm in favour of this method over the other one - it would seem sensible to me to keep each section (ie, AI and physics, which are unrelated) discrete, rather than be intertwined unneccessarily.

I'm still not sure how the objects will be connected together, though - hopefully I can corner Shane next week and get him to give me a crash course on how he plans to do it. Some of the graphics students had some interesting ideas - everything from using 'bones' to connect the node objects, to setting connected nodes in consecutive keyframes of an animation.

Design

Well, the design has really started to come together today. We got level 1 even more fleshed out, and made a solid framework for levels 2 and 3. Now we've got all the sections in each level specified, and the order they occur. There's wiggle room, of course - we may end up discovering we've just tried to put too many things in and have to cull some. But I hope not, because I think we could do some serious justice to these ideas, if we get the time.

We finally resolved our problem with the 'bots on Belfry that are too high for Lobot to deactivate' situation. I can't claim credit, alas - Geoff came up with the idea (it was actually one he suggested ages ago, I didn't think it was usable at the time). He suggested that instead of making him invulnerable, the shield could make Belfry invisible. After mulling over this idea for a bit, we realised it could be workable. It would mean that when enemy robots see and chase/try to attack Belfry, he can flip on his shield pretty quickly and the robots will stop, look around, be unable to work out where he's gone, and will eventually wander away again, back to their normal locations or patrol routes.

We thought about the practicalities and physics of invisibility and decided to change the flavour of the shield slightly - instead of making him actually 'invisible', the shield could be a sense-scrambler that Belfry's been developing. It only works on robotic senses, so has no effect on humans (not that that's an issue with this particular game, since there are no other humans).

We did some more work on the mini-game, too, with Geoff at the helm and the rest of us making suggestions and drawing 'helpful' squiggles on the whiteboard.

And finally, at the close of the second week of pre-production, we had our first progress report to the class. Fortunately (for me, anyway, I'm terrible at public speaking) Paul gave the speech, giving a description of what we'd put together so far for each of the levels. He used our whiteboard notes to demonstrate, which was a bit of a worry - they were kind of all over the place and rather incomplete, since they were scrawled progressively as we tossed ideas back and forth over two days.

The report wasn't as detailed or as long as we had planned, but we simply ran out of time. As Paul said, so far the programming and graphics teams are pretty much on-schedule, but the design team is lagging behind. In our defense I'll say that we're only learning what we're supposed to be doing as we're doing it.

We've been trying to debate the merits of different ideas thoroughly, making sure that everything occurs in an order that works for both the story and for player progression, and so far, I think we're doing a decent job, considering our inexperience. The design team is an interesting group, because, much like the entire programming class, it's made up of very laid-back individuals. This means we don't have full-on flame wars or major meltdowns, but it does mean discussions can sometimes go on for a while.

I think in future I need to try and stay more focussed, and make sure everyone else does too. I need to set out the goals of each session more clearly (eg, "today, we're here to decide [this], and at the end of it, we'll have [this]"), as well.

But on the up side, I think we've done enough of the design that the programmers and artists can start work while we finish it up.

Mostly what's left are the specifics: the exact types of NPCs we're going to have, what the puzzles in each section are and how they work, etc. Puzzles will probably be our focus for the next week - we need suggestions! If you can think of a setup, send it my way and we'll try to work it in somehow =D

Graphics

I didn't hear much in the way of news on the graphics front today. The artists were still working on their designs.

At one stage I caught Paul and Eve standing in front of the wall, picking out bits they liked from various robot designs. One of Simon's designs seems to be the frontrunner for Lobot - a robot with a teardrop-shaped head, and a posture somewhat reminiscent of Dog's (Half Life 2). Simon's robot is legged, but could be modified to use tracks or wheels just as easily.

Next week the designs will have to be narrowed down even further, as the art bible starts to take shape.

And I don't even want to think about the technical design document >.<

So that's it for another week - stay tuned for more Lobot-which-still-needs-a-new-name next Thursday!

And finally, a shout-out to the ever-awesome TN - thanks for your continuing interest in the project and all your encouragement =D
 
 
01 August 2007 @ 08:01 pm
Woooooo GOOOOO TEAM!!!!!!!!!!!!
 
 
26 July 2007 @ 10:13 pm
Today was a day of semi-organised chaos. It was Open Day at the AIE, and that meant people wandering in and out of the lab all day, harried lecturers running about, and admin staff extolling our virtues as we sat and attempted to look like we actually knew what we were doing. I'm not sure if we actually managed to fool them ^_-

First thing in the morning, we got bad news - apparently there is already a student-made game called "Lobot". I looked it up on youtube and there's a trailer for it. It seems to be a pretty standard platformer where you play a cat that shreds things. What that has to do with the name 'Lobot' is anyone's guess. But it does mean that we're going to need a new name! Suggestions are welcome, because I have no clues ^_^;

Programming

Today Ben continued work on his test framework. He managed to get the Aporkalypse world model loading, and then set it up so that he could create and drop cubes into the world while the program was running, and watch them bounce around. Actually seeing progress was very cool. It felt like we finally broke through the 'we have no idea how to even start this' barrier.

Meanwhile, Wayne got the wireframe of the physics world model appearing, so you could actually walk around and see how close it was to the graphical model.

Peter started work on the NPC AI, creating a skeleton rule system for the behaviour of different kinds of bots.

Shane spent the day wading through the animation loading and pipelining code in Aporkalypse. He came to much the same conclusion I did - it's messy, ugly, great chunks of it are from earlier experiments and are now redundant, and it would probably be easier to re-write the entire thing from scratch than try and clean it up. Daniel, however, disagrees, pointing out that at the very least, it does appear to work relatively reliably (it's just a shame the same can't be said for the rest of the Aporkalypse code). We're still undecided, but Shane will probably have the final say, since he and I are the ones that will be working on the Lobot code, and he's the more experienced programmer of the two of us.

On the other hand, the ongoing NovadeX/Ageia PhysX/no physics engine debate was finally decided. We're going with Ageia PhysX, since we managed to find a plugin for it that says it works with Max 9. That'll at least remove one step of the tangled, time-consuming exporting process. I guess we'll deal with the 'need to install program before the game can run' issue as it comes up.

Ben installed Ageia on his computer, and then went through all of the demos, to see what kind of upgrades the engine had had since it's NovadeX days.

There was an awesome stretchy frog that you could pick up by various bodyparts and throw around, which demonstrated some seriously nice deformable soft-body physics. There was also a cloth demo, which was really, really realistic. It was apparently created by joining huge numbers of very tiny particles together with springs. Probably too computationally-expensive for us to use in our game, but a very interesting demo of what can be done with the engine.

Ageia also seems to have some kind of in-built sensing/reaction scripting. One of the demos had cubes in it that had a sensor just in front of them, so that if they were moving forwards and about to crash into something, they'd turn to the left to avoid it. It was pretty simple, as far as scripting goes, but qutie effective.

We probably won't be using that particular feature, though. We need to keep all of the AI-related stuff in the actual AI code section, rather than scattered throughout the physics middleware ^_^;

Anyway, despite getting Ageia working on its own, Ben couldn't get the plugin working with Max 9 at all. After some investigation, his best guess was that the plugin was for an earlier version of Max, and that we'd have to try and look for a newer one tomorrow.

To add to the software frustrations, Shane-the-graphics-lecturer-not-the-programmer couldn't get Renderware working on the dedicated Max 8 machine, either.

Hopefully tomorrow will have fewer technical glitches.

Game Design

Geoff and I spent most of the day with the design team. In his morning speech, Paul informed the class that tomorrow the design team would be giving a presentation and walkthrough of the entire game in front of everyone. This was news to us, and rather stress-inducing.

But, despite still not having an exact idea of what we were supposed to be producing, we soldiered on. We started creating timelines for each level, showing the order of locations within the level, the goals for each subsection, the skills that the player would aquire there, and the type of puzzles that would appear in the subsection. We got the first level done and started working on the second level.

As we were working things out, we got into a discussion about whether we should have a 'levelling' system, and if so, how it should work. Levels are useful in one way, as they can give the user something to aim for, as well as helping them feel like they're actually achieving something and progressing. We tossed around the idea of NPC robots having levels, and Lobot being unable to deactivate anything of a higher level than he was.

The problem with that idea was the question of what to do if Belfry is set upon by a robot too high for Lobot to deactivate? Neither Belfry nor Lobot have any way of getting rid of it, which means the situation results in deadlock. Belfry can't move with the shield on, but he can't turn the shield off, or he dies. Guess that's another thing to try and iron out tomorrow.

Graphics

We did some more experimenting this morning, trying to get multi-texturing to work with Max 8, but with no success. This may have been because it was mostly Paul and the programming students trying it, with advice from some of the graphics students floating nearby. It's quite possible someone more experienced than us at Max (ie, Eve) would have more luck, but she was so busy with Open Day happenings that we didn't manage to grab her all day. Guess we'll try again tomorrow.

Today the artists have been refining their designs, and drawing even more detailed pictures. A couple of new Belfry designs went up that I liked, complete with crazy hair. Still no final decision on Belfry or Lobot, though. I guess we're still only halfway through preproduction, though, so that's not entirely unexpected.

So, that was it for today. More tomorrow!
 
 
24 July 2007 @ 11:25 pm
This one goes under "Useful Documents for Programmers": Aporkalypse Call Tree.

It's on the SVN, but I'm trying to keep a collection of all Lobot documents linked from the one place, as well.

Thanks to Shane and Ben for putting it together!
 
 
24 July 2007 @ 11:09 pm
Time to start breaking areas down into rooms and objects! I'm going to compile a list for each area, and add to it whenever people send me suggestions (feel free to comment on this post, email me, or speak to me in person). Level designers can then pick and choose elements to build their areas and puzzles out of.

Thanks to Terry for starting this list off!

Lower Level - 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.

Sections/Places/Rooms

Security/Guard Room
Battery Charging Room
Power Plant
Generator
Repair Area
Shanty Town
Waste Area
Recycle Depo
Discard Centre
Lab
Storage Area

Features

Security Booth
Checkpoints
Maintenance Beds
Production Line
Conveyor Belts
Machine Press
Soldering Booths
Racks of Robots
Cranes
 
 
 
20 July 2007 @ 11:08 pm
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.

Graphics

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.

Code

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!

~MJ
 
 
Current Mood: optimisticoptimistic
 
 
15 June 2007 @ 01:15 pm
For everyone who hasn't visited the LJ before - welcome! I figured that since Lobot is going to be the game we'll be working on for the next semester, I should dust off the LJ and get it updated regularly so we can keep track of how it's all going.

Everyone at AIE is free to join this community and post anything related to Lobot in particular or making games in general =)

I know we're not formally starting work on the game for another couple of weeks, but we might as well continue tossing around ideas and re-working bits and polishing others in the meantime.

If anyone has questions, this is a good place to ask them! I'm also happy to be asked stuff over email (michelle.hughes@students.aie.edu.au), or in person (if the graphics students are willing to brave the programming lab ; )

For info on how to join LJ and post in this community, check out the first post.
Tags: ,
 
 
14 June 2007 @ 04:51 pm
Congratulations lobot_dev_team! You guys rock! ^_^
 
 
Current Mood: excitedexcited
 
 
07 June 2007 @ 09:01 pm
The tutorial section will introduce actions and ideas needed for the game via advice from Belfry and by using hints.

Introducing Lobot's limbs:
In the first room, Lobot will be introduced to his extending his legs and arms by being asked to get a key card from on top of some rubble.

Introducing sneaking:
After leaving the starting room, Belfry tells Lobot that he can disable other robots by sending a deactivating program to their CPU. He says it will be easier to do this if Lobot can catch a robot unawares. The first robot encountered will be “sleeping” facing the opposite direction, blocking a doorway. This will be a sign that the player must deactivate and move the robot out of the way.

Introducing the mini-game:
The first deactivation mini-game will include a tutorial where Belfry will explain each of the elements of the mini-game. The switches, the code, the wires, the CPU, the bonus gates and various obstacles.

Introducing distraction:
The next room will have an armed robot blocking a pass between the wall and some shelves. Tech will tell Lobot that the robot reacts to sound. He says that dropping a noisy item behind the robot will distract it. A box full of nuts and bolts will be sitting on a bare desk. The player should realise that Lobot can extend his limbs and drop the box behind the robot. If the player is stuck, Tech will begin to give hints: “Come on Lobot, stretch your imagination!”.

The nuts and bolts will be kept as an item to use for distractions.

Introducing active enemies:
The following corridor will have two robots, a closer one “asleep” and a further one looking down the corridor from the other end. When the player deactivates the robot, the further one will recognise Lobot's hostility and attempt to attack him. Returning to the previous room will stop the robot from attacking.

The next section will have a sequence of robots, each looking in the direction of another robot. The player will know to look for the one robot that is at the start of the spotting chain. Then the player can easily deactivate the robots, without having any become aggressive.

The game will gradually introduce more and more complex puzzles that incorporate some new elements, but mostly using a combination of skills already acquired.


******************
I was having this idea how Tech is agitated and almost talking to himself at the start of the game, but by the end accepts Lobot as a partner :P Just something that popped up when I was trying to write dialogue...

“Wait... this robot could be me! It would just walk up to them!”
*beep* I could?
“Of course a robot couldn't be me. Only I could write this program! I could and I did, but a robot couldn't and wouldn't!”
*beep* I wouldn't?
“But you can and will use this program. It disables robots! ”
 
 
07 June 2007 @ 11:10 am

hey guys this is just a lil model i cam up with from the concept arts feel free to comment.

http://au.geocities.com/o422248787/lobot_concept_1.jpg