?

Log in

07 June 2007 @ 12:00 am
Code Base

Being a game played in third-person, Lobot would be able to utilise the core gaming engine of previous AIE projects such as Aporkalypse or Snak Vac. The main game loop, environment framework, player functionality and input system would likely need only minor adjustments.

Frame Rate

The design of the game means that the frame rate should be able to be kept consistently high.

The game is set inside a building, so visual distances will be limited, which keeps the LOD requirements to a minimum. The number of enemies onscreen at any given time is also very low, with it being rare for more than a couple to appear at once.

The game is single-player, so networking isn't an issue. The majority of the processing required for each frame will be graphics, physics, and AI.

Physics

Some simple animations will be done procedurally – for example, objects falling under gravity, particle effects like explosions and smoke, etc.  

The physics engine will also need to deal with collision detection and resolution.


Graphics

The environment itself would have to be replaced entirely, as the setting is completely different from both of the previous years' games. Because the game is set inside a building, the assets required will generally be smaller-scale than those required for a large, outdoor space, although they will probably need to be more detailed. Fortunately, because the setting is a factory, a lot of assets will be able to be cloned or simply re-skinned – repetition and re-use of mechanical parts and units is expected.

Lobot, Belfry and the other robots will need to be completely new models.

Combat and AI

The combat mini-game would have to be coded from scratch. Code would need to be written to generate random configurations for each board with varying levels of difficulty, which may become quite complex. This is especially the case because the opposing player, ie, the robot Lobot is trying to deactivate, will be actively working against the player as they play. AI for other robots will also need to be written.

The most complicated AI required will be for Belfry. While it's fairly simple to have Belfry follow Lobot's explicit commands, Belfry will also need to take the initiative and act independently in certain scenes/locations, without causing himself potential danger, or the player undue annoyance. The steering required for Belfry to follow Lobot around will also be more complicated than general 'wandering', due to the hazardous environment and potential to get 'jammed'.

Camera

The camera setup from the previous games could probably be re-used, but the code will need to be expanded if it doesn't already include player control.

Saving

Because Lobot has a fairly linear sequence of goals, rather than being a free-for-all like Snak Vak or Aporkalypse, saving will be important. Players can customise and guide Lobot's development by choosing upgrades and collecting items, so it will be very important for Lobot's state to be persistent, which means frequent saving. It is also important for the environment's state to be saved, so that doors that have been unlocked stay unlocked, etc.

Saving will use a combination of two methods: save points, to write information to permanent memory; and checkpoint saves, which are stored in temporary memory. If the game is ended prematurely by Belfry's death, the game state will revert to what it was at the last checkpoint. If the game crashes, the game can be reloaded from the last save point. Checkpoint saves will be automatic, while hard drive saves will be at the player's discretion (but will be encouraged).

Save files will probably be written in a custom format developed for this particular game.

Breakdown of Tasks

The work will be broken into five main groups: code, graphics, level design, story and sound, with the first three groups being the largest. The code, graphics and level design teams will be further split into design and implementation groups. Initially, more people will be involved in design; as time goes on, most people will switch to implementation. A team leader will be chosen for each of the main teams. This is important to ensure consistency in code design, art style, etc. throughout the game.

The code team will be responsible for:

Code design
Extracting usable code from previous projects
Implementing new sections of code
Assembling the sections of code
Testing, bugfixing, and more testing

The graphics team will be responsible for:

Creating concept art
Creating assets
Extracting and modifying assets from previous games
Animations
Testing

The level design team will be responsible for:

Designing the environment
Designing level puzzles
Testing

The story team will be responsible for:

Developing the plot
Dialogue
Direction of any animated scenes
Testing

The sound team will be responsible for:

Recording or collecting sound effects
Recording any spoken dialogue
Testing

As evidenced above, all team members will be involved in testing and bugfinding the game, once it is in a playable state.
 
 
06 June 2007 @ 11:40 pm
Ok, this post and the following contain be the sections of the report that I've written so far. I'm still waiting for the sections that you guys are supposed to be writing :P The sections are still pretty rough, so comments, suggestions, additions, etc, are all welcomed!

Core Gameplay

At its core, Lobot is a puzzle/exploration game, in the vein of Ico or Tomb Raider. But unlike these games, Lobot can't defeat his enemies with real-time combat. Instead, confrontations with other robots are played out through the combat mini-game, in the style of Puzzle Quest. Lobot has two primary objectives: find his way through the robotics factory to the end goal, and protect his human companion while doing so. Like to the two main characters in Ico or Primal, Lobot and his human ward are dependent upon each other, and some puzzles will require their co-operation in order to solve.

Player actions available are:

Moving/exploring
Picking up items
Interacting with items in the environment, eg, pushing buttons/switches
Accessing information panels
Speaking to Belfry
Deactivating other robots using combat mini-game

