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 Previous  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
HunterXI



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



PostPosted: Wed Sep 08, 2004 12:32 am    Post subject: Reply with quote

Goober wrote:
I haven't the foggiest idea what you're talking about there. It sounds like you're mixing up a whole bunch of completely unrelated things and ending up with a bucket of monkeys.


Forgive me, I can be like that. Scripting in mIRC is just a tiny bit like Dos. "Commands" in the scripting language are actually just bits of code in
the main executable file that call other programs; in DOS, typing a command actually is typing a filename (or, if you're Making a Batch file, multiple), thus calling up the program. My thought was that maybe it was possible to make a trigger system based off the same cconcept; of making a bunch of executables (or functions, respectively) that worked similarly to Batch. My other thought was that one could also make this system work very efficiently by actually compiling these commands (well, their code/functions, anyway) into a single file. It was a random thought. I thought said system could be good because:

1. It would be highly customizable
2. It could be extremely easy to learn and use
3. It could be quite efficient
4. It wouldn't take long to implement (Ok, I'm not actually sure on that one).

But yeah. Hope I made my somewhat-moot point a bit more clearer Smile
Back to top
View user's profile
Goober
Pod Team
Pod Team


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



PostPosted: Wed Sep 08, 2004 11:39 am    Post subject: Reply with quote

Ah, I see what you're saying now. I guess this would be kind of useful, but it does rely on having those pre-built instructions for everything. With the script system you get to be able to do stuff that you otherwise couldn't do, such as looping/branching and such.

Regarding "compiling these commands into a single file", I don't really see the benefit there versus calling these chunks of code when necessary. Actually linking already compiled functions into a single cohesive block could be problematic (especially if we moved to a newer/different compiler or a different calling convention).

I'm also dubious about the "highly customizable" aspect of it. Mainly because it's less flexible than a language supporting more complex structures. Whereas this system requires a "command" for everything you want to do, a fully featured language could support just having the function written in that language. Admittedly, a script language will definitely want support from native code functions so that as little runs in script as possible, but at least it offers the possibility for doing things a little outside the scope of all the pre-built blocks.

For a simple fetch->call system, you are right that would be pretty quick to implement, but then there's all the time spent implementing all the functional blocks that are required. With a language, if you need a short function to do something specific then you can, if you want, implement it using the script language. If the function becomes a bottleneck (or just if it ends up being used a lot) then you can reimplement it in native code and redirect those calls to the new, native-code version instead later on.

Funnily enough, pretty much the system you're talking about was used in Gun Metal. Essentially there were a set of logic blocks that could be placed in the editor and linked together to get stuff to happen. It worked quite well but, IMO, it was restrictive and it took longer to build stuff in that than it would have taken to write a script for in many instances.
Back to top
View user's profile
Weeble
Starscape Jedi
Starscape Jedi


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



PostPosted: Thu Sep 09, 2004 12:26 am    Post subject: Reply with quote

I see the point in having a scripting language, but why a new scripting language? If you consider Python, it provides some very powerful high-level concepts. It is designed to be easily integrated with other code. Do you simply need more raw power? Python (at least, without experimental projects) isn't going to compare with C for performance, but presumeably you're not going to be doing your serious number-crunching in the scripting language. I am not aware of any licensing problems in using Python. I believe the same is true of Lua. Python was used for scripting in The Temple of Elemental Evil, and that link goes to a discussion of the choice of Python.
Back to top
View user's profile Visit poster's website MSN Messenger
r000000b
Starscape Jedi
Starscape Jedi


Joined: 10 Jan 2004
Posts: 63
Location: Staffordshire



PostPosted: Thu Sep 09, 2004 6:06 am    Post subject: Reply with quote

Python is great, and if you need to do big number crunching numarray does most of its work in C, so for big enough arrays you get comparable to C speeds. Scipy uses numarrays to do big hard processing. Plus if you write it in python it takes half the time to write and has half the bugs.

Its relatively easy to write everything in pure python, profile it and move bottlenecks to C. Iím not sure about C++ tho, and thatís what you guys are using isnít it? It also sounds like python might be too fat and adding the needed features too difficult.

I think the real reason Goobers writing his own scripting language is because its fun, he always wanted to, I would write all of battlescape in python tho Wink

Weeble, have you looked at pyrex?
Back to top
View user's profile
cryogen01



Joined: 09 Sep 2004
Posts: 1



PostPosted: Thu Sep 09, 2004 4:21 pm    Post subject: Why a scripting language Reply with quote

Back to top
View user's profile MSN Messenger
BluePhoenix



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



PostPosted: Tue Sep 14, 2004 2:49 pm    Post subject: Reply with quote

Goober wrote:
With a language, if you need a short function to do something specific then you can, if you want, implement it using the script language. If the function becomes a bottleneck (or just if it ends up being used a lot) then you can reimplement it in native code and redirect those calls to the new, native-code version instead later on.

