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
August-04: Networking and Scripting
Goto page 1, 2, 3, 4, 5  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
Poo Bear
Pod Team
Pod Team


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



PostPosted: Mon Aug 16, 2004 11:54 am    Post subject: August-04: Networking and Scripting Reply with quote

I'll explain some of the details from the two main game systems I have been working on this month.

The orders system

Getting hundreds of units organised on the battlefield is extremely complex and is the cause of many ongoing headaches. At the top of the pile you have the player (or AI ) dishing out orders to one or many squad commanders. The player can also queue up lots of orders all at once, so he can select a bunch of squads, tell them to move here, dismount from your APCs, attack this target, move back to safety, etc.

The squad commander then ensures his units stay together and get the job done. The individual units then do as they are told, working out a decent path around obstacles and getting out of each others way. So a simple order to move somewhere from the player can cause a cascade of orders lower down the chain as soldiers mount up into APC's, negotiate obstacles and generally get in each others way.

This is all implemented using order stacks, each squad commander and each unit have an input order stack that can have a number of tasks to be completed in sequence. If there is an emergency (like being attacked) then a new order can be inserted into the top of the stack. This means once the emergency is over and the order is removed the units can revert to following their old orders (they remember what they were doing before).

They also have a single output order stack which lets them give one order to any number of other units or squads. So if a soldier needs to order someone else out of his way he can do it. This gives individual units a small amount of autonomy.

The player can also control the default behavior of squads when they don't have any orders, this is fairly standard in most RTS's. It is something often ignored or misunderstood by new players though and yet it can make all the difference between valiantly defending a strategically important location or trundling off into the midst of the enemy to be slaughtered.

Movement - hold your position, stay close to your position, go wherever you like.

Firing - hold your fire, return fire if attacked, fire at whatever you want.

Another easy mistake to make is to set your units to move where they want, fire when they want and then just order them to cross the map through the enemy. Half the audience will expect them to stop when they hit trouble and try to deal with it before carrying on. The other half will specifically want them to get where they are going and definitely not stop. The latter solution is simple and obeys the directions of the player, if he says go somewhere then you better damn well go. The key point is these standing orders only apply when a unit has NOT been ordered to do something. Obviously units will fire as they pass but they shouldn't stop. People can find this behavior surprising at first, but if you understand what is going on then you can start to use it. There is just no way for units to understand what the player really wants so the best/easiest option is just to obey the letter of his orders.


The orders and status panel in game.

The squad status system

Units have various stats related to cost, attack power and defence rating, etc and these are important when selecting your army. If they never changed then it would be difficult to encourage different battle strategies, you might as well select all your units and just charge the enemy. So instead there are three important squad indicators that can be used to give the player an advantage in combat:

Combat Power
    The more experienced the squad the more effective their weapons and armour.
    If you are attacking up hill you are at a disadvantage and combat power drops.
    If you are attacking downhill you have the advantage and combat power rises.
    If there is a friendly squad attacking your target from a different angle then you have him in a crossfire and combat power rises.


Morale
    If your squad is badly damaged then morale falls.
    If you are near other friendly squads then morale rises.
    If you are veterans or there is a leader nearby then morale rises.
    If your transport is killed morale falls hard.
    If you are on a killing spree then morale rises.
    If you are hit by a weapon with longer range than your own morale falls.
    If you are in combat for a long time morale falls, but rises again once combat ends



Cover
    If you are infantry near friendly armoured vehicles you gain a cover bonus.
    Cover is split between "Light" such as rocks and bushes and "heavy" such as trees.
    Units in cover take less damage from incoming fire.
    Units in cover move more slowly.
    Units in shadow receive a cover bonus.


So in theory strategies should emerge that allow a player to defeat a numerically superior army:
    Stay in cover if possible.
    Use artillery to soften up the enemy before an assault, you probably wont kill very many but overall morale should fall.
    Take positions up hill and keep them.
    Try to attack from two sides at once.
    Pull out if casualties are heavy, if you can bring squads back together you can regain some lost morale.



The selected tanks morale is very high, they have made a lot of kills, they are healthy and are well backed up.


The selected tanks are in for a rough time, their combat power is down due to the uphill fight.
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: Wed Aug 18, 2004 5:09 pm    Post subject: Reply with quote

First off, I'll apologise for the boring screenshots. Fost was nagging me saying "you need to put screenshots in to make it more interesting, people like pictures". Little did he realise just how boring network test applications could be. This Dev Diary, in all it's yawn inducing boringness, is dedicated to Fost.

