Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[th3flyboy]

Hello, I'm not sure if this is the exact right board for this, but I figured I may as well ask. I'm planning on picking up the full version of Anteworld soon, but I would like to ask a few questions about it.

1. I know Anteworld will be modifiable, but my question is, how much will end users/modders be able to extend it and access the base engine using DLL plugins and scripting. As a few examples, if someone wanted to implement AI, or various other code based functionality, to make for example, a combat simulator, would that be possible to implement using plugins?

1-1. If the functionality mentioned above will be possible, is there any rough guess as to when functionality as mentioned above would be available?

2. Will there be a Linux version in the foreseeable future?

I do intend on getting it whether or not the answer to these questions is yes or no, the main reason I ask is I think that there are some cool possibilities that could happen if the right mod capabilities are available.

Thanks,
Flyboy

[cameni]

We plan to evolve Anteworld into a basis of a game/sim platform, where devs can make game mods, games, sim cores etc and have it automatically distributed and installed/upgraded for users that want it. Should work for both free and commercial games. But we are very bad at guessing when this could happen

Linux (and Macs) - basically when it gets into our priority list. There's practically just one thing that must be specifically coded for it, the asynchronous file/socked reads, but I expect there would be a lot of debugging and tweaking. Now that I think about it, we would probably need a dedicated guy for it.

[th3flyboy]

We plan to evolve Anteworld into a basis of a game/sim platform, where devs can make game mods, games, sim cores etc and have it automatically distributed and installed/upgraded for users that want it. Should work for both free and commercial games. But we are very bad at guessing when this could happen

Awesome, that is pretty much exactly what I was hoping for, even if the actual implementation is a while off.

Linux (and Macs) - basically when it gets into our priority list. There's practically just one thing that must be specifically coded for it, the asynchronous file/socked reads, but I expect there would be a lot of debugging and tweaking.

I did some reading up on the subject. One method of doing it would involve using the boost::asio library, however boost libraries aren't always the best option when it comes to performance and being light weight. Another option may be using Pthreads, which I think may be a better option for preventing unneeded dependencies and bloat. It would require more work, but it would also allow more control and be lighter weight.

Pthreads and boost::asio both also have socket related code, so those libraries should also be able to cover the socket (provided socked was a typo) functionality as well. What I've read however indicates that Pthreads may not be the best solution for implementing asynchronous sockets and AIO due to limitations caused by poor implementation as well as being at userland level, and that it would be better to do it on a kernel level, however I'm not sure how accurate those statements are as of today, and I'm not sure if there would be GPL issues in implementing threading using the kernel level calls. I'll admit I don't have much experience with this particular subject, so I can't give much personal knowledge on the subject. It is however something I hope to investigate as soon as I get the time anyway, as the open source project I'm working with is trying to deal with implementing threading as well.

Now that I think about it, we would probably need a dedicated guy for it.

I'm not sure if I should interpret that as serious and possibly send in a resume, or interpret it as an April Fools' day joke. 

[cameni]

It's not so much a problem of sockets, mainly for files we need to handle the async loading to not block the rendering pipeline. Even that is not such a big problem as our job manager handles the file loading in separate threads already, and it wouldn't matter that much if these blocked. However, the job manager is also controlling a possible congestion of requests so that there aren't many jobs competing for the resource, and it uses the detection of a blocking request to control other jobs so that the resources are used effectively. It's as if a small operating system acting there

No boost, that's a huge beast living for itself. But I'm sure it won't be such a big problem, not shy to use low level functions .. it just needs time.

Not a Fools' day joke, I just think it will need a dedicated guy, once we can afford a couple of them. Relocating to SK?

[th3flyboy]

Ah, I see, so the threading for the most part is there, it's just the asset loader implementation that needs to be done. As for boost, I agree, it's nice for when you want functionality fast, but for something that's intended to be optimized and efficient, it's way too clunky. One thing I do have to ask however is about whether or not there may be a chance of at least a basic DLL plugin API in the near future, as that may be useful to at least start on development of more advanced mods, even if the API initially is pretty basic. As for relocating, I'm not planning on it, but if I were to relocate, I'd consider SK if there was a job in it for me.

Finally; sorry it took so long to respond, life has been hectic lately with school and other real life commitments.