Forums » General
Let's all critique Whistler's performance as well!
Lesee... where to start... >:P
Lesee... where to start... >:P
I demand the ability to eject from my ship on a cable and fist-fight other players. In space.
Rock 'em Sock 'em Robots!
Well, fistfighting is taking it a bit far IMO, but a purchaseable EVA suit outfit, that spat you out with minimal thruster power, but invulnerable and with the power to carry a single piece of cargo (e.g. nation xith) off to a nearby station, would be a cool addon.
FOG! Gotta love fog!
FOG!!!
FOG!!!
if Sunset_Graffiti gets to fistfight in space, then I want to have the ability to play golf on small planetoids.
Let's stay on topic here, or just let it fade away....
that fog looks pretty cool, i wonder though, will there be some kind of fluid flow to it, or is it static?
100000000000 credits to the person whou can bring me a fog machine widgit
Perhaps I'm being dense but wasn't the deliverator working a while ago? Shouldn't you be able to look back and see what changed to break it and then undo that change or rework it. Perhaps I'm stating the obvious and it's just easier for you guys just to scrap it and start it over.
They've explained it a few times already. See the excerpt from incarnate's post below
Tue, Dec 05, 2006 incarnate
"...Deliverator is currently written in one of the oldest of programming languages: Lisp. Lisp is a pretty amazing language in a lot of ways, especially as they relate to our deliverator-type development. Lisp code is written and run inside of a process that internally handles memory allocation, garbage collection, and interpreting/compiling code as needed. It's all very elegant, and has worked fine for us for well over a year. Until last month, when Michael released a heavily revised version of Deliverator after a couple of months of work, and found that the lisp CL (the program that does the above running functionality) balloons in memory and bombs out after a few hours. He and Andy then spent a month trying to get the damned thing to work, debugging, swapping lisp platforms (CMUCL, SBCL, whatever) to no avail.
So, now we're changing platforms. Writing and moving to a whole new translated back end which starts in Lisp, for simpler development, and then individual functionality compiles down to light threads of a language called Erlang. Thus, the lisp system says something like "the hive is this big, in these locations, and has this many bots doing.. these activities". Those bots then become specific threads and run in a different lightweight model, which is much more scalable (distributed across as many machines as needed) and more resilient. If lisp bombs eventually, it hardly matters, the started threads are all autonomous.
We've been planning on doing something like this for.. well, over a year, but just for scalability purposes. But we didn't plan on doing it NOW, and we sure as hell didn't plan on being forced into doing it.
Why does this make any difference to development? Unfortunately, most of our interesting next-generation gameplay has come to hinge on the "deliverator" construct, and what it was meant to do. Oh, sure, we had CtC before deliverator, so we could write it in Lua or something, right? But that's part of why CtC has been broken for so long. Using lua to do that functionality, for various reasons, has become a confusing and unmaintainable mess, and is ill suited to the sort of work we're going to need to do as we move ahead. Debugging is a giant pain in the ass, for instance. So, we made this other thing to let us do what we needed to do.. much better, and then it exploded in our face last month when the underlying (and well-used and supposedly reliable) system that runs it.. stopped working right.
When deliverator was working, I could tell Michael a general idea and have him drop it into the game in like a day. Border Skirmish, for instance, which is an unfinished test-case, was implemented almost immediately. Doing the same in lua would probably have been a week or two of annoying debugging when things inevitably didn't work quite right. I haven't given him more refined and finished gameplay to implement in Deliverator, frankly because he's been working on internals, and it wasn't yet clear to me that the system was totally ready for prime-time (looking back now, gee!). So I've been waiting for that to be finished up, while trying to do other things. The three-location Hive launch, which was supposed to happen a month ago, and the new economy, which was supposed to happen about now, were going to be the first game-wide uses of the system.
Tue, Dec 05, 2006 incarnate
"...Deliverator is currently written in one of the oldest of programming languages: Lisp. Lisp is a pretty amazing language in a lot of ways, especially as they relate to our deliverator-type development. Lisp code is written and run inside of a process that internally handles memory allocation, garbage collection, and interpreting/compiling code as needed. It's all very elegant, and has worked fine for us for well over a year. Until last month, when Michael released a heavily revised version of Deliverator after a couple of months of work, and found that the lisp CL (the program that does the above running functionality) balloons in memory and bombs out after a few hours. He and Andy then spent a month trying to get the damned thing to work, debugging, swapping lisp platforms (CMUCL, SBCL, whatever) to no avail.
So, now we're changing platforms. Writing and moving to a whole new translated back end which starts in Lisp, for simpler development, and then individual functionality compiles down to light threads of a language called Erlang. Thus, the lisp system says something like "the hive is this big, in these locations, and has this many bots doing.. these activities". Those bots then become specific threads and run in a different lightweight model, which is much more scalable (distributed across as many machines as needed) and more resilient. If lisp bombs eventually, it hardly matters, the started threads are all autonomous.
We've been planning on doing something like this for.. well, over a year, but just for scalability purposes. But we didn't plan on doing it NOW, and we sure as hell didn't plan on being forced into doing it.
Why does this make any difference to development? Unfortunately, most of our interesting next-generation gameplay has come to hinge on the "deliverator" construct, and what it was meant to do. Oh, sure, we had CtC before deliverator, so we could write it in Lua or something, right? But that's part of why CtC has been broken for so long. Using lua to do that functionality, for various reasons, has become a confusing and unmaintainable mess, and is ill suited to the sort of work we're going to need to do as we move ahead. Debugging is a giant pain in the ass, for instance. So, we made this other thing to let us do what we needed to do.. much better, and then it exploded in our face last month when the underlying (and well-used and supposedly reliable) system that runs it.. stopped working right.
When deliverator was working, I could tell Michael a general idea and have him drop it into the game in like a day. Border Skirmish, for instance, which is an unfinished test-case, was implemented almost immediately. Doing the same in lua would probably have been a week or two of annoying debugging when things inevitably didn't work quite right. I haven't given him more refined and finished gameplay to implement in Deliverator, frankly because he's been working on internals, and it wasn't yet clear to me that the system was totally ready for prime-time (looking back now, gee!). So I've been waiting for that to be finished up, while trying to do other things. The three-location Hive launch, which was supposed to happen a month ago, and the new economy, which was supposed to happen about now, were going to be the first game-wide uses of the system.
Thank you Whistler that answers most of my question though shouldn't it be as simple as reverting to a backup until the new system is ready? My guess is it's a bit more complex than that otherwise they would have done that by now. Perhaps there are some players who know Lisp or Erlang that would be willing to help with some tasks? Also are you guys expecting any problems with the translation or is that fairly reliable?, that could be something that a few competent players might be able to help with.
I'm simply trying to point out the obvious in the hope that something useful might come of it on the off chance that you guys haven't considered an option or two.
I'm simply trying to point out the obvious in the hope that something useful might come of it on the off chance that you guys haven't considered an option or two.
The devs will likely answer for themselves later, but:
I think it is more complicated than simply reverting, if only because so many things hinge on the revisions poor Momerath made. Rolling back would negate months of work and break other stuff that is tied in with it. Deliverator works, but it needs babysitting due to the memory issue.
The devs do have an intern or two to help out with things, but I think that the time used to fully orient, communicate with and supervise new people is generally better spent just writing the code themselves. This part of the job requires a full understanding of the Big Picture. I don't think translation will be an issue at all.
I think it is more complicated than simply reverting, if only because so many things hinge on the revisions poor Momerath made. Rolling back would negate months of work and break other stuff that is tied in with it. Deliverator works, but it needs babysitting due to the memory issue.
The devs do have an intern or two to help out with things, but I think that the time used to fully orient, communicate with and supervise new people is generally better spent just writing the code themselves. This part of the job requires a full understanding of the Big Picture. I don't think translation will be an issue at all.
Whistler is right on the money :)
Thank you I'm satisfied. Hope all goes well with the Deliverator2.