Recently I've been working on networking code, with the intention of building a simple (both in use and implementation), fast and reusable library that we can drop in to a project quickly and easily. Because I wanted it to be suitable for a range of applications I decided early on to base the system on UDP and implement an ordered reliable delivery mechanism on top.

Essentially what happens is that when messages are sent they get stored in a buffer, until such time as the remote computer acknowledges it received the message. If the message isn't acknowledged within a specific time, or an acknowledgement is received for a later message, then the message is (and subsequent messages are) resent. At the receiving end the network layer only accepts new messages, but always acknowledges that it received a message. With this we can ensure the packets arrive and that they arrive in-order (remember, UDP packets can legally arrive out of order). Don't worry if that doesn't make sense, thinking on two computers at once, in multiple threads, is an acquired skill (that I have yet to acquire Wink)

As well as this madness, the network layer also attempts to keep track of how much bandwidth it's using. At startup the calling application can let the network layer know how much bandwidth to use, and it'll stick to that (give or take a few bytes). Handy for not saturating a dial-up connection. There are also a bunch of statistics that the network layer keeps track of and makes available to the application, mainly for debugging purposes although they could be exposed to the user to facilitate problem solving; number of packets resent, ping times, bandwidth used per update, that sort of thing.

Finally, we have unreliable messages. There are instances where you might want to fire some data off, but it doesn't really matter if it gets there or not, it was just a courtesy thing anyway. In this case you can pass unreliable messages to the network layer. If there is bandwidth available then the network layer will fire them off along with the reliable messages. They don't require acknowledgement, and they don't get stored or resent under any circumstance.

And using all that, I built a real simple chat client to test it out. Nothing flash, the server is a console application which just allows clients to connect, and echoes messages sent to it back to all connected clients. The chat client is an MFC app which allows you to connect to the server and send messages. That's pretty much it, but it was a big help when testing the reliable delivery mechanism. I built into the network layer a way of simulating packet loss (all it does is when it gets a packet, it generates a random number, if the random number is in a certain range then the packet is thrown away) so I can see how well this all works without needing a really crummy internet connection Smile. The whole thing is going to need a decent amount of real net testing, but this is useful for demonstrating that even over a very bad link (something like 70% packet loss) the network layer is able to maintain a connection. I just hope that no-one in the real world has to put up with a connection that bad! Wink

------------------------------------------------------------------------------------------------------------------
Connecting to a server! Oh! The anticipation!


------------------------------------------------------------------------------------------------------------------
Sending a message to the server! It's like some sort of MMORPG! I bet the Everquest 2 team are worried now.


------------------------------------------------------------------------------------------------------------------
The server! Gasp in awe!


------------------------------------------------------------------------------------------------------------------
Besides the network system, I've also gotten a simple script language working. Currently it's only the virtual machine and a simple form of assembly language, next up will be a high level language that compiles to the VM bytecode. Why implement my own script language instead of using Python/Lua/Ruby/<insert your favourite script language here>? A number of reasons, mainly to do with the speed I could implement something versus how long it would take hacking around with someone else's code. My intention is to use the script language in a number of places including the GUI system, the shader system and as a generic in-game script system. Because of this I wanted an easy way to extend the functionality of the language (mainly to support calling back to native code, and also to support vectors, matrices and quaternions as intrinsic types), and also to be able to put script language code directly into other scripts we have, such as GUI definition files. Other languages looked to be a pain to hack in that respect (i.e. the lexical analyser), so I jumped straight in with my own. Also, I found that most script languages implement too much, which sounds odd, but I'm not comfortable with a script handling such things as memory allocation and whatnot. For our purposes I see a script language as performing some simple logic, and anything more complex being handled by native code. This doesn't mean that the script isn't powerful, it already is, but just that thought should be put into where the majority of work gets done.
Back to top
View user's profile
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Wed Aug 18, 2004 5:37 pm    Post subject: Reply with quote

Last month I broke one of the golden rules of game development: never, under any circumstances, promise you will do anything. Very Happy and sadly this month I don't have any animations for the Talos ready to show as I said I would.

Instead, here's a few shots of the final textured Talos walking tank and some of its equipment options.


Dropped a Cerberus tank and trooper in there as a scale reference, although sizes are by no means final - we really need to see how it interacts with everything else in the game before making a decision.

