ID:151775
 
Well, I was keeping this 3D byond idea a secret, but since I never have time to work on anything fun any more, I'm going to talk about it here.

It's actually slightly more than an idea, because I have part of it working. Here's the results of what I've done so far:

Step 1: C# windows application fires up.
Step 2: C# app fires up BYOND app of your choice.
Step 3: Byond window is quickly bound to the interface of the C# windows form.

Here's part of the trick, this form doesn't actually run a map, it's just code and some controls. The code is minimal, the idea being to let C# do most of the work. I'm using a "pipe" of sorts -- a dll -- that allows me to talk between programs.

Step 4: Tie in XNA window for 3D graphics in the same windows form.

From this step onward I haven't really bothered with, because it's so much too think about. I like the pre-existing network of BYOND, and I have an automated process for linking two worlds which are hosted independently, but I'm wondering how much of BYOND to allow into this environment and how much of C#.

Should all of the networking be done C#/XNA side, or should all of it be done in BYOND, or should it be a hybrid?

Beyond networking, what of the map files in BYOND, should my system handle all movement in BYOND and export it to XNA to be handled, or should commands-only be permitted through the pipe instead of things like variables containing coordinates?


I'm just looking for thoughts here.

You're shooting yourself in the foot here, basically.

If you're doing something in 3D, Xna exposes proper constructs to deal with that (Vector3, Matrix, Model, etc). Doing that logic in DM will be more difficult and require more calculations than it would in Xna.

I guess what I'm asking is: What part of DM do you actually want in this?
First, I admire your enthusiasm about your "secret," which I'm assuming is because you think you're the first to tread the territory, but someone else has already done real 3D via an external program (though it was just a proof of concept rather than an entire game). Completely externally running program though, as Byond did not have the library system it has now.

Second, and the real reason you might want to rethink what you're doing (I wasn't trying to discourage you with my first point, but I am very slightly with this one), I agree with Alathon that you are shooting yourself in the foot.

Byond is great for exactly what it was made for. Sometimes, when I'm bored, I'll spend 30 minutes making a game that keeps me occupied and having fun for the rest of the day (sometimes for a few days or a week even). You can very, very rapidly and easily create certain types of games. What you're doing is not one of them. While that in and of itself is not a good reason to not use Byond for whatever you are doing, the reason you might want to reconsider is that it is actually easier to fully develop certain types of games outside of Byond rather than trying to force Byond to do what wasn't intended of it.

Granted, I have thought many times about doing something similar to what you are doing. Heck, in the long past, I even attempted a few 3D game types entirely in Byond, without external support. I made one test world that was similar to OFD's "TRN," I half-made a first-person-view spacecraft-shooter which was pretty cool and allowed you to fly around in a fully-3D movement/rotation (being in space with a black background gets you out of having to worry about terrain though! that makes it a LOT easier) which used a quasi-3D approach for viewed objects kind of like what Duke Nukem had, and I once even tried using Byond to do real 3D, having a function that took data for primitives which attempted to draw icons for them, trying to use a model similar to OpenGL's. That last project didn't get far at all.

The last mentioned project there was impossible to complete, obviously, since Byond's dynamic graphic-drawing system was (is?) way too slow, since it wasn't intended to support this kind of behavior.

Obviously, what you're doing isn't quite the same, as you are now able to leverage outside elements that are not so slow, but I would imagine it will still be a pain to implement properly in Byond.

This is all just a bunch of food for thought for the most part. If you still really want to do it, all the more power to you. As I said, now that I can whip up an external library for Byond, I've actually thought about making a DLL that does little more than give Byond direct access to OpenGL functions, though I keep deterring myself by telling myself the same stuff I just told you.

I have one last concern though. If you are using a dll to support 3D on the client's side, generally you would have to have a distributed-server model where all the client's themselves are executing the contents of the dll rather than the real server. This is one area I have been paranoid about, as this adds a huge security risk to your computer through Byond. When you execute a function in a dll, you are literally letting the dll's creator execute any arbitrary code on your computer, which is especially hazardous if you don't have proper security set up on it, as anything at all could happen.
In response to Alathon
Alathon wrote:
You're shooting yourself in the foot here, basically.

If you're doing something in 3D, Xna exposes proper constructs to deal with that (Vector3, Matrix, Model, etc). Doing that logic in DM will be more difficult and require more calculations than it would in Xna.

Well, I had imagined that perhaps the world could have 2D coordinates (think like Runescape [I know, how cliche]), but the entire world look and feel 3D.

Of course I mean that in the sense that if I decided to incorporate the map system from BYOND, otherwise I'd just keep it a command-only sort of system for the BYOND part of it. I guess in that sense all BYOND would be doing is connecting all the players and worlds, and issueing commands. From that part on all 3D calculations would be handled by the C#/XNA component.

