FAQ Search
Memberlist Usergroups
Profile
  Forum Statistics Register
 Log in to check your private messages
Log in to check your private messages
Moonpod Homepage Starscape Information Mr. Robot Information Free Game Downloads Starscape Highscore Table
June-05: Re-Animator!
Goto page 1, 2  Next
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary View previous topic :: View next topic  
 Author
Message
Moonpod Developer Diary RSS feed -RSS Feed
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Fri Jul 08, 2005 11:51 pm    Post subject: June-05: Re-Animator! Reply with quote

Move Your Body

Goober finished animation support a few months back, but I didn't have time then to test it. We are using the MD3 model format (from Quake III) for animated models only. There's some limitations compared to our own format, such as no vertex colours/multiple uv sets, but it supports animation frames, and more importantly, there's a lot of existing, cheap/free animation programs out there that also support MD3. There was a lot of free loader code knocking around which meant Goober could get something up and running quickly.
Getting a model into the game is not as simple as just exporting it because we have to tag the MD3 with our own shader system files, so there's also a separate text file that sets that up. For my first animation I again tried using a bunch of separate meshes exported from wings 3d. I have to say - I would never recommend anyone try this Smile It's the worst way you could animate EVER! Basically I'm getting animation out of a modelling package that doesn't support animation. I export each model to a numbered set of moonpod models, and then use a commandline tool that Goober has written to compile the MD3.

This is truly awful, not just because the export process is slow (even when using lots of batch files to automate it), but because you have to animate each frame in isolation, and you can't see the others. I ended up making a pencil rough of the animation on paper, scanning each frame, and then using it as a backdrop to line everything up. then if anything looked odd on the pencil test, I could take a screengrab of the model, print it out, sketch over it on my lightbox, and adjust bits until the pencil test looked good. Then I can use that as a backdrop in wings3d to line up all the objects.

Incidentally, at this point, I must publicly thank Stan Hayward, creator of Henry's Cat, for the valuable animation talk he did on the BBC many years ago. I just had a look and found that Stan has loads of 'getting started' animation lessons here: http://www.makemovies.co.uk/



Anyway, that's obviously not going to work as a plan for animating the rest of the Mr Robot models, so I need to investigate budget modelling/animation packages. We bought a copy of milkshape ages ago, and I've been putting off learning anything about it, but it does seem to have everything I need to do animation properly and also exports direct to MD3. I'll probably still continue to model using wings3D (I've gotten pretty comfortable with Wings3D over the past few years), and then animate using milkshape. I seem to have a knack for inventing convoluted art pipelines Smile

Here's the result of a lot of effort - a 16 frame walk cycle Smile
(2.5 meg flash video)
Keep On Walkin


ORGUS: A Brain The Size Of A Planet!

We have quite a lot of robots now, but, you can never have enough! Here's our latest addition to the friendly bots on the ship, meet Orgus!

I often model the robots after an initial rough (I call them toilet roll doodles:)) because it gives me enough of a silhouette to know I'll like the end result.

For friendly bots, I tend to work this up into a far more detailed picture - they have for more personality than the enemy bots(I hope!), and it's important to me to get that across. The enemy robots are deliberately 'soulless' and I can usually nail them with a quick scribble.

Orgus' design is based on how I'd always imagined Marvin the robot should have looked when I read 'The Hithchiker's Guide To The Galaxy'; essentially an enormous brain with legs and arms.

Orgus is slow and weak in the physical world, but will come into his own during ghost hack where the processing power he has available can kick butt!


Concept Art Stages

Final Game Model


Water Vertex Shaders

Not the most interesting way to use vertex shaders, but we've used a vertex shader to scale the textures up and down with water blocks. this means that no matter what size you make them in the editor, they always come out looking the same.



The Boring Old Business Bit.
Yes, here's the bit you can skip where I complain how I haven't done enough work because of the requirements for running a business at the same time. Wink

Spent a huge amount of time this month re-working our payment templates. SWREG, who handle our online transactions, have just been bought by Digital River. This is hopefully going to be pretty good, because Digital River have a really massive affiliate network - so hopefully we can get our games on affiliate sites*1. This isn't something we've put a lot of time into before because of the effort involved with setting up another payment system. The slight downside to this buyout has been Digital River have needed to make a lot of changes to the payment system templates*2 for VAT and state Taxes. We have some pretty heavily customised templates, so I needed to implement the changes carefully and make sure they were well tested.