The player's primary goal is to reach the mainframe control room. To this end, the player must successfully attain a series of sub-goals, in the form of level objectives. In addition, the player may choose other goals for themselves, for example, to explore as much of the map as they can, or to seek out combat with other robots in order to increase Lobot's stats and abilities.

Many of the level goals will be to get to a particular location in order to perform a set task. The player's task is to progress efficiently through these environment puzzles by finding the best possible routes, while minimising the danger to Belfry along the way. This may involve, for example, getting him to a safe location and telling him to stay there while you search for a way forwards, or asking him to press a switch at the top of a flight of stairs which you are unable to ascend.

Control System

The game is designed for a console controller with at least four buttons (not counting the direction pad); in this case a PS2 controller. Lobot's movement is controlled using the left analogue stick, as is standard for a third-person game. Four other buttons also have functions tied to them, being: interact, cancel, information screen, and give orders. The right analogue stick lets the player control the camera.

The player can interact with items or entities in the environment by getting close to them and pressing the 'interact' button. This enables Lobot to activate buttons or switches, pick up small items, push or pull large items, speak to Belfry, initiate combat with other robots, and so on. The interact button also functions as 'select/accept' when there are multiple actions to choose from.

The second button accesses Lobot's two information screens – the status screen and the map (pressing this button toggles between the two options). The status screen shows his current state and stats, as well as items in his inventory. The map screen shows the areas that Lobot has already explored. The map begins dark, but is uncovered as Lobot explores. Once Lobot has been to a particular location, it will always be shown on the map.

Finally, the cancel button cancels the current action, or closes the map/status screen.

Interaction with Belfry

Lobot can speak to Tech Belfry by moving close to him and pressing the 'interact' button. When spoken to, Belfry may give reminders of Lobot's current goal, suggest advice, or occasionally just ramble. If Lobot is physically damaged, Belfry will repair him.

Lobot can also use his 'order' button to give Belfry specific orders. Basic orders include 'stay', 'follow me', and 'come here'. Orders can be given from a distance, as long as Belfry is within sight.

In some situations, Belfry will attempt to act independently. Sometimes he will give Lobot a say in these sorts of decisions. For example, he may say “Shall I activate the switch now?” and the player will be able to choose 'Yes' or 'No'.

Interaction with other robots

If Lobot is alone and not behaving suspiciously, most other robots will ignore him. Because of this, it is relatively easy for Lobot to sneak up on them and attempt to deactivate them.

Other robots will become suspicious in four different circumstances: Lobot tries to deactivate them, fails, and chooses not to retry; they see Lobot deactivate another robot; they see Lobot assisting Belfry, or they are told to go into 'alert' mode by another robot. This last method is only used by guard robots.

Robots will perform different actions when in 'alert' mode, depending on their type. Small robots may run away. Larger robots, especially guard robots, may attack or try to shoot Lobot. Robots without any means of doing damage might grace Lobot's audio receptors with a few choice bleeps. Whatever the reaction, Lobot cannot attempt to deactivate a robot that is in alert mode.

Most robots will calm down and return to normal mode when Lobot has been out of sight for a short period. Some robots, however, chase Lobot, which means he must keep running until he loses them, or manages to hide somewhere.
 
 
01 June 2007 @ 01:07 pm
Ok, this is the combat plan that was worked out yesterday during design class.

Lobot can't deactivate other robots when they're in 'alert/aggressive' mode. Basically all robots start in passive mode, and Lobot needs to get into physical contact range without setting them off in order to initiate the 'deactivate' mini-game. This can be done by sneaking up behind them, distracting them in some way, using a legitimate-sounding excuse to get in range, etc.

Lobot himself has no weapons. Many of the other bots will also be unarmed, since they're loading/maintenance/assembly robots as well and have no need of weapons for their usual tasks. Some robots, for example those who act as guards, will be armed. Robots who are armed will be able to shoot at and damage Lobot.

Physical damage will be a hinderance to Lobot - a damaged wheel/track might make him list to the left when steering, a damaged joint in an arm may spit a shower of sparks, making it difficult to sneak up on other robots, etc.

When robots go into alert/aggressive mode, the ones with ranged weapons will try to shoot Lobot. Robots without ranged weapons will chase Lobot. Some robots will stop chasing as soon as Lobot is out of sight. Other, more determined robots, will continue to chase him until Lobot manages to shake them, for example, by hiding amongst other 'deactivated' robots in a storage room.

So that was the plan. But I was going over it last night, and realised there's a major problem with it. If other unarmed robots chase Lobot when aggravated, but Lobot can't enter combat with an aggravated robot - what are they going to do when they actually catch him? ^_^;