I've pretty much got an inexaustible supply (although suggestions are welcome as always Very Happy ) of equipment ideas for the Talos.
Currently I'm working on a backpack, and a laser spotter (untextured in blue below):



I've also become interested in various texturing tricks that use optical illusions to make the viewer think there are more polygons in a model than there actually are, and I've tried a few of the out on the Talos. The following image might be quite difficult to follow, and I'm not sure I've fully achieved the effect I was going for, but it's an intriguing technique:


For the rest of this month I've been getting on with more Battlescape work (nothing to show yet - more news as and when it's ready - as usual you'll be the first to know.) and I've also made a few additions to Starscape although they require work from a programmer so it's unlikely you'll see them until Battlescape is released. Should mean there'll be some nice updates for everyone round about that time though.

Lastly, I'd just like to say how impressed I've been with what wings3d is now capable of doing and the effort that has been put into it. Once Battlescape is finished I'd really like to write up some tutorials for it.
Back to top
View user's profile Visit poster's website
icarus
Troll
Troll


Joined: 01 Mar 2004

Location: Olympia Washington



PostPosted: Wed Aug 18, 2004 6:30 pm    Post subject: Reply with quote

Wow! pretty screenshots,
but the Talos is way to big, no mech should be taller than 20ft/6.5m (the wanzers in FM1 wer only about 15f tall) any bigger and the humanoid shape makes the target silhouette too large
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: Wed Aug 18, 2004 7:39 pm    Post subject: Reply with quote

Have you seen Metal Gear Rex? That thing must have been about 50 feet tall. And I think Metal Gear Ray was even bigger. Size of silhouette is relatively unimportant when it can nuke you, your family, your neighbours and your country into oblivion before you even cross the horizon. :D
Back to top
View user's profile Visit poster's website MSN Messenger
limulus



Joined: 05 Aug 2004
Posts: 14



PostPosted: Wed Aug 18, 2004 8:05 pm    Post subject: Just wondering... Reply with quote

Fost, I was just wondering how long exactly does it take you to do these things? I am no artist and I really have no idea but do you require a whole month to create one model for a game and texture it? Or have you created way more than the Talos, Cerberus and Hades and are just keeping it to yourself to not spoil the fun?

It would be really interesting if you could tell me how long it takes you approximately to make a model.
Back to top
View user's profile
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Wed Aug 18, 2004 8:13 pm    Post subject: Reply with quote

icarus wrote:
the Talos is way to big

I did mention that the current scale was undecided in the diary and it may become smaller; we really want to check how the various units interact on the battlefield before deciding the size. There's also some quite practical reasons where smaller would make sense: it would be too cpu intensive to have an IK system for each mech, so we want to avoid the kind of situation where one of its feet overhangs a cliff as much as we can, and this is less likely with smaller mechs.

Currently, they come in at just under 12 meters. I actually built them round the body compartment - which is sized to comfortably fit a standing man (seemed like a sensible way to go about the design), but there's a lot of leeway in the design should we decide to shrink them a bit.

I don't have a major problem with them being the size they are right now though - if one could construct such a machine, what would be it's advantage? Do these assumptions sound reasonable?:

*It would present a pretty easy target.
*It would not be as well armoured as a tank as it would need to be lighter.

So, I'm thinking its major advantage is manouverabilty, especially in urban environments. After that you have a slight height advantage, presumably some immunity to most morale issues, and the ability to enter close combat. This is the kind of way we are trying to think about the Talos when we set up its cover modifiers and attack bonuses/penalties.
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: Wed Aug 18, 2004 8:29 pm    Post subject: Reply with quote