*1. Affiliates work by hosting sites that reccomend or advertise your game. Anyone can sign up to do this if the payment system allows it, and they are paid directly from the payment service company (so we can't pretend you never made a sale for us and cheat you:) ). All you need to do is sign up and then use a special link to the game and downloads of it. You too could be making money selling Starscape and Mr. Robot. Smile

*2. Most of the better payment services allow you to customise the pages where people enter their credit card details etc so to all intent and purpose they look like your own site. On the face of it, this sounds like a trick, but this is actually how most sites operate payments. Even ones that collect your credit card details themselves have to post them on to their merchant account provider. I actually prefer to see another company handling the payment these days. Especially if I'm buying something from a small company - which makes more sense - the small company doing the credit card/payment security, or a large company with expertise in the field who's sole purpose is card processing? I know I would not be comfortable staying on top of all the security exploits that crop up these days.

The other business pain we had this month was a long downtime at our service provider level. This was unavoidable and it happens from time to time. Fortunately they gave us a warning well in advance, so we had time to temporarily shift the server over. If anyone reading this is thinking of starting a web based company - I strongly recommend using a dynamic dns service, such as freeparking to register your domain. It's saved our lives many times - if your hosting company turns out to be rubbish/goes bust/ burns to the ground, just get a new server, upload everything, and point the domain at the ip of the new server.

Next Month:


Last edited by Fost on Mon Jul 11, 2005 5:52 am; edited 57 times in total
Back to top
View user's profile Visit poster's website
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Fri Jul 08, 2005 11:51 pm    Post subject: Reply with quote

Battle Control
Battle mode brought with it quite a large management overhead in menu screens as I discussed last month and now we have the second menu screen load to implement. This time we need mini-screens within the actual battle for things like:
  1. deciding what each of your avatars is going to do in the next round.
  2. changing the currently equipped items (ice and ice_breakers).
  3. selecting a program to fire off.
  4. selecting a carried item to use.
  5. selecting a special attack.


Menu screens are a real pain, they aren't the most exciting aspect of development yet they are vital to the players experience. They don't usually contribute to the fun but they can easily get in the way of the fun and therefore a lot of care needs to be taken in their development. A lot of the functions within a battle are streamlined replications of the larger menu screens done previously. Why bother? why not just make the player switch to those other more detailed screens? That would have been easier but it would certainly have got in the way of the fun. It would have meant bringing up a full screen menu right in the middle of a battle; not a good idea. Menu screens are a tool to let the player operate and interface with the game, they must be intuitive, enabling and transparent. When the game goes beta we'll enter a cycle of user testing and alteration, not just to fix bugs but to make sure the menus don't get in the way.

Streamlining Workflow

If you ever want to give yourself a shock then take one work day and try and analyze your efficiency and work rate. It is difficult to do because if you consciously try and analyze what you are doing from minute to minute it will affect the results. How much time do you spend chatting with colleagues, eating snacks, at lunch, reading emails, browsing the net, day dreaming, writing emails, checking the newsgroups, going to the toilet, in meetings? Now take into account that the human mind cannot stay focused and concentrated on a specific task for long periods and that once distracted it can take up to 15mins to re-enter "the zone" - a fully concentrated state of mind. So before we've even looked at the tools we use we have an uphill battle just to get a decent amount of work minutes each day. Now consider what you are actually doing and how worthwhile it is. Whether you are an artist or a programmer you will spend your time making minor changes and then reviewing them in action. You tweak a texture on a model, save it, export it, run the game, load it, get to the point where the object in question exists, use it, review it, repeat. Same thing happens with code, alter something, compile a new exe, run the game, get to the point where you can see the change, review it, repeat. The bigger the game gets the slower this loop becomes. If you manage to get 2 hours of useful work a day (yes it can easily be that small) how much is spent clicking buttons, waiting for compiles to finish, loading saves, navigating to a certain point in the game? How much of that super valuable focused work time is wasted? The key to maximising work time in game development is fairly obvious:

  1. let the game reload everything on the spot without having to turn it off and restart.

  2. put the minimum number of clicks between starting any operation and completing it.

  3. Automate everything assuming the normal best practice, if there are unusual cases then add provision for handling them but don't break a smooth automated process just because 1 time in 10 a user needs to make a decision.

  4. Put time into tools, they are boring and dull but are vital. The easier it is to do something the faster you can do it. The faster it is to do something the more likely you are to have time to experiment. The more experimentation is done the more unique gameplay emerges making a better game.

  5. Use scripts and initialization files wherever possible, if changing something means recompiling then only a programmer can do it, it will take time and therefore it wont happen most of the time.


LUA scripting

This month as part of that mantra we've started putting in the LUA scripts that operate any unique functionality in a room. A room doesn't need a script as most things happen automatically i.e. running, jumping, pushing switches, getting killed. However, if that was all there was to it it would be a little clinical so when we want people to talk to you or something unusual to happen we put it in a script. That way a programmer doesn't have to write it or test it, all he has to do is provide support functionality in the form of a suite of functions the script can call that make things happen (that's next month spoken for then Wink).

