Posted: Mon Sep 05, 2005 9:44 am Post subject: Jul/Aug-05: Angel Delight
This is the dual dev diary for July and August. Sorry for the lack of updates - July saw a lot of issues with our webserver (see 'business' below) which ate time (which is always our greatest commodity anyway). It's always tough trying to find time to write up our dev diaries, but it's kind of therapeutic to see how much you've done some months and wipe the slate clean. This month sees Hamish' first dev diary for War Angels which is a great read (we are very excited about this project as even in its current early production state it's great fun running around with all those guns!).
Space... The Final Frontend
The front end (setup and game start screens) for Mr Robot needed a backdrop, and so we decided it would be nice to show a little diorama of the Eidolon (the colony space ship that is the setting for the game), with slow camera pans past it as it travels to its destination. In constructing the Eidolon, we discussed several designs which were progressively outlandish. What would the criteria be? Mr. Robot is set before Starscape's faster than light drive becomes common use, so the ship would be a sub-lightspeed, long haul ship. Many of our designs incorporated crew space separate from the propulsion system via extremely long 'spines'. The separation allowing for hazardous drive technologies. This was an aesthetic we liked, but in the end we u-turned and came up with a conventional outline for the space craft.
We decided that after travelling more than 100 light years, raw materials would be very important, and so the entire ship should be able to land and be dismantled so it could be converted into the colony. This meant the ship had to be somewhat aerodynamic, even if it was probably for a one shot landing on a planet. All of which has absolutely no bearing on the game whatsoever - but sometimes its fun to think why everything is like it is rather than just making it pretty It would certainly be interesting to hear what other people hypothesize a sub-lightspeed colony ship might look like!
Modelling the Eidolon was a pretty swift affair once we had decided on a design. I made a quick mockup for the scene - an extremely rough approximation of what I wanted to achieve. It's almost just a fleeting impression of a scene, and I doubt many of you will see the point of it, but I have always found it can really help me solidify an image I have in my mind, and then it's easy for me to get on creating the final scene. It also really helps me work out the light colouring I want to strive for. Since the Eidolon is the first thing you will see when you boot the game up (after the loading bar at least!) it's important for it to set the right mood for the game, and look as polished as it can be.
UV mapping and texturing ended up taking far longer than I had imagined. The model weights in at approx 6,500 polys. Whilst in game character models in top end PC hardware can far exceed this these days, they tend to be easy to map. The mapping does not need to be very regular, and you can often get away with flat mapping 90% of the model from front and back, then just pulling the seams a little.
Regular geometry can conversely be much harder; if the texture also contains lots of regular geometric patterns (as in this case) then the mapping needs to be perfectly square, even across the whole model. It's akin to gift wrapping the worst shaped present you can imagine
The model had to be mapped twice - the first set of UVs are used to maximise the colour map by spreading the available texture over one half of the ship, then mirroring the model to create the other side. The second set roughly covers the whole model with no overlaps so I can create a light and shadow map. These two maps are then multiplied together in the shader. Additionally, the alpha in the colour map is used to pick out a few areas that need to be self-lit (like the windows). The colour map itself was yet another area that soaked time - all the regular geometric patterns have to flow round the contours of the ship and match up over uv seams. It was a look I really wanted to create but filling a 1024 square texture with single pixel wide geometric patterns can at times make you go cross-eyed Once that was complete, all that remained was to separate the text that is imprinted onto the side of the model into it's own separate set of polys, so it can be flipped on the other side (otherwise, after mirroring, it comes out backwards!), and write the glowy, animating texture shader for the jets.
All this has made me extremely appreciative of the work Relic put into Homeworld 1 and 2. Their space ship creations are wonderful and were a big inspiration to me on this part of the project.
Here's a short rendered spin round the final model:
(4 meg flash video)
Early oil pastel colour test used to gauge composition and 'mood'.
Final scene animating in the game's front end.
Do we have enough robots in this game yet? Hell No! Yet another addition to the robots onboard the Eidolon is Raistlin. Raistlin is the ship's comms specialist unit. Built round a lightweight robot skeleton; he is designed for speed allowing him to quickly locate and fix any errors in the miles of communication cabling onboard the Eidolon. Raistlin generally keeps himself busy in the darker corridors of the ship undetected by normal sensors due to his high level of interference shielding. Other droids often go about their business without even realising he is there except on the rare occasions he has something to say. Asimov has always been a little afraid of Raistlin's shadowy and secretive nature.
The design phase for Raistlin was the fastest of the robots yet. I tend to mess around with all kinds of ideas before getting inspiration, and can often end up taking longer to design the model than to actually build and texture it (a process that is pretty quick once I know what I'm doing). I don't think this is normal amongst artists btw, as I know people who seem to be able to come up with great ideas at the drop of a hat. I find it much harder to work out what designs I'm going to go with and feel comfortable making. However, in Raistlin's case, he needed to be very lightweight, and so this dictated the design from the start and I think the constraints helped me enormously. I really like it when the design of a model fits its function:)
Game Data Server
In advance of Poo Bear implementing some of the front end features, I've been writing some new scripts to handle data requests direct from the game; effectively creating a data server the game can query. This allows us to do several things: Firstly, if you are connected to the internet, the unlock process can be handled for you, making it incredibly straightforward. The script can also pass binary data down to the game if requested, and so we can now have an 'update' button in the front end - one click and any patches are downloaded and automatically installed.
That's the theory anyway Poo Bear still has to implement the much harder part that the game has to take care of. We are also moving to having codes available on a timeout basis, so in the future nobody should ever be in a situation where they reach the limit on the number of codes they can request. All these ease of use enhancements will also be rolled into Starscape 1.6 once Mr. Robot is finished.
Business Why I hate server administration/ Moonpod Catastrophe avoidance plan.
July and to some extent August was a complete pain due to web server failure, but has at least been a tour-de-force example of the Moonpod 'Catastrophe Avoidance Plan'. Our current web hosts warned that they would physically be moving our server to a new ultra secure, ninja-proof bunker complex, that would be patrolled by attack dogs and killer robots.
They said that the server would be out of commission for 17 hours on a weekend. We don't want to have any downtime though; sales aside, it means customers can't log in to get codes. We definitely didn't want to deny anybody their Starscape fix, so we rented a fast server with full 24 hour tech support included (the kind that you ring any time and they do whatever you want to the server immediately!). That's expensive, but it's better to have someone else there incase anything goes wrong. So, 2 days before the planned server relocation, we took down the forum and buy pages, backed up the database and transferred it to our temporary web server. Set up a redirect and re-enabled everything. From that point on, everything was up and running on our temporary server with no problems, and we just needed to change the dns so we wouldn't have to bounce people off the old server.
Everything went well; the tech support turned out to be a waste of money, because the temporary server had a fantastic custom control panel that was better than any I'd seen anywhere before and did everything. Although it was nice to know support was there if we needed it.
Then the time came to move back, and we tried to access our usual server...
Maybe one of the killer robots went haywire and zapped it, or one of the attack dogs peed on it, I'm not sure, but it was now dead. So, our hosts apologised profusely, and set us up a new server straight away. Everything is backed up (Thanks to the catastrophe avoidance plan!) so no troubles there. However, there's some things you can't back up so easily - the server configuration doesn't transfer so nicely between different installs of linux/control panels. Our new server had an up to date install of Fedora and a control panel. Our old one ran an ageing release of redhat and had been administered entirely via commandline. It took me quite a while to work out how to even set up a website using the control panel, and then just as long to work out where the website files should be put (I knew my way around the old server and this was undiscovered territory for me.) Eventually we got the whole thing up and running and made it live.
...and that's where all the problems began. Perpetual issues like ad links being broken because of a minor php version issue (and therefore wasting a pile of money on ads that didn't display anything when anyone clicked on them!), reverse dns on the mailserver being broken so some mailserver rejected email from us. I won't go into the other boring details, but every day, tracking down these problems was taking a lot of time. Pretty much every day for 2 weeks, some minor issue cropped up and meant I had to spend the entire morning tracking down the problem and fixing it.
Whilst I'm really happy we have a catastrophe avoidance plan that has saved the day, this has proved the old adage "If it ain't broke, don't fix it!". Sadly, in this case, it was out of our hands, and cost us a lot of precious time
Last edited by Fost on Wed Oct 19, 2005 9:35 pm; edited 65 times in total
Joined: 14 Oct 2002 Posts: 4107 Location: Sheffield, UK
Posted: Wed Sep 07, 2005 9:16 am Post subject:
Easing The Player Into The Game
I've spent a lot of time creating the game's first phase which introduces the characters, sets the stage for the plot and explains the different game mechanics. The ideal I'm aiming for is that set by Nintendo and now much copied. A Nintendo game doesn't require the player to read a manual or feel they are taking part in a separate stand alone dry tutorial. They want you to get playing straight away, to introduce and explain new game mechanics gently as they appear. The goal is to get the player having fun immediately (within seconds) and to get him comfortable with how the game works, why he is there, and what he is trying to do. All without the player feeling they are back at school or that they are having to work at it.
To try and achieve these goals I've made the first section of the ship require a linear progression with each room adding a single new game mechanic. You will also meet some of the main characters and get a feel for being a lowly maintenance robot performing his day to day duties. So hopefully you begin to understand how the game works, what is happening within the world (your ship) and your relationship to your crewmates. Everything starts out fairly normal, but along the way you get clues to things starting to go wrong and then at the end of the first phase everything falls apart and fate selects you to step up.
Writing dialog and plot is very difficult, I'm not talking about the quality of the writing here, we have a professional writer to take care of that. It's avoiding reams of text that lie above the game, again Nintendo are very good at this. Players need to be directed to perform interesting tasks or be taken through interesting situations; it's no good just having 5mins of gameplay and then expecting them to read/listen 3 paragraphs of text (no matter how well written) that don't immediately impact on what they are doing. To achieve this you really need a good scripting system, this takes the pressure off the programmer and ensures it is relatively easy to bind the player's activities and the dialogue together and keep those activities fresh and interesting. Now I'm not saying MrRobot achieves this, just that it is a goal to aim at.
In MrRobot I need to communicate that Asimov is a lowly bottom of the ladder generic maintenance bot, only recently activated, desperate to impress his superiors so he might gain a specialist role and gain his comrades' respect. A classic story theme, although his aspirations are thwarted in daily life, fate puts him at the centre of a catastrophe only he can conquer requiring him to rise above his self imposed limitations and realise he can gain the recognition and respect he seeks without needing a new specialist robot body or title.
Communicating all that in a simple fun action/puzzle orientated adventure game is very difficult. A lot of well written prose might work quite well in a more serious rpg adventure title, but it wont do here at all. So instead those themes need to be in the designers head at all times and they need to "leak" out through the dialogue/activities as naturally as possible. If you do it right most people might not really consciously even notice and you might not communicate everything to everyone; people pick up different things. This is what happens in good quality episodic tv shows, they only have 45mins with you and there has to be some big in your face action (or fox will drop it) - i'm thinking firefly here . How do they communicate character relationships, setup an interesting world background, develop each character, develop multiple over arching story threads? Sounds impossibly hard, but it's what they all try and do with subtlety and transparency. The same thing happens in games, but the techniques are different and it happens much much less often. Something to strive for even if you don't achieve it. A writer cannot do it on his own, weaving plot into gameplay is crucial and you need a game designer to do that, but he cannot do it alone either. He wont have the writing skills or more importantly the understanding of how to develop interesting characters, their inter-relationships and the larger over arching plot/story that a player might actually care about.
On a more practical level, I've added mouse support. People just love their mice and even if it makes more sense to use keys or game pad a lot of people just don't want to let go of that mouse. So the instant you touch the mouse in Mr. Robot, a little direction icon appears at Asimov's feet and you can drive him around. Left mouse to walk and right mouse to jump. Simple and a lot better than I thought it would be, but not as accurate as keys.
Simple Position/Euler angle Animation Scripts
To spice up the front end and encourage the idea you are inside a giant space ship we're going to show it slowly gliding by in the background of the front end. A very simple implementation where camera position and orientations are entered, comma separated, one frame per line (25 fps) into a text file (although I think Fost is managing to get some useful ascii data from blender now). The frontend is locked to the same update rate so each update overwrites the camera with the next frames data. You really can't get a simpler camera track animation system than that. Even better, the camera never goes vertical so we can use simple euler angles for its orientation. No need for a more complex quaternion implementation as we never have gimbal lock and we don't need to interpolate rotations. A lot of people avoid euler angles like the plague but there are still cases where they work fine. A 3 day job turns into a single afternoon. I hate it when projects slip because people become obsessed with "clever" implementations, bulletproof code that works in any situation and is completely reusable. Those goals are laudable, but taking shortcuts is quite often a more sensible approach especially when goals are shifting, the game is still unplayable or deadlines are slipping.
Hello everyone. For those who know me, I apologise for leaving you without updates for five months. For those who don't, let me introduce myself and my game. I've been making freeware games for about 10 years now and have taken up a position at Moonpod developing my latest game, and hopefully many games to come. For the past year and a bit I've been making the sequel to the FAIND game Factor X, which is now being developed into a stand-alone title for Moonpod. This is no longer a sequel, but rather a new game with a similar theme (and one similar character).
Because this is my first entry, I'm going to start off with more of an overview of game. Next month I'll get more into the development process.
War Angels is a top-down action game controlled in the same way as Crimsonland, Alien Shooter, Mutant Storm and other similar games. Set in an alternate future where the Nazis were not defeated in 1945, and the free people of the world continue to fight a desperate battle against the futuristic Third Reich. You take control of one of four female mercenary commandos, each with their own special abilities (which I'll go into later).
Unlike many other independent games in similar vein, the player will follow a story that folds out through the levels as the game progresses. At the start of the game you are employed by a research organisation to stop their time travel technology from falling into German hands, which will eventually lead you across four different locations and time periods, each with their own set of enemies and weapons. Weapons will range from laser cannons, multi-missile launchers and micro nukes in the far future to advanced projectile weapons like hand-held miniguns and railguns in the earlier time periods. There will be over 40 unique weapon types to play with along with many different grenades and character abilities.
Minigun, Salvo Missiles, Flamethrower and Laser Cannon in action
The game can be controlled by keyboard and mouse (by default, using the keys to move and mouse to aim) or keyboard only, mouse, joystick and gamepad.
The prominent gameplay mode will be Campaign Mode, where you work your way through the story in four different time periods, collecting weapons, money and upgrades. After each level there is a non-combat headquarters section, the main feature of which is the shop. As you're a mercenary, you'll have to buy most of your equipment with the money you get paid for completing objectives. Enemies will also drop money and equipment, and many powerups can be found hidden around the levels.
Arcade Mode will be added if we have time, where you can jump straight into the action and compete for an online high-score. If we have even more time Co-Op Mode will be added, where you can play arcade mode with another person on the same computer. These might have to be saved for a patch or expansion, though.
My first task in converting the game from a pretty demo (as it was before I joined Moonpod) into an actual game was to get some proper game levels up and running. I already had a basic editor, but to give the maps some action I needed to make some sort of scripting system.
Scripts are composed of two types of objects, Triggers and Events. Events are enemy spawns, powerup spawns, music cues, sound cues, anything the player observes. Events are linked to Triggers, which usually take the form of invisible boxes on the map.
When the player triggers a Trigger object (usually by stepping inside the box) all the linked Events will activate (enemies will spawn and attack the player). This gives the illusion of enemy tactics and organisation, where flanking and ambush attacks can be made easily even with simple "run at the player and shoot her" enemy AI.
This month I've been working on the four characters you'll be able to play as. Each character has their own special ability which you can develop as you play. Your other teammates will help you in many of the levels as AI characters aswell, but to see their special abilities in action you'll need to play as them. (As the characters are not yet named, I'll name them by their special skill for now)
This character will be able to purchase and find weapon modifications for her guns. The most common and useful weapon modifications will be alternate fire modes. For example, when you buy an extra barrel mod for your shotgun, pressing alternate fire will do a more powerful but less accurate double shot. The machine gun will be equippable with a tripod, which can be deployed on the ground, making the player into a stationary turret but greatly increasing the accuracy of the machine gun.
This character gets a hovering robot drone, which can be equipped with a miniature arsenal of guns and missiles. With your special fire key you can order it to move and attack - allowing you to surround enemies and using it to scout ahead and clear out fortified positions.
The commander has the authority to call in air support from your allies. Airstrikes, artillery shellings, paratroopers and in the future orbital laser and nuke strikes will all be available to call in at the players whim. Non-offensive support options like supply drops will also be available.
The covert ops has a special utility weapon, able to hack into electronics from a short distance. It can be used to make enemy vehicles lock up, turn enemy drones against them, make nazi cyborgs brains go haywire - when it is fully upgraded the beam emitted will even be able to fry normal infantry. Out of battle it can be used to reprogram enemy security systems and other computers around the level. Hacking an ATM machine in the city will make it drop an extra cash bonus for you.
Next month: 3D Maps
Last edited by Hamish on Thu Sep 22, 2005 2:01 pm; edited 34 times in total
hey that looks pretty spectacular i am amazed it will look like that in game. some kind of moonpod space combat game would be neat! i used to be a fan of the colony wars series. imagine dogfights in starscape devstators round these massive capital ships
some kind of moonpod space combat game would be neat! i used to be a fan of the colony wars series. imagine dogfights in starscape devstators round these massive capital ships
Yeah, space combat games rock. We'd love to make one, but they do seem to have a habit of taking out their creators. It's like some universal curse on space game development.
No reason why you couldn't have a couple of ships like that running around on modern hardware though. 6500 polys isn't a massive amount. Although the lighting is burned in, but stencil shadowing could take care of that.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum