View Single Post
Old 07-14-2012, 01:39 PM   #52
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: Can MUDs implement range/distance?

So, I had a few more thoughts after all:

Firstly, I've been keeping an eye on arantha--I was kind of waiting on the crafting system, assuming one is forthcoming (I get the impression one is from various posts here), but I'll probably be dropping by to check it out. Unfortunately, I'm not overly sure just how accessible your approach is, to the blind, and probably won't be able to use it unless it has added features for that, or something. The impression I get is a roguelike ascii map for combat, with a time limit on the turns, so not very accessible, but I shall see in the next couple of days if I get a free moment.

I wasn't going to go down this road, but since we seem to be anyway. If you're going to try this kind of mud, have a look at scala--there's issues with hosting it because it runs on the java vm, but c++ can do a lot of the same thigns, if you're willing to jump through hoops. In particular, one of the common things I've seen floating around when teaching scala is a fully working implementation of mixed numbers (i.e. 1 and 2/3), which can be used the same as ints (you multiply, divide, etc the same way, and use // to define one, as in val x = 2//3), and they can be converted to int/double/whatever easily. Which is one of the reasons I like scala, and one day I'll figure out how to host jvm for free or have an income, and buy a vps.

Finally, and this is for the math people out there, mostly. I don't fully understand how this works, only how it can be used.

Take a look at opengl math, in particular the matrices, as the same thing applies. If each object you want to represent in the game world is considered to be a model with one point, a lot of the same stuff applies--you can suddenly do "to your left" depending on the direction faced, etc, by transforming each object into the local coordinate system of the viewer and generating your descriptions off that. Basically, you transform the coordinates such that the player is at the origin and the y axis points straight out of the player's chest--negative x is to the left and positive x is to the right, and the pythagorean theorem still works for distances. This is heavily cpu intensive unless offloaded onto a graphics card, but both have the same problem: shared resources. You're unlikely to find a shared server with a graphics card that's high end and, if you do, 6 or 10 or 100 other people are probably all on it for the same reason--graphics cards are now basically hugely parallel cpus, and you can offload a lot of parallelizable scientific programming on to them. That said, I'm not sure how bad this'd actually be, but we're talking o(pn), where p is the number of players and n the number of objects per player--for each player, this has to be done for each object. It does allow for a lot of interesting things, however, like affects that make your left eye stop working, etc, or that flip everything about the y axis--couple that with some sort of block left/right system that protects either the left or right side, and you've got lots of really interesting fun under way. This is probably extremely overkill for this, but if you're interested, look into opencl (open computing language, iirc).

This is one of those optimization things, but for a 2d coordinate system, you can do most of the above with trigonometry--3d systems are doable this way, too, but matrices are much easier at that point, given the preexisting libraries.

One day, i'm going to get around to writing a mud with this kind of stuff. One day, when I work out the server issues and can use something that's not c/c++--I hate headers with a vengence, and just love signal segfault, or the more obscure segabrt (out of memory, sometimes, not always). I also need time and motivation--but as we all know, you can succeed without them.
camlorn is offline   Reply With Quote