We've also been implementing one-click context sensitive reloading, this means whatever you are looking at in the game you just need to hit one button to make it all reload.

Player Animation

The game now supports morph target animation so this month I built a player that allows us to load a range of animations and control how they are played back and tweened. Tweening blends two animations together, this is how you smoothly get from walking to jumping.

Ghost Hack Battle Enhancements

I've also been adding some more advanced features to battle mode character development. Your avatars will grow in skill based on their actions while fighting, but the player will also win "upgrades" which he can use to increase abilities like attack and defence and therefore customize his characters to his own preference.

Another layer of strategy is provided by special attacks which must be charged up before they can be used. Each character has unique special attacks which are very powerful but take a long time to charge. You can only do one at once so you could get all your avatars fully charged before a particularly difficult hack or just get lucky when things look bleak and pull off a signature move to save the day.


Last edited by Poo Bear on Sun Jul 10, 2005 3:58 pm; edited 4 times in total
Back to top
View user's profile Visit poster's website
Goober
Pod Team
Pod Team


Joined: 11 Oct 2002
Posts: 449
Location: Moonpod Central



PostPosted: Fri Jul 08, 2005 11:51 pm    Post subject: Reply with quote

Clumps

Previously the room rendering just worked its way through all the objects in the room, found out what model they wanted to use to render (if any) and created an instance of that model for them to use. This is ok for smaller rooms, but once rooms get to any decent size, and contain a large number of blocks, rendering time increases to a point where it's just not going to work out on lower end hardware. This isn't an issue with polygon counts or shader complexity, just a simple fact that we're calling the rendering API's draw function lots of times per frame, which is pretty inefficient. In some cases you just have to do that, and there's nothing you can do about it (like if different models have different shaders or textures), but a lot of the rooms use a small set of models instantiated lots of times, this is where clumping comes in useful. Essentially what you do is instead of creating lots of individual mesh instances, you create one big vertex buffer and pre-instance the model you want into this big vertex buffer. Then when you want to render you just fire the big vertex buffer at the rendering API and it has a decent amount of work to do per draw call, so you amortize the overhead of the draw call itself across a number of models. This is all in now and works automatically, aside from us having to tag which objects are allowed to clump and which aren't, and has worked out to be a good win in terms of rendering time per frame, to the extent that the debug version (at least on our development PCs) runs at intended frame rate again, with some headroom, rather than looking like the main character is moving through treacle. This bodes well for the game running well on lower spec configurations.

Cornwall

I went on holiday for a week, to a place in Cornwall called St Ives. It's a really nice place, clean beaches, clean sea, and lots of good places to eat. Thankfully the weather was pretty much the best week it's been all year, it was a bit grufty before the holiday week, and it was quite bad afterwards, so I feel pretty smug Smile. However, be warned that the Atlantic is cold, even though it might be blazing sunshine on the beach, the water has some sort of built in cooling system.

Animated Meshes

As you can see in Fost's update, animated meshes are in and working. My part of the work has been done for a while, but it's only when systems start to get used in earnest do you see obvious cases where things can be improved. In this case it was just simply making them easier to use from the game code point of view, and making any loading errors more obvious to the user (so Fost can see what might be wrong when loading a new file).

Particle System

Next up, and taking longer than I had hoped, is a simple particle system for effects and such. I have a basic system working, but it needs more flexibility to be really useful. Hopefully it'll be at a state where it's usable by Fost and Poo Bear, and at that point we'll have more idea of what other features might be required for it to be useful in the final, shippable game.


Last edited by Goober on Fri Jul 08, 2005 9:23 am; edited 2 times in total
Back to top
View user's profile
Hamish
Pod Developer
Pod Developer


Joined: 15 Mar 2005
Posts: 570
Location: Auckland, NZ



PostPosted: Mon Jul 11, 2005 6:26 am    Post subject: Reply with quote

What did you render that walking animation in? It looks amazing, like a movie
Back to top
View user's profile MSN Messenger
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Mon Jul 11, 2005 9:18 am    Post subject: Reply with quote

Thanks Smile Allthough it's not doing anything particularly clever - just lots of work on individual lighting options.

I only noticed the yafray (yet another free renderer) options in wings a few months back, but it is pretty well supported. Funnily enough, the hardest bit of that was assembling it as an animation - it used many copies of the same file, and getting the camera to track right involved working it out beforehand on bits of paper with basic maths and then typing the coords directly into the Yafray xml file that wings spits out.

Note - getting Yafray to work with wings in the first place can be a bit of a nightmare (make sure the path to it has no long file name Shocked) but I found this great tutorial.

