Official Soldat Forums
Soldat Fans => Developers Corner => Topic started by: strack on August 08, 2013, 09:24:24 pm
-
I think the biggest mistake of Soldat development is the fact of the soldatserver not being an open source project.
Why don't you guys (soldat developers) create a Github project and release the Soldatserver code?
I'm telling this cause I'm a Node.JS developer and I really want to create a Soldatserver opensource project written in Node.JS.
With Node.JS, I can build a very scalable and light soldatserver.
With the soldatserver source opened, that port can be release much faster and easier?
When this game will change this little mentality and selfishness?
When this game will become a great and big game?
Soldat is like a game that is always on ALPHA.
-
There's a lot of developers trying to release a successful Soldat clone along 10 years and there's no one clone that is solid as Soldat, with a decent community as ours (active official forum, sctfl, swc etc). I'm asking myself about this since 2006. Why fix little bugs ("features" for veterans) if what we need is a new Soldat (new graphic engine especially)?
I loved the OpenSoldat idea but...
-
strack if you care about soldat come to #soldat.devs on irc and find a way you can help. All the devs are there so you can talk to them directly
-
Soldat is closed source, this is intentional.
In the long term the goal is to make the server opensource.
But there are a few things we need to do before that can happen.
I'm not sure if a server in a different programming language will be helpful.
You see, the server and client are supposed to share some common code. This way changes to the server don't require additional work on the client.
ATM server and client share some code parts but not everything (due to historical reasons, don't ask...) and we are working on improving that.
Soldat will become better as we are cleaning up the code base.
If you want to help us with that and you know Delphi/Object Pascal feel free to talk to us on #soldat.devs on quakenet.
-
@Shoozza
If we hypothetically build a Node.JS version of soldat server, we could have the common part written in C++ and the rest could be written in Javascript.
Today, Node.JS (Javascript) have the biggest open-source community in the internet. And that could be a boost in soldat's expansion.
Think about that?
It's impossible to start a project like that, today?
-
@Shoozza
If we hypothetically build a Node.JS version of soldat server, we could have the common part written in C++ and the rest could be written in Javascript.
Today, Node.JS (Javascript) have the biggest open-source community in the internet. And that could be a boost in soldat's expansion.
Think about that?
It's impossible to start a project like that, today?
That would require a huge rewrite. Issues:
- Soldat's code is over 100k lines of Pascal, so you can't copy/paste or refactor to c++ so easily
- A lot of Soldat's "features" are really bugs so reproducing the exact behavior/gameplay wouldn't be that trivial
- "Node.JS (Javascript) have the biggest open-source community in the internet." << what? Are you kidding me? Node is right up there with Rails and Flask and every other hip new framework that all the fanboys rave over for a few years then forget about
That said, nothing is stopping you from making a clone of Soldat and its server in Node. You'll just have no existing code to go off of.
-
@Shoozza
If we hypothetically build a Node.JS version of soldat server, we could have the common part written in C++ and the rest could be written in Javascript.
Today, Node.JS (Javascript) have the biggest open-source community in the internet. And that could be a boost in soldat's expansion.
Think about that?
It's impossible to start a project like that, today?
That would require a huge rewrite. Issues:
- Soldat's code is over 100k lines of Pascal, so you can't copy/paste or refactor to c++ so easily
- A lot of Soldat's "features" are really bugs so reproducing the exact behavior/gameplay wouldn't be that trivial
- "Node.JS (Javascript) have the biggest open-source community in the internet." << what? Are you kidding me? Node is right up there with Rails and Flask and every other hip new framework that all the fanboys rave over for a few years then forget about
That said, nothing is stopping you from making a clone of Soldat and its server in Node. You'll just have no existing code to go off of.
Ok. Keep coding on that. And Soldat will continue falling.
<< what? Are you kidding me? Node is right up there with Rails and Flask and every other hip new framework that all the fanboys rave over for a few years then forget about
http://webcache.googleusercontent.com/search?q=cache:4IOcCsF6v_oJ:https://github.com/languages+&cd=1&hl=pt-BR&ct=clnk&gl=br&lr=lang_en%7Clang_pt
What? 24% (21% js + 3% coffee)
-
@Shoozza
If we hypothetically build a Node.JS version of soldat server, we could have the common part written in C++ and the rest could be written in Javascript.
Today, Node.JS (Javascript) have the biggest open-source community in the internet. And that could be a boost in soldat's expansion.
Think about that?
It's impossible to start a project like that, today?
That would require a huge rewrite. Issues:
- Soldat's code is over 100k lines of Pascal, so you can't copy/paste or refactor to c++ so easily
- A lot of Soldat's "features" are really bugs so reproducing the exact behavior/gameplay wouldn't be that trivial
- "Node.JS (Javascript) have the biggest open-source community in the internet." << what? Are you kidding me? Node is right up there with Rails and Flask and every other hip new framework that all the fanboys rave over for a few years then forget about
That said, nothing is stopping you from making a clone of Soldat and its server in Node. You'll just have no existing code to go off of.
Ok. Keep coding on that. And Soldat will continue falling.
<< what? Are you kidding me? Node is right up there with Rails and Flask and every other hip new framework that all the fanboys rave over for a few years then forget about
http://webcache.googleusercontent.com/search?q=cache:4IOcCsF6v_oJ:https://github.com/languages+&cd=1&hl=pt-BR&ct=clnk&gl=br&lr=lang_en%7Clang_pt
What? 24% (21% js + 3% coffee)
Just because 24% of the projects include javascript (I'm not going to count coffee script) doesn't mean they're all using nodejs, which is what you're arguing for. Furthermore, I can't even find the link you pasted outside of google cache. Additionally, that list probably aggregates languages each project uses, so it'll count projects that include PHP and JS and ASP/JS and Perl/JS all towards JS' share. So, if you think that 24% of Github's projects are just javascript you're probably reading the graph wrong. And again, most of that JS usage is definitely client side widget toolkits/libraries, not stuff on the server end which is what you're proposing.
-
@Shoozza
If we hypothetically build a Node.JS version of soldat server, we could have the common part written in C++ and the rest could be written in Javascript.
Today, Node.JS (Javascript) have the biggest open-source community in the internet. And that could be a boost in soldat's expansion.
Think about that?
It's impossible to start a project like that, today?
That would require a huge rewrite. Issues:
- Soldat's code is over 100k lines of Pascal, so you can't copy/paste or refactor to c++ so easily
- A lot of Soldat's "features" are really bugs so reproducing the exact behavior/gameplay wouldn't be that trivial
- "Node.JS (Javascript) have the biggest open-source community in the internet." << what? Are you kidding me? Node is right up there with Rails and Flask and every other hip new framework that all the fanboys rave over for a few years then forget about
That said, nothing is stopping you from making a clone of Soldat and its server in Node. You'll just have no existing code to go off of.
Ok. Keep coding on that. And Soldat will continue falling.
<< what? Are you kidding me? Node is right up there with Rails and Flask and every other hip new framework that all the fanboys rave over for a few years then forget about
http://webcache.googleusercontent.com/search?q=cache:4IOcCsF6v_oJ:https://github.com/languages+&cd=1&hl=pt-BR&ct=clnk&gl=br&lr=lang_en%7Clang_pt
What? 24% (21% js + 3% coffee)
Just because 24% of the projects include javascript (I'm not going to count coffee script) doesn't mean they're all using nodejs, which is what you're arguing for. Furthermore, I can't even find the link you pasted outside of google cache. Additionally, that list probably aggregates languages each project uses, so it'll count projects that include PHP and JS and ASP/JS and Perl/JS all towards JS' share. So, if you think that 24% of Github's projects are just javascript you're probably reading the graph wrong. And again, most of that JS usage is definitely client side widget toolkits/libraries, not stuff on the server end which is what you're proposing.
Github removed that page:
https://github.com/blog/1585-explore-what-is-trending-on-github
But that info is recent. And no, that graph is based on the most written language on each project.
Most of Javascript projects also work in Node.JS.
So that fact is: The most active community today is Javascript and Node.JS (+coffee script, there is a lot of Node.JS projects written in coffee).
-
Github removed that page:
https://github.com/blog/1585-explore-what-is-trending-on-github
But that info is recent. And no, that graph is based on the most written language on each project.
Probably also includes people duplicating projects/"forking" which just copies code around.
If you want to see a solid example (that doesn't have the page redacted :-/) of the languages with the most lines of code written, look at OhLoh: https://www.ohloh.net/languages?query=&sort=code
C > XML > C++ > HTML > Java > Javascript
You can't use github as your only source (lol pun!) here because it's based around people finding a project, "forking" it (which doubles the stat), occasionally submiting code or just forgetting about it.
Most of Javascript projects also work in Node.JS.
Yeah, especially the ones that revolve around manipulating the HTML DOM to make clickable buttons and slide things around. /sarcasm
Just because the syntax is the same doesn't mean the utility also is.
So that fact is: The most active community today is Javascript and Node.JS (+coffee script, there is a lot of Node.JS projects written in coffee).
What you're not grasping is that the usage of JS is primarily geared to client side web browser scripting, not complex tasks on the server side, and certainly not game server logic.
As this war has gone on long enough (not to say I haven't enjoyed it but it's still petty) I'll just lay down these points:
- I'm all for rewriting Soldat in another language
- Releasing Soldat as Open Source would be cool, but Shoozza listed the caveats required in doing so numerous times over the forums
- I do enjoy writing code in JS (as well as other languages) and I use it often at work
My only gripe with what you're proposing is that you're saying that JS is the best language for the job to rewrite a complex game server in, while ignoring that the vast majority of JS in existence is for the purpose of client side scripting rather than server side applications and using that as your argument.
-
I've already talked with jrgo on IRC.
But just to clear it out.
That link is ordered by code lines. And that does not count. (C and Java project are much bigger than other languages)
Probably also includes people duplicating projects/"forking" which just copies code around.
If you want to see a solid example (that doesn't have the page redacted :-/) of the languages with the most lines of code written, look at OhLoh: https://www.ohloh.net/languages?query=&sort=code
C > XML > C++ > HTML > Java > Javascript
You can't use github as your only source (lol pun!) here because it's based around people finding a project, "forking" it (which doubles the stat), occasionally submiting code or just forgetting about it.
That link is ordered by code lines. And that does not count. (C and Java project are much bigger than other languages)
The correct ordered are:
https://www.ohloh.net/languages?query=&sort=projects
https://www.ohloh.net/languages?query=&sort=contributors
And ignoring CSS, HTML and XML (not programming languages).
Javascript is the first.
Yeah, especially the ones that revolve around manipulating the HTML DOM to make clickable buttons and slide things around. /sarcasm
Just because the syntax is the same doesn't mean the utility also is.
There are many of browser javascript projects that also have a Node.JS API.
Also, there are many Node.JS that requires browser javascript plugins and frameworks.
What you're not grasping is that the usage of JS is primarily geared to client side web browser scripting, not complex tasks on the server side, and certainly not game server logic.
As this war has gone on long enough (not to say I haven't enjoyed it but it's still petty) I'll just lay down these points:
- I'm all for rewriting Soldat in another language
- Releasing Soldat as Open Source would be cool, but Shoozza listed the caveats required in doing so numerous times over the forums
- I do enjoy writing code in JS (as well as other languages) and I use it often at work
My only gripe with what you're proposing is that you're saying that JS is the best language for the job to rewrite a complex game server in, while ignoring that the vast majority of JS in existence is for the purpose of client side scripting rather than server side applications and using that as your argument.
Node.JS is a not just Javascript running outside the browser.
It can easly handle complex tasks on server side. I work for almost two years with Node.JS and i've seen many complex projects using Node.JS.
Also you are able to write Node.JS C++ addon if you can't do something on the Javascript part.
Just read more about Node.JS and search for Node.JS projects and you'll see.
-
You know, i've read somewhere that "Psychology and IT" field of study will be popular soon with thesis "Inheritance via prototyping and Stockholm syndrome". I actually start to believe that.
But, let's get down to business. Soldat (server) in javascript is NOT gonna happen, no matter how hard you want it. Why? First of all, because of what Shoozza said: code won't be opensourced anytime soon (although i'm against this one myself). Secondly, because of also what Shoozza said: netcode is shared between client and server, so if server in NodeJS was ever written, that implicates one of two things: also client in javascript (lol), or two necode bases that has to be kept in sync. Neither solution seems appropriate to me.
Thirdly (least important though), imo javascript just sucks. If you have a scale that assumes "the smaller codebase is, the better language it must be" then there's nothing left for me to say but "thank you, go be yourself somewhere else". Javascript is just bad by design: no hard typing makes all kind of typos more than easy, even decent IDE doesn't know which variable belongs where. No distinction between class and object creates a huge mess in defining new types (if we can even call it like that). Closures on function level are just hilarious. And the whole approach to "adapt" and try to parse everything that's passed to function. Seriously, it just feels that programmers are scared to throw an exception in your face because they think that it might offend you. Let's make code crash in a random place 1000 lines later, shall we.
tl;dr: Just.. no, you can as well ask to close this topic. Soldat in JS is not gonna happen, at least not anytime soon.
-
You know, i've read somewhere that "Psychology and IT" field of study will be popular soon with thesis "Inheritance via prototyping and Stockholm syndrome". I actually start to believe that.
But, let's get down to business. Soldat (server) in javascript is NOT gonna happen, no matter how hard you want it. Why? First of all, because of what Shoozza said: code won't be opensourced anytime soon (although i'm against this one myself).
...
Secondly, because of also what Shoozza said: netcode is shared between client and server, so if server in NodeJS was ever written, that implicates one of two things: also client in javascript (lol), or two necode bases that has to be kept in sync.
Like I said in my last post, you can write C++ addon to Node.JS. So you can have a C++ part in Node.JS soldat server and a C++ client with the same code.
Neither solution seems appropriate to me.
Thirdly (least important though), imo javascript just sucks. If you have a scale that assumes "the smaller codebase is, the better language it must be" then there's nothing left for me to say but "thank you, go be yourself somewhere else". Javascript is just bad by design: no hard typing makes all kind of typos more than easy, even decent IDE doesn't know which variable belongs where. No distinction between class and object creates a huge mess in defining new types (if we can even call it like that). Closures on function level are just hilarious. And the whole approach to "adapt" and try to parse everything that's passed to function. Seriously, it just feels that programmers are scared to throw an exception in your face because they think that it might offend you. Let's make code crash in a random place 1000 lines later, shall we.
tl;dr: Just.. no, you can as well ask to close this topic. Soldat in JS is not gonna happen, at least not anytime soon.
Javascript have classes.
Well so you really never worked with JS and have your knowledge about it based on what people always said about it.
Think what you want and keep with that. The problem of Soldat starts that. =)
Do what you want with the topic. =)
-
Like I said in my last post, you can write C++ addon to Node.JS. So you can have a C++ part in Node.JS soldat server and a C++ client with the same code.
That still implies maintaining NodeJS abstraction layer which is pretty much the same thing, just in C++ instead of JS (which is still different from pascal, or are there also pascal bindings?)
Javascript have classes.
Well so you really never worked with JS and have your knowledge about it based on what people always said about it.
Think what you want and keep with that. The problem of Soldat starts that. =)
Do what you want with the topic. =)
I work as website front end developer, i know my stuff about javascript and no, i've never seen classes in here. Afaik they've appeared in ECMA Script 5 but got dropped in harmony anyway. And ECMA5 was never implemented. At least not in browser's javascript implementations. Although i've never ever used NodeJS nor any other server side javascript technology, neither i intend to.
-
That still implies maintaining NodeJS abstraction layer which is pretty much the same thing, just in C++ instead of JS (which is still different from pascal, or are there also pascal bindings?)
Oh god...
I don't know if there is pascal bindings. But I don't doubt there is.
I work as website front end developer, i know my stuff about javascript and no, i've never seen classes in here. At least not in browser's javascript implementations. Although i've never ever used NodeJS, neither i intend to.
Well, it's everything explained.
Classes on Javascript are different and confusing. But it exists.
Also there are many frameworks that helps you work with classes on Javascript, for an example: TypeScript - http://www.typescriptlang.org/
Also all features of ECMA 5 are being implemented on V8 and Node.JS source.
-
Well, it's everything explained.
Classes on Javascript are different and confusing. But it exists.
Also there are many frameworks that helps you work with classes on Javascript, for an example: TypeScript - http://www.typescriptlang.org/
Also all features of ECMA 5 are being implemented on V8 and Node.JS source.
Hacked together clases by third party modules (be it that typescript or coffee script) don't make up for deficiencies in the language itself. Using the latest ecma experimental features as they come out doesn't allow for a necessarily stable and mature codebase either since those new features might not exist forever. And none of that gets around the issue of a split codebase between server and client.
-
Well, it's everything explained.
Classes on Javascript are different and confusing. But it exists.
Also there are many frameworks that helps you work with classes on Javascript, for an example: TypeScript - http://www.typescriptlang.org/
Also all features of ECMA 5 are being implemented on V8 and Node.JS source.
Hacked together clases by third party modules (be it that typescript or coffee script) don't make up for deficiencies in the language itself. Using the latest ecma experimental features as they come out doesn't allow for a necessarily stable and mature codebase either since those new features might not exist forever. And none of that gets around the issue of a split codebase between server and client.
Ok, believe in what you want. Me and other thousands of developers don't agree with that statement
If you don't even know how Node.JS is built and never used, how can you be sure?
And like I said before: a Node.JS soldat server can easily share a C++ part with the soldat client.
You can just open a mind that is already locked.
-
Ok, believe in what you want. Me and other thousands of developers don't agree with that statement
And like I said before: a Node.JS soldat server can easily share a C++ part with the soldat client.
You can just open a mind that is already locked.
Me and other thousands of developers don't agree with that statement << Which statement? I made several.
And you can go try to make a clone of soldat and its client in node/c++. Stop whining and go do it if you're that hell bent on the idea.
-
Oh you want me to build a clone of Soldat? From scratch?
Ok. Sit and wait. I'll not waste my time on that.
Hacked together clases by third party modules (be it that typescript or coffee script) don't make up for deficiencies in the language itself. Using the latest ecma experimental features as they come out doesn't allow for a necessarily stable and mature codebase either since those new features might not exist forever.
This statement.
--
I guess i'll watch Soldat be forever the same as today.
-
Oh you want me to build a clone of Soldat? From scratch?
Ok. Sit and wait. I'll not waste my time on that.
So you'd rather we waste our time instead? Rewriting either the client or server in node mostly still constitutes a clone from scratch even with access to the source as you can't use any of it except as reference.
-
Oh you want me to build a clone of Soldat? From scratch?
Ok. Sit and wait. I'll not waste my time on that.
So you'd rather we waste our time instead? Rewriting either the client or server in node mostly still constitutes a clone from scratch even with access to the source as you can't use any of it except as reference.
No, don't waste your time, too. Continue where it is. Just bug fixing.
With the original source would not be a waste of time.
-
Ok now that i have time to reply (not really):
Soldat already uses a unhyped programming language, replacing parts of it with javascript will not make much difference as you still need Object Pascal/Delphi to do the real stuff.
For us it really doesn't matter how much opensource support javascript has. If you are really into coding Soldat you will have no issue learning Object Pascal/Delphi.
Besides that I'm not really convinced that using the C++ plugin feature and Node.js is the way to go for the server.
First it will require us to work in yet another language which in addition has a functional/prototype based concept.
A lot of people misunderstood what javascript is because of the similar syntax.
Second javascript is less efficient than Object Pascal/Delphi.
While this might not be such a big issue there is still the question why we should make the server less efficient.
Third it would introduce another level of indirection which would make debugging more complicated (in addition to the problems the language itself adds).
Then there is the issue with installation which will require server hosts work more to get soldatserver up and running (no more unzip, chmod and run).
The update procedure will require some thinking and the hosts will need some way to restrict any access to the js files for their customers.
Since we use Object Pascal/Delphi and not c++ creating a plugin for Node.js isn't that easy. It probably requires C++ and Object Pascal/Delphi code compilation with some manual linker calls among other conversion steps.
I don't believe the dev environment setup needs to be more complicated.
Over all I think this doesn't sound like a great idea.
-
Soldat already uses a unhyped programming language, replacing parts of it with javascript will not make much difference as you still need Object Pascal/Delphi to do the real stuff.
For us it really doesn't matter how much opensource support javascript has. If you are really into coding Soldat you will have no issue learning Object Pascal/Delphi.
The idea of using javascript on the soldatserver project is the same as the Node.JS development
Part of the Node.JS source is written in javascript and that fact made the development Node.JS faster and better.
Besides that I'm not really convinced that using the C++ plugin feature and Node.js is the way to go for the server.
First it will require us to work in yet another language which in addition has a functional/prototype based concept.
A lot of people misunderstood what javascript is because of the similar syntax.
Why not? Performance?
Second javascript is less efficient than Object Pascal/Delphi.
While this might not be such a big issue there is still the question why we should make the server less efficient.
Could be a little less effecient but could be better on production and scalability.
Third it would introduce is another level of indirection which would make debugging more complicated (in addition to the problems the language itself adds).
Then there is the issue with installation which will require server hosts work more to get soldatserver up and running (no more unzip, chmod and run).
The update procedure will require some thinking and the hosts will need some way to restrict any access to the js files for their customers.
You could embed Node.JS inside soldatserver's directory. With that you have the same procedure.
I think there's no problem with the update procedure.
Hosts restrictions? Would be much better!
The host would be able to configure each server the way it wanted, with the restriction it wanted.
Since we use Object Pascal/Delphi and not c++ creating a plugin for Node.js isn't that easy. It probably requires C++ and Object Pascal/Delphi code compilation with some manual linker calls among other conversion steps.
I don't believe the dev environment setup needs to be more complicated.
Will continue to need Object Pascal/Delphi?
-
Soldat already uses a unhyped programming language, replacing parts of it with javascript will not make much difference as you still need Object Pascal/Delphi to do the real stuff.
For us it really doesn't matter how much opensource support javascript has. If you are really into coding Soldat you will have no issue learning Object Pascal/Delphi.
The idea of using javascript on the soldatserver project is the same as the Node.JS development
Part of the Node.JS source is written in javascript and that fact made the development Node.JS faster and better.
Not really convinced that it would speed up development. Node.js might be a special case here. Soldatserver has also scripting support with pascalscript.
Might be better to use that instead of JavaScript. That would make it look more like the node.js case, don't you think?
Besides that I'm not really convinced that using the C++ plugin feature and Node.js is the way to go for the server.
First it will require us to work in yet another language which in addition has a functional/prototype based concept.
A lot of people misunderstood what javascript is because of the similar syntax.
Why not? Performance?
Second javascript is less efficient than Object Pascal/Delphi.
While this might not be such a big issue there is still the question why we should make the server less efficient.
Could be a little less effecient but could be better on production and scalability.
Because of the different concepts of the language and the difficulties in debugging and building it. It will be a pain to work with. Node.js uses C++ but we don't.
Also duct-taping that stuff together will be an horrible job.
Then there is the issue with installation which will require server hosts work more to get soldatserver up and running (no more unzip, chmod and run).
The update procedure will require some thinking and the hosts will need some way to restrict any access to the js files for their customers.
You could embed Node.JS inside soldatserver's directory. With that you have the same procedure.
I think there's no problem with the update procedure.
Hosts restrictions? Would be much better!
The host would be able to configure each server the way it wanted, with the restriction it wanted.
Sure they could but it requires them to modify the server js code or us to implement the most common solution as each update could break their customization.
My concern was that the js files can be overwritten via ftp and then the customer could do weird stuff.
Since we use Object Pascal/Delphi and not c++ creating a plugin for Node.js isn't that easy. It probably requires C++ and Object Pascal/Delphi code compilation with some manual linker calls among other conversion steps.
I don't believe the dev environment setup needs to be more complicated.
Will continue to need Object Pascal/Delphi?
Yeah we will have to use Object Pascal/Delphi in the future as the client is written in that language and we want to share code.
Porting anything to another language means more work.
Let's say this is not an option and move on. If we finally manage to make soldat opensource you are free to fork and try your changes (as long as the license allows it ofc but I don't think that will be an issue).
-
NodeJS is available for different purposes. The main goal is creating web sites with push capabilities (thats why it is Javascript).
There is no point rewriting soldat server in NodeJS. It will be just waste of time.
-
I wish I had seen this topic earlier. It's one of the most unintentionally funny topics I've seen. I hope strack strides against common sense and convention, and makes it big as a Node.JS game developer.
-
I think that he take his nick from this guy: http://blogs.adobe.com/strack/about/ [most related to his talk]
and as I scrolled few sites about Node.js, searching keywords (his nick, game development, server etc) but I found just few random talk about soldat and node.js, probably one of this guy is this "strack".
PS I'm not expert or even beginner of programing so dunno what is this exactly, but I found this site:
https://www.npmjs.org/package/gamedig
and Soldat is selected as a supported game.