Guyon:
Quote: "
How hard would you think that would be to make for DBpro? What would be the hardest part, and what pitfalls do you see in creating it?
"
The compiler/virtual machine are some of the most challenging aspects. Although environmentally your robot controllers need to handle their world automatically for the user. So features like sliding collision need to be handled on the libraries side of things. Also, the bots will need to check line of sight, and otherr characteristics about their environment. Like locating objects (visibility / path finding). The last thing the bot coder wants to do is write complex scripts to guide themselves through the world. It';s too tedious and places too much stress on the interpreters back.
Quote: " One thing I remember about the game was, different commands took different clock cycles to perform, as well an each player had a different amount of commands depending on there strategy. So you could have a slow powerful high AI tank, or a light fast highly maneuverable one.
"
A couple years ago I wacked together a virus competition engine in DB called Kyruss. The concept would have been to pit rival programmers/groups against each other so they could compete in a type of memory wars. The game takes place in a computer simulation. To win you had to be last remaining 'running' task. It's pretty trivial to write. But really doesnn't suit Db though..
One of the key drama's was that Kyruss was too low level for most to follow. Since your dealing with bombing memory(inside the simulation), it was based around a 'cut down' 68000 assembly. With a bit of api to help the user out.
A year later I decided to attempt to build a robot game based around a basic language. Logically this a more accessible approach, but it does place a lot of stress on the interpreters back, In particular as the command/feature set evolved. So realistically DB wasn't going to cut it. I can't say how it'd run Dbpro. After porting, it still doesn't work (crashes). It's a real shame.
One benefit that writing in DBpro today has over the way i was forced to go about things was the need for octree/portal support. Since the interpreter will eat through some serious time. So if you want to hold the frame rate up with a number of bots, your going to either have 'minimal' gfx overhead or interleave tiny cycle slices over many frames. This isn't really a valid option, as it amounts to watching a slow motion war, rather than a real time battle..
i.e.
If you bot takes 1000 cycles to perform one update. And the interpreter allocates say 250 cycles (nice round number) for the starting cycles of each bot. So if the target refresh rate is 30fps for the virtual machine, then the bots will actually update in 30/4 = 7.5 Fps.
The trick is going to be building a command set that makes the scripts both powerful and as efficient as possible for the VM.
Anyway the couple of tech demos of Kyuss 1 and 2 or still on my site.
http://www.Kyruss.UnderwareDesign.com (the assembly/virus oens one)
http://www.Kyruss2.UnderwareDesign.com (basically Db written in DB
)
Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