Wings also has plugins for renderman and povray but I've never tried them. Blender apparently has even better Yafray integration. I really must have a go of blender, I hear it's very good if you can get yourself past the interface.


Last edited by Fost on Mon Jul 11, 2005 8:09 pm; edited 2 times in total
Back to top
View user's profile Visit poster's website
Weeble
Starscape Jedi
Starscape Jedi


Joined: 25 Apr 2003
Posts: 1143
Location: Glasgow, Scotland



PostPosted: Mon Jul 11, 2005 10:31 am    Post subject: Reply with quote

Are the user interface components, particularly the battle ones, scripted in Lua or whatnot too? I've been really impressed with how easy it is to poke about with the World of Warcraft UI, and some people have done some wonderful things with it. In case you're not familiar, XML files describe the visual components and call Lua scripts to respond to events. While it is probably much harder to first implement, it looks like it must save so much time in the tweaking stages. Of course, my ulterior motive is that I want to get to poke about with the UI. Very Happy
Back to top
View user's profile Visit poster's website MSN Messenger
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Mon Jul 11, 2005 10:47 am    Post subject: Reply with quote

No the front end is setup based on a collection of simple initialization text files, one for each screen plus any popups.
Back to top
View user's profile Visit poster's website
HunterXI



Joined: 26 Dec 2003
Posts: 476
Location: Playing like there is no tomorrow.



PostPosted: Mon Jul 11, 2005 11:40 pm    Post subject: Reply with quote

Goober wrote:
I went on holiday for a week, to a place in Cornwall called St Ives.


"Isn't there a 'St. Arghs' in Cornwall?"
"No, that's 'St. Ives'."

Smile
Back to top
View user's profile
Kajamakuji



Joined: 17 Feb 2005
Posts: 11
Location: Canada



PostPosted: Tue Jul 12, 2005 9:22 pm    Post subject: Reply with quote

Wow, Crazy good work on the animation. It looks so smooth.
Back to top
View user's profile
Weeble
Starscape Jedi
Starscape Jedi


Joined: 25 Apr 2003
Posts: 1143
Location: Glasgow, Scotland



PostPosted: Tue Aug 02, 2005 11:07 am    Post subject: Reply with quote

Weeble wrote:
Are the user interface components, particularly the battle ones, scripted in Lua or whatnot too? I've been really impressed with how easy it is to poke about with the World of Warcraft UI, and some people have done some wonderful things with it. In case you're not familiar, XML files describe the visual components and call Lua scripts to respond to events. While it is probably much harder to first implement, it looks like it must save so much time in the tweaking stages. Of course, my ulterior motive is that I want to get to poke about with the UI. :D

Oops, forgot that Goober had already talked about Lua.
Back to top
View user's profile Visit poster's website MSN Messenger
Sonic TH



Joined: 08 Aug 2005
Posts: 1
Location: USA



PostPosted: Mon Aug 08, 2005 1:44 pm    Post subject: Reply with quote

Just a quick note about blender, I just started using it a few days ago and so far it's awesome. The guide you can get of their site (or buy in book form) explains the interface pretty good so far. But the animation part of it is way easy compared to the other 3D apps i've used.

If you get a chance you should make time to check it out, it's worth it.
Back to top
View user's profile
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Tue Aug 09, 2005 11:24 am    Post subject: Reply with quote

Yes, I'm more a fan of blender than I am of milkshape, just because it seemed easier to get into for somone like myself with my own personal history of using 3D apps and what I'm comfortable with. Although every time I look at either of them they both seem to have come along huge leaps.
Back to top
View user's profile Visit poster's website
happymonster



Joined: 03 Sep 2005
Posts: 38
Location: Nottingham, UK



PostPosted: Sat Sep 03, 2005 9:13 am    Post subject: Reply with quote

Can I just ask if we are likely to see the July development news soon? Has something happened to cause the delay?

Thanks.
Back to top
View user's profile Visit poster's website
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Sat Sep 03, 2005 10:37 pm    Post subject: Reply with quote

We've decided to merge July and August into one diary which we hope to get written up soon. Sadly, there were a lot of website pains during July that caused a delay (which I'll be talking about in the boring 'busniess' bit that nobody reads Wink ), so we didn't feel there was enough time or new content to talk about.

Hamish has written up a diary entry for his project too this month - which I think will be an interesting read for everyone. should have something within the week Smile
Back to top
View user's profile Visit poster's website
happymonster



Joined: 03 Sep 2005
Posts: 38
Location: Nottingham, UK



PostPosted: Thu Sep 15, 2005 6:16 pm    Post subject: Reply with quote

Hate to be a pain, but as a fellow developer I look forward to reading your progress reports. As such I'm feeling a bit impatient. Smile
Back to top
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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


Powered by phpBB © 2001, 2005 phpBB Group