Fost - Mr. Robot Art
Another hero object we have used in later areas is the Eidolon shuttle. The Eidolon carries several of these for making short scientific expeditions. (Sorry, Asimov can't fly them off though ;) ). I wanted the shuttle to have a small visual link back to the Starscape universe, and so it is designed to look like an earlier model of the Aegis' shuttles from Starscape. It was fun extrapolating the former 2D design into 3D, but it presented a few problems with the collision objects. Static block objects can only be concave boxes on a half height grid. The shuttle had to be designed around this proportion system, and then split up into 6 separate objects each with their own collision. Takes a little while to assemble it in the editor, but it works nicely. I've named the first one Serenity after our TV favourite :)
Assembled Shuttle in game.
Learning C++ - the copy and paste method!
The bane of a game artist's life is usually the editing tool they use. With indie development, there's even less time for programmers to spend making the tools 'friendly' and so editor work is more often than not a case of becoming familiar with what will crash the editor and making sure you don't accidentally do that, and hitting save every five minutes. I can't fail but appreciate that this suffering is necessary - better Poo Bear works on interesting gameplay than have him waste time wading around in editor code he didn't write!
Still, sometimes there are some incredibly minor fixes that could make my life much easier. To this end, I started learning C++ in the only way I know how - hacking around copying bits of code from one place to the other. My previous knowledge of PHP, maxscript and AMOS basic ;) helped me find my way around, and make some small tweaks to the editor.
It's a really bad idea for a non-programmer to start messing about with production code, but I've limited my efforts to the editor in the vain hope I won't destroy everything :) . So far I've changed the way lights are displayed so you get nice, axis aligned wire loops rather than the wireframe ones we had before. I've also added a zoom feature - again, a very basic thing, but we hadn't needed it before I started lighting the rooms. Some interesting lighting effects can be made using really huge lights placed far away, but they were impossible to find without the ability to zoom out. I've also made the editor save the last room it worked on so you can slip right back into what you were doing quickly, and fixed some small bugs where lights were moved around if you resized the room.
All quite small things, but they make my life that bit easier, and put us a bit further down the path to the possibility of releasing the editor. On that note, I've added help buttons and started a compiled html help file (.chm) to the project. Currently, the editor is not releasable*, so I don't want to get everyone's hopes up. I'm keeping as many notes as possible for the help file just in case it becomes possible.
*That's our opinion at Moonpod anyway - we don't like the idea of releasing the editor 'as is' without putting more work into 'bulletproofing' it.
My remaining task list is choc full of small items. I'm basically filling in the blanks. Poo Bear makes a room, and if there's anything unique he needs, he adds it to my list. Since we added a big robot like Samson, we also needed a big door for him to go through. One of the sections in the game also contains an airlock. the airlock in particular ended up being more work than I initially envisaged (Or, I should say, I added a bit more to it than was strictly necessary!). The materials system we have is very capable, but there's no user friendly interface to it. So even adding simple texture scrolling to an object involves quite a bit of messing with the shader. The airlock has 3 separate door sections, and a copy of those doors offset back slightly and darkened to give the impression of depth (remember, doors are built in Mr. Robot from single polygons and use texture scrolling to slide the door out of the way. This means there's no depth to them, but it can be faked with another copy of the doors.). Lining up all these door sections was very difficult because I had to keep resetting rooms and picking up keys to see them open. This is where Lua scripts turned out to be very useful. Poo Bear showed me how to set up the room to open and close the doors on a timer, so the doors perpertually opened and closed. Great for finding visual discrepancies :)
To cap it off, the Airlock also has a basic shader to turn lights on and off, and a slightly more complicated shader that 'camera maps' a texture onto the surface. this is used on a backdrop rectangle that sits outside the doors. As you move around and the camera pans, the space and stars image appears to be locked to the camera, and therefore looks infinitely far away.
Airlock (Left) and Big, Samson Sized Door(Right) in a test room.
The Vacuum (cleaner) Of Space...!
Mini Flash Animation of Dyson the Cleaning Droid.
Meet Dyson - head of the Eidolon's cleaning crew. Dyson has what you would call a 'walk on part' but he was a lot of fun to come up with. Poo Bear's daughter drew me a little picture of a robot with long 'anglepoise' style bendy arms for cleaning up the space ship. I really liked the concept of a futuristic vacuum cleaner robot :) I also love the design ethos behind the products made by the Dyson company. So I came at this design wondering what the people at Dyson would be making in the future :).
Dyson is probably the last robot to go into the game, unless we decide that rooms need something adding to them during play testing.
Final approved Dyson concept design.
Dyson Game Model
Flip ya for real!
Just some quick little art tips. They probably seem obvious and incredibly minor to most people, but every now and then I discover things that make my life easier.
- Shorcuts in Photoshop: I've no idea what version it turned up in, or if it's always been there, but in the current version of Photoshop you can edit the shortcut keys. During the texturing process, I end up making loads of selection flips and rotations to construct geometric shapes from basic lines. I added shortcuts for FlipY, FlipX and Rotate 90?. It's amazing how small processes can break your flow of creativity. These 3 shortcuts mean I now just mess about with texture alignment to my heart's content - because it's easy to try things out in an instant.
- Never overlap textures: I've made this a golden rull from now on. Sometimes in the past, I've been annoyed how textures won't fit perfectly on a page because of one small part. Sometimes I fix this by re-using the same piece of texture. I'm not talking about texture mirroring here (using the right side of an object mirrored to create the left side), but thinking things like: 'that bit of arm there can be re-used to texture the fingers or hand'. Don't ask me why, it's a mystery, but it just never works! Usually some bit of shading makes the whole thing look fine on one part, and broken on the other. I've stopped doing this, and I'm happier for it!
Relight My Fire!
A continual job on Mr. Robot is lighting the rooms. In theory, I could just use a default ambient light and directional light and save myself some trouble, but I don't think that would really show off the game (plus, it would get a little dull). Besides, I like breaking my own back :)
One thing I've discovered in lighting, is that I can get really nice hue falloffs using two lights in the same position. E.g. one deep orangey-red light with wide range, and a smaller yellowey light. It's obviously double the cost of normal lighting, so I can only really do it in smaller rooms, but I really like the way the hue of the light changes as it falls off.
Although the image has a lot going on, you can probably just make out the lights/ranges and positions:
Poo Bear - Mr. Robot Programming
I've just put the finishing touches on the last section of the ship and I feel like I've just crossed the finishing line of a marathon. I wont say how many separate rooms and corridors and sections the ship has but it's well over a hundred. It would have been easy and quick to just regurgitate different configurations of the same challenge again and again but I decided early on to avoid that at all costs. This is the main reason the game has taken so long to create. The game has a great editor and also makes heavy use of the LUA scripting language; both firsts for us. These tools were essential to hand craft this quantity of unique content, but even with them it was a mountain of work.
Sadly this doesn't mean the game is ready to ship (oh if only that were true!), I still have to setup all the "ghost hacking" battle stages. This is where the robot Asimov must hack into a defended computer system with the help of his comrades. Development is split into phases, you have prototyping, then production, the alpha and finally beta.
Prototyping - is this actually fun? how does the code work? can we build it, create a design document and make the tools?
Production - following the design document go ahead and build everything.
Alpha - bring it all together and get it working properly so you can play through beginning to end and playtest it to hone the fun to its maximum.
Beta - fix all the bugs and get all the ancillary items sorted like installers and websites, etc.
I'd say ghost battles are well into their production phase with the rest of the game now just into the alpha phase. So for the first time I feel I can see the light at the end of the tunnel. Hacking sees you exploring the glowing circuits of various computer brains and secure networks with periodic battles. Ghost battles are turn based and start with each group of adversaries facing off to each other. Asimov and his friends line up on one side and the enemy group into formation on the other. The player then gives orders to Asimov and his friends and then an internal initiative system sees a round kick off with software attack programs flying through the air and I.C.E. breaker attacks smashing into their targets. During the course of the game the hacks get more difficult and Asimov has to power himself up by collecting various upgrades. He also picks up more and more friends for his ghost team along the way.
The LUA scripting has grown into the real backbone of the game code. LUA is a simplified C language that is very easy to use and still allows the author to create very powerful expressive functionality within the game. On its own it cannot interact with the game world so you have to extend the language by providing new commands that allow the script to do things to the game. Getting all the language extensions in took a major time investment, but it has already paid off. It's interesting to compare it to the WarAngels system which went in a lot faster and is much easier to use by non-programmers. It depends what you need in the editing process, with MrRobot each area of the ship is in many ways almost an entirely new game in terms of actual game mechanics. With a mountain of a ship to build I had no choice but to create a powerful scripting system, without which the ship would have had replicated content or been a lot smaller. WarAngels is different and it would have been overkill to do the same thing, adding maybe another 2-3 months onto its schedule for little benefit. In that game the fun comes from exploring the level, finding and using appropriate weapons and ammo, along with the placement, AI and choice of enemy types. Speed and destruction. The right tools for the right job is half the battle.
The command list has grown quite extensive so far:
Hopefully it wont be long until we get the editor in a state players can use it and then they could access exactly the same library of commands when making their own game levels. That would be very cool.
We've just finished some initial testing on the dreaded "built into your motherboard - shared memory" graphics processors that are so prevalent these days. The old ones were terrible, absolutely useless and we had lots of email from people who couldn't understand why no game worked (including ours). The new ones, led by the Intel Graphics Media Accelerator chip (the GMA900) are light years beyond their prehistoric ancestors. Everything works fine and they even support pixel shader 2.0 which is amazing considering how cheap they are, these chips cost pennies and come built-in to bargain basement motherboards. I was so impressed with that particular chip I even tried Doom3 on it and it worked !! Ok I was only running at 640x480 and had everything turned down, but still, an impressive achievement compared to the old Intel eXtreme chips.
Here's a great tip for anyone up against it. The new scientist recently reported the findings of a study looking at how food affects sleep. They found that eating a lot of chilli's every day caused their subjects to require less sleep and remain fully alert longer. It is thought the effects are due to capsaicin, the chemical responsible for peppers' spiciness. It acts on sensors in our brain which control our sleep cycles causing us to spend longer in deep sleep. This mode of sleep usually only lasts for 30mins a night during which you do not dream and it is almost impossible to wake up. Test subjects remained in this state longer. Chilli also cuts the risk of heart disease. So there you go, eat about 30g of chillies a day and get a few extra hours of work done. I tried it and it worked for me.
A Few Room Shots To Keep You Going!
Dyson does some spring cleaning
Asimov ponders what to do. Luckily, the tiny nanomek team are on hand to assist!
Hamish - War Angels
Sorry for the lack of diary updates for those of you who are following the game. I've been working hard converting the game to it's new 3D look over the past few months, so with all the work I've been doing and the lack of substanial screenshot material I didn't manage to start an entry in time. Now that things have settled down and the progress is starting to show I hope I can make an update every month.
Perhaps the biggest advancement I've made on the game in the last few months is from switching to 2D tile-based maps to lightmapped 3D polygonal maps. I was consistently unhappy with the look of my 2D tiles, they were taking a very long time to make and get into the game editor and were taking up alot of disk space. I thought about the limited 3D effects I was already using, then I had an epiphany - why not go the whole way? I did some experimenting with a 3D editor, and after a few weeks I came out with a result that I felt looked alot better, and was alot easier to edit and develop.
I established a good art pipeline with two cheap, independent 3D utilities - Cartography Shop for modelling the levels (placing and texturing all the shapes that make the physical map) and Gile[s] for lightmapping them (Creating a second texture layer over the whole map that is blended over the the top of the original texture map to create lighting and shadows). Both are simple enough for a 3D newbie like me to pick up and plug into my game straight away while complex enough to create decent looking game art.
Before I start making the map I go through a rough planning phase. This is the first time in my game development life that I've actually planned levels, but when you have three programs to run your map through to get it up and running in the game I find it's faster to draw it up first. I already have all the level settings jotted down so I know basically what I'm aiming for to start with, the plan is used mainly to plan the way the gameplay flows, where specific art pieces will go (like the park and the mall) and where certain scripts will be executed. The map will probably change radically while it's being made but this serves as a good starting point.
Constructing the map is a 3-phase process, using three different programs. In Figure 1 you can see one of Cartography Shop's 2D viewports, where I lay out the map geometry. Figure 2 is 3D view of CShop where I set the textures for each polygon and scale/rotate them so they fit to the polygons perfectly. Then it gets exported to Gile[s] where I lightmap it. Lightmapping takes quite a while, doing a full level can take an hour, so I break up a level into 5-10 segments so I can test each piece quickly. In Figure 3 you can see the lit map area in Gile[s]. Finally the lit map is exported from Gile[s] into a format the game can read. I run the game in Editor Mode, where I place all the enemies, scripts and other interactive objects. In Figure 4 you can see me playing the completed map segment.
Ultimately converting the maps to 3D was a big success. Unlike tiles which have hundreds of variations, textures are very easy to modify allowing me to tweak them very easily. Computer-calculated lighting looks alot more natural and consistant than my previous attempts at shading and colouring grey buildings and the perspective of it all looks good in motion as you can see in the video at the end of the post. Here's a comparison shot of the old 2D city park and my current 3D park:
Once the map's been made, I have to populate it with interactive objects; mainly enemies. With action games becoming less abstract and increasingly realistic, designing interesting enemies and challenges becomes increasingly difficult. While this game isn't Rainbow Six I still wanted enemies that had a bit of backstory and seem realistic, at least within the game world. When I started the game I designed my enemies like a strategy game - soldier with 10 weapon variations, tank with 3 turret types, humvee and apc with mounted soldier on top, etc. They were all realistic army units, but many were no fun to fight. Tanks, snipers, machine-gunners and other anti-infantry units could kill you in an instant.
With my latest revision of enemies I've put player fun and variety first, and come up with a new three-enemy set for Level 1. Each one requires a different tactic to defeat, and can be combined together requiring you to use multiple tactics in the same battle. I've also managed to give them a background and purpose in the game world, which won't be readily apparent to the player, but certainly helps make the world feel coherent and detailed to me, which will hopefully show through with the dialogue and story.
Conscripts will be the first type of infantry you fight. They are not true Nazis, but rather people forced into the army when their country was re-conquered by the Nazi army. Not being Aryan they are looked down upon by the real Nazis, and forced into their own divison of the army (identifyable by their blue uniform and yellow V logo) where they are equipped with cheap and often ineffective weaponry. The Nazis use this divison either as meat-shields at the front of an invasion, or in the case of the first level, backwater occupation forces with a low risk of combat. They are not well trained, or often not trained at all, and therefore very weak and cowardly. They will often try and run away when you kill the rest of their squad.
Gameplay wise they are the pefect enemy to start the game with. Easy and fun to kill. There are four or five variations of the troops, with riot gear like shields, batons or grenade launchers. Most troops can be fought in the same manner however - keep your distance, and kill them before they can get close enough to hit you.
The patrol bot was developed to aid Nazi conscript occupation forces in subduing civil unrest and rioting. It can be programmed to autonomously patrol the streets attacking percieved threats, instilling fear and obedience in the citizens of conquered cities. It functions well against rioting civilians, with light armour and an area-of-effect grenade launcher (although it can be equipped with other weapons). Its threat to you is minimal however, and will be taken down easily with high-calibre weapons or explosives.
One enemy type alone doesn't keep the player interested for long, so I made this enemy to compliment the soldiers on Level 1. It is relatively fast so strafing this enemy is more effective than running. It also introduces the player to the concept of armour types early - your team-mates will point out that grenades will destroy them much quicker than bullets will.
Deployable Missile Turret
This deployable missile turret shoots two guided rockets at once, and is used against tanks and low-flying aircraft. Their heat-seeking guidance system won't work on people however, so if you fight them alone they can be taken out with relative ease.
I was previously using machine gunners as mounted enemies for the first level, but these proved to be much more interesting. Missiles are slower than bullets but more deadly, so the player must pick them out of the crowd and dodge them on top of whatever else they're doing. And once you kill them, you can get on their turret and use it yourself. Letting the player use a big gun early on in the game definitely helps sell them on it.
On the programming side of things, I've recently had to write an external scripting system for special in-game events and dialogue. It had to be flexible enough to use for any sort of scene I needed to program in game, and easy enough for script translators to go through and change/add/remove all the dialog. The scripts are all written in an external text file then parsed into the game when it loads up. Here's an example script I've been using to test:
Say Captain #Sup doods#
Say Rayne #Hello#
Say Captain #I'm walking to this spot over here#
Move Captain TestZone
ZoneWait Captain TestZone
Say Captain #I have arrived#
say Rayne #Great work!#
the 'Say' command will make an in-game message box pop up, with the specified character portrait and it will display the specified message. 'Wait' will wait for a certain amount of milliseconds. With these two commands I can create dialog between characters. Aswell as being able make conversations, the script can currently move characters to places with the 'Move' command.
In the game there will be an invisible trigger area set to start the script - in this case 'TestScript'. Other areas like 'TestZone' and characters like 'Captain' and 'Rayne' are also defined in the in-game editor. When the script is started, it will go through and execute each command in order. With simple conditions like 'Zonewait' which waits for an object to reach the specified zone, I have quite a powerful mini-programming language for me, a scriptwriter or a translator to develop the ingame story with.
I've decided to show a short video of the game if possible each month. I'll start off with a much longer preview of the first map (with a few of the more expensive weapons). Right-click the picture to download (18 meg):