si, what you are saying is that if scripting language is used in some sort of level editor, then we (the user) will be able to also use C or C++ in our script?
Back to top
View user's profile AIM Address Yahoo Messenger
Weeble
Starscape Jedi
Starscape Jedi


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



PostPosted: Tue Sep 14, 2004 6:36 pm    Post subject: Reply with quote

BluePhoenix wrote:
Goober wrote:
With a language, if you need a short function to do something specific then you can, if you want, implement it using the script language. If the function becomes a bottleneck (or just if it ends up being used a lot) then you can reimplement it in native code and redirect those calls to the new, native-code version instead later on.

si, what you are saying is that if scripting language is used in some sort of level editor, then we (the user) will be able to also use C or C++ in our script?

I'm pretty sure that Goober is talking about development. Any time a function in a script becomes a bottleneck (it is used enough and does enough work that it slows down the game) the developer can hard-code it straight into the script engine, which is written in native code (presumably C++ here). I don't think he means that you can put native code in a script.
Back to top
View user's profile Visit poster's website MSN Messenger
Goober
Pod Team
Pod Team


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



PostPosted: Wed Sep 15, 2004 4:44 am    Post subject: Reply with quote

Weeble wrote:
I'm pretty sure that Goober is talking about development. Any time a function in a script becomes a bottleneck (it is used enough and does enough work that it slows down the game) the developer can hard-code it straight into the script engine, which is written in native code (presumably C++ here). I don't think he means that you can put native code in a script.


Absolutely correct. I couldn't have put it better myself. In fact, I think I didn't put it as good. Or something. Anyway, cheers. Smile
Back to top
View user's profile
jollyreaper



Joined: 20 Jun 2003
Posts: 181



PostPosted: Sat Sep 18, 2004 9:07 pm    Post subject: Reply with quote

I really like the mech designs. It looks functional yet also cool. The textures look quite nice. If that same sort of look is maintained across all of the human units, I think we're in for quite the spiffy-looking army.

As for the proper size of mecha, it all depends on your story universe. With realistic technology, mecha simply don't make sense. It's always easier to armor a box than a humanoid form so tanks will always be cheaper than mechs. When you also consider that the basic purpose of a weapons system is to marry a) a weapon to b) a vehicle, the simplest way to accomplish that goal is always the most effective. If the best weapon on the battlefield is a 105mm cannon, a mech carrying such a weapon would be more expensive and more vulnerable than a tank similarly equipped, but it would still have the same hitting power. When talking modern technology, we still don't have anything close to the tech to consider building a mech, regardless of practicality.

In a more sci-fi scenario, you can make the future tech make your mech make sense. In the anime Evangelion, the director wanted to have monsters and robots on a Godzilla-scale fighting it out in a city, hand to hand. That at first sounds absurd. The way he was able to make it work, the alien monsters use an AT field as a defense system, a super-shield impervious to human weapons. The only thing that can counter an AT field is another AT field. A vehicle capable of carrying an AT field would be huge, and you are left creating a robot to carry it. Once the field is neutralized, the enemy can be engaged hand-to-hand and destroyed.

Realistically, any mobility advantage conferred upon the mech by being humanoid and able to walk would be cancelled out by it's conspicuous nature, standing over the battlefield. It would likely be a missle magnet ... unless there's a nicely though out explanation for how this could be countered. In a modern-day example, the guided missile is the biggest threat a tank faces, the main gun on enemy tanks being a distant second. Aircraft can hunt down and destroy enemy tanks long before they have a chance to directly engage friendly tanks. Infantry also has powerful anti-tank missiles. Now if a decent anti-missile laser is developed in the near future, a tank could confidently expect to defeat a large percentage of incoming missiles. That means the best way of killing a tank has gone back to getting a cannon in place to engage it.

So long as the technology used in the game is self-consistant and makes sense, Moonpod could get away with just about anything. Smile
Back to top
View user's profile
Harabek



Joined: 10 Apr 2004
Posts: 94
Location: Arkansas, yes we have computers.



PostPosted: Sat Sep 25, 2004 10:05 am    Post subject: Reply with quote

What ever happened to a Sept. dev. diary?
Back to top
View user's profile
Poo Bear
Pod Team
Pod Team


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



PostPosted: Sat Sep 25, 2004 10:25 am    Post subject: Reply with quote