So, I modified combat a little. Lobot can enter combat with aggravated robots, but if they initiate combat, then Lobot is at some kind of disadvantage in the mini-game. Thus, it is to his advantage to do the sneaky-sneaky thing and be the one to initiate combat, but he doesn't have to.

And that brings me to the combat mini-game, but I'll post about that after lunch =D
Tags: ,
 
 
30 May 2007 @ 07:48 pm
I grabbed Geoff, Scott and Brad this afternoon and we hashed out a few ideas.  Of course, now I can't remember half of them, but hopefully you guys will remember the stuff in each of your areas and remind me tomorrow  ^_^;

Bits and pieces!

Level design rough breakdown:

Start area - the "lower levels".  Belfry's repair lab.  Lots of crazy inventions and tech bits and pieces and robot parts lying around.  There would probably also be storage rooms and that kind of thing on this level.  This will be the learning/training area.

Middle area - the factory.  Conveyor belts, robot assembly lines.  Robots will be wandering around this level.  The main puzzle area.  This section can be expanded and broken down into multiple levels/goals

End area - the higher levels are less machine-y and more electronic-y.  This is where the humans that run the factory work, and where the mainframe (the game goal) is kept.

Movement:

Walking, turning, etc.  No jumping, but Lobot might be able to extend parts of his body, in order to see or interact with things higher up.

Level puzzles:

Some sections can only be passed through by either Lobot or Belfry.  Lobot can't walk up stairs.  He might have problems with magnetic fields that Belfry can pass through harmlessly.  Conversely, Belfry can't go through areas with high levels of heat or radiation. 

Intro sequence:

The game could start with Lobot being fixed (or possibly assembled from scratch) by Belfry.  Belfry, being absent-minded, failed to turn up to the morning meeting yesterday, which is why he wasn't rounded up and herded out by the virused robots with all the other humans.  Lobot didn't hook into the network because he was waiting to be fixed.  So the beginning sequence could be Belfry testing Lobot, after repairing him, by giving him specific instructions, which will get the player used to the controls.

[Which reminds me - we're programming the game for PS2 controllers, which may affect certain design decisions]

More later!
 
 
30 May 2007 @ 07:15 pm
just took a look at the concepts for the mini games and generaly there all ok. though i really like the frist consept with the switches.
 
 
 
 
26 May 2007 @ 05:26 pm
As well as everyone submitting general game ideas, I'd like everyone to have a particular area that they're helping me work on for the report.  Everyone's free to pick a specific area that interests them.  Some examples (off the top of my head) might be: combat, character design, environment design, level design, general art style, player/npc movement, characterisation of Lobot and Belfry, gameplay, technical design, etc.  Feel free to pick more than one, or suggest your own!

This list will be updated as people email me.  If I don't hear from you in a couple of days, I'll randomly assign you a section.  If there's nothing in particular that you really want to work on, proofreading/editing the report would also be useful.

Combat/Mini Game: Geoff
Lobot design/concept art: Daniel
Belfry design/concept art: Tien
Environment design/concept art: Scott
Level design/overview: Bradley

Don't forget that overlap is not just ok, it's encouraged - everyone should throw in suggestions for all sections, and if anyone feels like doing random concept art or descriptions of bits of game, that's all to the good - the more stuff we have to show off what the game could be, the better =D
 
 
26 May 2007 @ 11:56 am
Lobot Game Design – Project Pitch Brief

It's Ico meets Short Circuit, in a shooter-action-puzzle game!

Read the restCollapse )
 
 
26 May 2007 @ 11:42 am
Hi guys!

This LJ community is a place to discuss the 'Lobot' game pitch, for the second-year AIE design project. Everyone in the group is free to both post and comment. Commenting can be done anonymously, but to make actual posts, you'll need a livejournal account - but they're free and fast to set up, so hopefully not too much of a hassle.

If you want to make an account, go to this page and follow the instructions:

https://www.livejournal.com/create.bml

Once you've made an account, log into it and go to this page here to join this community:

http://www.livejournal.com/community/join.bml?comm=lobot_dev_team

To post an entry to the community, go to your update page here:

http://www.livejournal.com/update.bml

Type up your entry, but BEFORE you post it, go to the "Post To:" dropdown box up near the top and change it to "lobot_dev_team". If you don't change it, you'll only make the post to your own journal, and none of us will be able to see it!

If anyone has any problems with it, just email me and I'll help you out =)

Feel free to post anything related to the Lobot pitch or design class in general here.

For anyone who'd rather make suggestions to me privately, feel free to email me at michelle.hughes@students.aie.edu.au, or the lobot mailing list at lobot@students.aie.edu.au, or googletalk me whenever I'm online. And feel free to drop by the programming lab and grab me at any time, too!

Michelle