Do you have some degree of normal-tweaking to make edges look smoother? Some of them look smooth and rounded while others look quite jagged. How costly is it to have interpolated virtual normals across your surfaces as opposed to simple flat shading? And if it does make a difference, is it something that can be tweaked by level-of-detail mapping? (I'm not sure I've got the right term, I mean the one that's like mip-mapping but for complexity of models in general, not just resolution of textures.) I'm afraid I know lots of scraps of theory, but next to nothing about the real practicalities.

Also, is my monitor gamma all screwed up, or are those pictures very washed out? Everything looks very pale.
Back to top
View user's profile Visit poster's website MSN Messenger
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Wed Aug 18, 2004 8:32 pm    Post subject: Re: Just wondering... Reply with quote

limulus wrote:
Fost, I was just wondering how long exactly does it take you to do these things? I am no artist and I really have no idea but do you require a whole month to create one model for a game and texture it? Or have you created way more than the Talos, Cerberus and Hades and are just keeping it to yourself to not spoil the fun?


Ha! - No, I wish I had more to show Very Happy . The main reason things have turned up slowly in the past month is that I've been doing a lot of work to streamline our website operations. That said, I am a pretty slow artist. If I was working 100% of the time, it would not be unreasonable for me to design, and model the Talos, UV map it and and texture it, create and texture all its weapons, and do all the animations within a month. This is pretty much what happened with the Hades, although even then there was a lot of business related distraction.

Although I do tend to compare this to people I know in the game industry who could probably do the above in a week - they tend to be working from a design someone else has done. I tend to design on the fly- which isn't the fastest way to work, but is the only way that I can ever seem to get results I'm happy with.
Back to top
View user's profile Visit poster's website
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Wed Aug 18, 2004 9:00 pm    Post subject: Reply with quote

Weeble wrote:
Do you have some degree of normal-tweaking to make edges look smoother? Some of them look smooth and rounded while others look quite jagged. How costly is it to have interpolated virtual normals across your surfaces as opposed to simple flat shading?

Those aren't finalised as far as vertex shading goes, but to answer your question - flat shading would be the worst thing to do in this case. To make a break in the normals you end up splitting the mesh on export, and having more than one vertex at the same location but with different normals. These days, vertex count is more important than poly count - especially for an object like this which will be realtime deformed (we are using framed mesh animations for efficiency, rather than a separate, hierarchically linked model skeleton.) and so cpu time is spent on each vertex in the mesh. The same goes for UVs - I try to seamlessly map as much of the emsh as possible - even at the expense of texture space if required. Of course there are bound to be breaks, so if I want them, I tend to match up the smoothing changes to places where there are already UV breaks.
Weeble wrote:
And if it does make a difference, is it something that can be tweaked by level-of-detail mapping? (I'm not sure I've got the right term, I mean the one that's like mip-mapping but for complexity of models in general, not just resolution of textures.) I'm afraid I know lots of scraps of theory, but next to nothing about the real practicalities.

I think you might be talking about LODs? (Level Of Detail) where you swap in different models as you get closer (or dynamically reduce the vertex count as the model moves into the distance). This isn't so much the silver bullet it once was (Goober can probably give you a techier reason and explain the current state of play with current gfx cards and efficient rendering), and with Battlescape, the range of zoom isn't so bad, so I suspect we won't need to do it.
Weeble wrote:
Also, is my monitor gamma all screwed up, or are those pictures very washed out? Everything looks very pale.

Very Happy I tend to light production shots so that it's visible on the two programmer's monitors, which always seem to be at the bottom end of the gamma spectrum (Then again, they are staring at text all day, so it helps save their eyes!).Tthose shots are a bit on the bright side though, the game of course, is adjustable Very Happy
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: Wed Aug 18, 2004 11:02 pm    Post subject: Reply with quote

Weeble wrote:
Do you have some degree of normal-tweaking to make edges look smoother? Some of them look smooth and rounded while others look quite jagged. How costly is it to have interpolated virtual normals across your surfaces as opposed to simple flat shading?


As Fost explained, flat shading is more expensive (in terms of per-vertex work) than Gouraud shading. Although I should point out the difference between flat shading, Gouraud shading and Phong shading, just in case anyone is confused:

Flat shading is where you light each face according to how it faces the light source (or not). The lighting value is constant across the face. With modern APIs and hardware this actually involves replicating the lighting calculation 3 times (per vertex) per face unless you're willing to write you're own lighting code and do a lot of nasty fiddling about (which I'm not Wink).

Gouraud shading is where you calculate a lighting value per vertex and interpolate the resulting light level values (i.e. a color) across the face. Because faces share vertices you only need to calculate the lighting value once. The downside to Gouraud shading is that you have a large polygon and a light shining on the middle of it, you don't get the correct lighting response.

Phong shading is where you interpolate the surface normal across the face, and calculate the lighting at a more refined level (per pixel perhaps). What you're seeing with stuff like Doom3 and Far Cry etc is essentially this, but with the normal being provided by a texture map rather than just being interpolated, so you can get more detail in the lighting.

Weeble wrote:
And if it does make a difference, is it something that can be tweaked by level-of-detail mapping? (I'm not sure I've got the right term, I mean the one that's like mip-mapping but for complexity of models in general, not just resolution of textures.) I'm afraid I know lots of scraps of theory, but next to nothing about the real practicalities.


Level of detail can be useful, but it all depends on your application, and your method of LoD. CPU intensive LoD methods have fallen a little out of favour recently because of the huge amount of vertex throughput of the newer graphics cards, there's just no reason to perform LoD a lot of the time, you're just tying up the CPU and using slow paths to get the vertices to the graphics cards. This is even more apparent when you're using complex surface shaders, such as per-pixel lighting and such, because the bottle-neck in the GPU is actually in the rasterization, not the vertex transform, so spending more vertices doesn't cost you more rendering time. Having said all that, when you need to fall back to rendering on hardware such as a TNT2/Rage128/Voodoo3 (as we do Sad), then it's worth considering methods where you can quickly and trivially reduce vertex counts. View independant progressive meshes can be very good, especially when implemented using the sliding window indices method. For Battlescape there probably won't be a LoD system in place, so Fost is building all the models to work well on lower spec hardware. For newer graphics cards we'll likely turn on nice effects in the shaders, maybe add more particle effects, that sort of thing. Those changes don't require extra assets, and therefore don't require Fost to do a lot more work (he has quite enough to do as it is!)

Fost wrote:
Weeble wrote:
Also, is my monitor gamma all screwed up, or are those pictures very washed out? Everything looks very pale.

Very Happy I tend to light production shots so that it's visible on the two programmer's monitors, which always seem to be at the bottom end of the gamma spectrum (Then again, they are staring at text all day, so it helps save their eyes!).Tthose shots are a bit on the bright side though, the game of course, is adjustable Very Happy


My gamma got turned up briefly while I was playing Doom3 (or I just couldn't see a damn thing and was left wondering why my health was going down when there was just darkness all around), but it's back to being nice and dark again now Smile.
Back to top
View user's profile
BluePhoenix



Joined: 08 Jun 2004
Posts: 96
Location: Between Georgia and Cuba



PostPosted: Wed Aug 18, 2004 11:35 pm    Post subject: Reply with quote

Fost wrote:
So, I'm thinking its major advantage is manouverabilty, especially in urban environments. After that you have a slight height advantage, presumably some immunity to most morale issues, and the ability to enter close combat. This is the kind of way we are trying to think about the Talos when we set up its cover modifiers and attack bonuses/penalties.


You forgot to mention: can step on people and light machinery and instantly destroy it. Very Happy

And I like the Command system, Poo Bear. I can't tell you how many times I'll be playing an rts and wishing for a "hold fire" button. Looks simple, yet very versital
Back to top
View user's profile AIM Address Yahoo Messenger
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Wed Aug 18, 2004 11:52 pm    Post subject: Reply with quote

BluePhoenix wrote:
You forgot to mention: can step on people and light machinery and instantly destroy it. Very Happy

Very Happy We were discussing just that today, but came to the disturbing conclusion that the ultimate anti-infantry weapon would be a mech containing Michael Flatly (That oily looking guy who does the River Dance)
Back to top
View user's profile Visit poster's website
Darth Dallas



Joined: 18 Oct 2003
Posts: 411



PostPosted: Thu Aug 19, 2004 10:47 pm    Post subject: Reply with quote

So when your talking close quarters fighting, are you talking about if both sides' mechs ran out of ammo (assuming nothing but mechs were used), they'll start to duke it out Rock'em Sock'em Robot style? Smile

*BAM*

"Wow! Did you see that?! That head came clean off."

"Yea, but that one over there is trying to bite the other one's ear off..."

Smile
Back to top
View user's profile
01d55



Joined: 12 Mar 2004
Posts: 79



PostPosted: Sun Aug 22, 2004 5:24 am    Post subject: Reply with quote

Fost wrote:
BluePhoenix wrote:
You forgot to mention: can step on people and light machinery and instantly destroy it. Very Happy

Very Happy We were discussing just that today, but came to the disturbing conclusion that the ultimate anti-infantry weapon would be a mech containing Michael Flatly (That oily looking guy who does the River Dance)


If you really want to push the stomping envelope, put a flat mesh on the end of a wrecking-ball arm and rig it on one of those big tanks. Jus' roll up and drop the flat. (The mesh is so that you don't lose all your potential energy dislocating air, like a flyswatter.) Not as effective against light armor, however.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary All times are GMT
Goto page 1, 2, 3, 4, 5  Next
Page 1 of 5

 
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