I think there might be a delay in Battlescape updates (for a good reason), more news soon. Wink
Back to top
View user's profile Visit poster's website
Martoon`



Joined: 08 Oct 2004
Posts: 3



PostPosted: Fri Oct 08, 2004 5:29 pm    Post subject: Floating point variance Reply with quote

Goober,

For a networked RTS like this, how do you deal with floating-point variance? The bane of almost every networked game I've worked on is that different CPU's, even from the same manufacturer (e.g. an Athlon 850 vs an Athlon 1000), can get slightly different results from the same floating operations due to differences in their internal storage precision.

So how do you deal with this in Battlescape? You've got entities in a 3D environment, so I'm sure everything is maintained and processed as vectors, quats, and matrices that consist of floats (so you're doing lots of fp operations). You've got large numbers of entities in the world, so presumably you're only sending things like player commands over the network (and not a continuous stream with the position and rotation of every entity in the world). This means that the game world needs to be updated in parallel on all connected machines in a network game, with only independent factors like player commands sent over the network. How do you ensure that these simultaneous world updates result in identical world states on all machines, when the individual machines can get different results from the same floating-point operations?
Back to top
View user's profile
r000000b
Starscape Jedi
Starscape Jedi


Joined: 10 Jan 2004
Posts: 63
Location: Staffordshire



PostPosted: Mon Oct 11, 2004 11:50 am    Post subject: Reply with quote

Quote:
I think there might be a delay in Battlescape updates (for a good reason), more news soon.


go on, give us a hint, what are you up to?
Back to top
View user's profile
Goober
Pod Team
Pod Team


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



PostPosted: Wed Oct 13, 2004 11:37 am    Post subject: Re: Floating point variance Reply with quote

Martoon` wrote:
For a networked RTS like this, how do you deal with floating-point variance?


Currently we don't, we haven't gotten networking into the game yet, but chances are we'll be quantizing all values down to save network bandwidth and so that if there is any fp variance (which there shouldn't be provided the FPU is set up the same across all platforms and they all purport to adhere to IEEE754) it should only be in the very least significant bits and will just be squished out in the quantization.

That's the plan anyway, we'll let you all know how well it works out Smile
Back to top
View user's profile
Martoon`



Joined: 08 Oct 2004
Posts: 3



PostPosted: Wed Oct 13, 2004 4:07 pm    Post subject: Re: Floating point variance Reply with quote

Goober wrote:
Martoon` wrote:
For a networked RTS like this, how do you deal with floating-point variance?


Currently we don't, we haven't gotten networking into the game yet, but chances are we'll be quantizing all values down to save network bandwidth and so that if there is any fp variance (which there shouldn't be provided the FPU is set up the same across all platforms and they all purport to adhere to IEEE754) it should only be in the very least significant bits and will just be squished out in the quantization.

That's the plan anyway, we'll let you all know how well it works out Smile


Unfortunately, quantizing the values sent over the network doesn't solve the problem that I'm referring to. Let me try to clarify what I'm talking about.

Let's say your main game loop updates the entire game world 100 times per second. So in each of these 0.01 second updates, you iterate through all of your entities, and tell each entity that 0.01 seconds has passed and to update itself accordingly. So a tank, for example, might add its velocity to its position, get the terrain height at the new position, and alter its vertical position accordingly (or whatever). Now say you have 200 entities like this in the game, each updating themselves 100 times per second. Obviously, you can't send all of this info over the network. So you have each machine in a network game update all of its own entities independently, and trust that each machine comes up with the same result. After all, they should. They're all running the exact same code, executing the same instructions and starting with the same initial data. You only need to send independant factors, like "This player told this unit to move to this position", and disseminate these commands over the network and make sure they're executed in the same update timeslice on all machines.

Unfortunately, due to floating-point variance, you don't get identical outcomes on all machines during the update loop. Let's say a tank, while modifying its rotation, gets a slightly different result on one machine than on another. Now this tank is on a slightly different heading on the two machines. As the tank continues to travel some distance on both machines, it will end up in different places on the two machines. And it might end up just within attacking range on one machine, and just outside of this range on the other. So the enemy unit gets killed on my machine, but not on yours. This Butterfly Effect continues, and the game gets more and more out of sync.

Quantizing or truncating the values sent over the network doesn't help this, because this is all internal to the updates happening on both machines, and none of this info is sent over the network. Even truncating the result of every FP operation (which would be expensive and a serious PITA) wouldn't guarantee consistency. Let's say machine A got a value of 1.99999999, machine B got 2.00000000, and they truncated to some precision. They'll still have different values (my example was in decimal for ease of illustration; the same principal applies to binary truncation).

And yes, the different CPU's claim IEEE compliance, but I've found they can still get different results. From what I understand (and I'm still researching this), the standard requires a certain minimum number of bits for internal representation of FP values, but not a maximum, and different CPU's have varying numbers of bits beyond the required minimum, which can lead to slightly different results in FP operations.

Sorry for the lengthy rant (I'm sure you're much less interested in this than I am Smile ), but this issue has been a thorn in my side for a couple different titles I've worked on, and I have yet to come up with a solution that isn't ugly and doesn't fail at least some of the time. This must be a solved problem, since there's many RTS's with thousands of networked games being played online, and they seem to stay in sync (and I can't imagine they're all using fixed-point math). I've discussed this on a number of programmer's forums and mailing lists, and always get contradicting responses from different people.

I hope you have better luck with this than I have, and if you do have a solution, I hope you'll share it. Wink

Good luck with your continued work on Battlescape. We're all looking forward to another beautifully done title from Moonpod.
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 Previous  1, 2, 3, 4, 5  Next
Page 3 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