I guess what I'm asking is: What part of DM do you actually want in this?

That's what I was trying to figure out. Hehe.
In response to Loduwijk
Loduwijk wrote:
First, I admire your enthusiasm about your "secret," which I'm assuming is because you think you're the first to tread the territory, but someone else has already done real 3D via an external program (though it was just a proof of concept rather than an entire game). Completely externally running program though, as Byond did not have the library system it has now.

Second, and the real reason you might want to rethink what you're doing (I wasn't trying to discourage you with my first point, but I am very slightly with this one), I agree with Alathon that you are shooting yourself in the foot.

Byond is great for exactly what it was made for. Sometimes, when I'm bored, I'll spend 30 minutes making a game that keeps me occupied and having fun for the rest of the day (sometimes for a few days or a week even). You can very, very rapidly and easily create certain types of games. What you're doing is not one of them. While that in and of itself is not a good reason to not use Byond for whatever you are doing, the reason you might want to reconsider is that it is actually easier to fully develop certain types of games outside of Byond rather than trying to force Byond to do what wasn't intended of it.

That's true, but I do love the syntax of BYOND's DM. I'm never more comfortable than when programming in DM. The BYOND network is also pre-established, and it's easier to make an entry in the BYOND community than it is to make a whole new web-presence.

Granted, I have thought many times about doing something similar to what you are doing. Heck, in the long past, I even attempted a few 3D game types entirely in Byond, without external support. I made one test world that was similar to OFD's "TRN," I half-made a first-person-view spacecraft-shooter which was pretty cool and allowed you to fly around in a fully-3D movement/rotation (being in space with a black background gets you out of having to worry about terrain though! that makes it a LOT easier) which used a quasi-3D approach for viewed objects kind of like what Duke Nukem had, and I once even tried using Byond to do real 3D, having a function that took data for primitives which attempted to draw icons for them, trying to use a model similar to OpenGL's. That last project didn't get far at all.

The last mentioned project there was impossible to complete, obviously, since Byond's dynamic graphic-drawing system was (is?) way too slow, since it wasn't intended to support this kind of behavior.

My pixel demo basically was one giant test to determine exactly that. I found what you found, it was way too slow. But on the plus side, I was able to generate some pretty pixels.

Obviously, what you're doing isn't quite the same, as you are now able to leverage outside elements that are not so slow, but I would imagine it will still be a pain to implement properly in Byond.

Yeah, that's why I haven't worked on it for months. Well, that and I just haven't had a lot of time.

This is all just a bunch of food for thought for the most part. If you still really want to do it, all the more power to you. As I said, now that I can whip up an external library for Byond, I've actually thought about making a DLL that does little more than give Byond direct access to OpenGL functions, though I keep deterring myself by telling myself the same stuff I just told you.

Ooo, ooo, please do! That sounds fun.

I have one last concern though. If you are using a dll to support 3D on the client's side, generally you would have to have a distributed-server model where all the client's themselves are executing the contents of the dll rather than the real server. This is one area I have been paranoid about, as this adds a huge security risk to your computer through Byond. When you execute a function in a dll, you are literally letting the dll's creator execute any arbitrary code on your computer, which is especially hazardous if you don't have proper security set up on it, as anything at all could happen.

Each client in this model has their own dll, and they could make that dll do whatever they want, but they wouldn't be able to execute any malicious code against anyone else...

As I wrote that sentence my mind went another place -- they could manipulate the world coordinates or anything else if I gave the BYOND app too much leeway. That means, unfortunately, that the only thing BYOND can do in this model is provide commands to be interpreted by the XNA/C# module.

Dang. Well at least I got that sorted out.

Well, point being, it will likely be a client-to-client model. However, to ensure that no one can tamper with the game, it might be better to have a star sort of setup. One server sits in the middle with the world coordinates and events, the clients merely conjure up the 3D display of wher e they are, and ask the server for an update of where they are.

Well, thanks for the input. Any other thoughts?
In response to Rockinawsome
Rockinawsome wrote:
Of course I mean that in the sense that if I decided to incorporate the map system from BYOND, otherwise I'd just keep it a command-only sort of system for the BYOND part of it. I guess in that sense all BYOND would be doing is connecting all the players and worlds, and issueing commands. From that part on all 3D calculations would be handled by the C#/XNA component.

If you're working in Xna, check out Lidgren-Network, or any other host of applicable already-made networking libraries. The one I linked to has Xna hooks and is specifically for games in C# - There are plenty of others for general networking.

BYONDs networking is one of the weak points as far as speed and control is concerned, its definitely not what I'd capitalize on. If you're not taking advantage of the easy syntax, GUI editor or similar, I wouldn't recommend it - Although like Loduwijk says, if you want to then sure :)