Thread: Modern Server Design - Discussions about

Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27
  1. #11  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Arham View Post
    It isn't really a strong argument for or against something if it being in current servers or successfully in practice. We know that almost every production server does not have a great codebase. If it's currently used in our community is irrelevant. What we should do is take inspiration from the larger realm of software programs.



    I lack knowledge to speak in regards to Multithreading. I just think (based on threads that I read) it is too much work for not much gain. 2,000 players actions being processed every 600 milliseconds (which is a lot of time) does not justify the need for multiple threads.

    Side note, I remember once upon a time, for fun, I wished to try making a server using Concurnas which, like Kotlin, is a JVM language with an emphasis on multi-threading and concurrency.



    Quite the opposite really. Build systems literally exist to not require much effort. If the argument of "simple run script is not provided" was even valid to begin with (I don't think it is), you can just run the gradle / mvn commands in your run script. Hell, even the run scripts would be easier with build systems than without (who wants to define all those classpaths when gradle build can do it for you?).

    Idk, don't see your point here really.



    I don't get what is trying to be said here. The topic is "scripting" but the description transformed into "language choice" rather than "scripting or not?" A lot of the community has ditched non-JVM languages for scripting due to the lack of true interoperability. Like, the lack of IDE support, the lack of "I call you, you call me," etc.

    Now, as for scripting itself, I assume you mean the whole plugin system? Different terms. The community in general recognizes that plugins are beneficial, but its mostly been about who will take up the work in making a server to such a state where one actually uses servers with plugin systems. Notable projects include Apollo and RSMod.



    Just because testing is "extra work" doesn't mean we can just dismiss it as development overhead. It is an even bigger production overhead having code that is untested. Unfortunately, Unit testing is not that prevalent in our community due to the coupling nature of most of our sources. Just try making a mock Player without networking and see what happens.



    SOLID principles in mind while developing will lead to a much more flexible codebase. Refer to Unit testing response for a benefit with following SOLID principles whilst doing our object oriented development.
    I was asking about current servers to see if anyone had successfully implemented it and if it actually worked in practice (not just in theory). Lots of good points here, I think you misunderstood my point about build systems. I am not saying they make it more difficult to build, I am saying it is more difficult for the average person to build it and therefore there is a higher barrier to starting with servers. Running a bat file is a lot simpler than learning about gradle tasks or pom files.

    On the subject of scripts you are right to say plugins is probably a more appropriate term to use, I did not feel the need to clarify the issue of language choice because as far as I am aware there are not many servers that are actually used that the core is not written using Java. I don't really understand your point about non JVM languages? RSMod is the only popular exception I can think of and that uses Kotlin which is a JVM language? I have written one in C myself but know for a fact that most servers are written with Java and tend to be extended with an interpreted language if they are
    Reply With Quote  
     

  2. #12  
    Banned

    Join Date
    May 2016
    Age
    55
    Posts
    1,137
    Thanks given
    565
    Thanks received
    600
    Rep Power
    0
    Quote Originally Posted by Fire Cape View Post
    I think you misunderstood my point about build systems. I am not saying they make it more difficult to build, I am saying it is more difficult for the average person to build it and therefore there is a higher barrier to starting with servers. Running a bat file is a lot simpler than learning about gradle tasks or pom files.
    IMO not having these require the user to learn more about what they are getting into & starts them off better by making them use an IDE.

    I started trying to program back when no one really knew what an IDE was, when IDE's came around they were a bit intimidating only because I've never put time into learning about one or using it.
    Once I was more or less forced to make the change with my own practices I felt like it was the best choice and helped me advance faster than ever.
    This may have been where there was a "leap" in standards as well since most people started using an IDE that gives all kinds of tips and provides tools to help you program therefore people who were not using an IDE sooner most likely got left behind.
    If someone can't properly learn how to use an IDE than programming is probably not for them.

    As said by others the standards really are still low in the RSPS scene overall, if you know the basics you can bring in a decent amount of players & there are plenty of decent bases released that helps.
    This is judging from an overall stand point there are very few servers that hold their code to a top notch standard technically they'd rather just pack in more content/etc.
    Reply With Quote  
     

  3. #13  
    (Official) Thanksgiver

    Arham's Avatar
    Join Date
    Jan 2013
    Age
    23
    Posts
    3,415
    Thanks given
    7,254
    Thanks received
    1,938
    Rep Power
    3905
    Quote Originally Posted by Fire Cape View Post
    I think you misunderstood my point about build systems. I am not saying they make it more difficult to build, I am saying it is more difficult for the average person to build it and therefore there is a higher barrier to starting with servers. Running a bat file is a lot simpler than learning about gradle tasks or pom files.
    But my point was that even making the BAT/SH files are easier using a build tool. All one has to do is install Gradle (just like they installed Java) and run the BAT/SH file that would simple read, say,
    Code:
    gradle build
    Code:
    gradle run :core
    It's a lot easier than:
    Code:
    title Compiling
    "C:\Program Files\Java\jdk1.7.0_51/bin/javac" -cp ./data/libs/*; -d bin -sourcepath src src\com\rs\*.java src\com\rs\cache\*.java src\com\rs\cache\loaders\*.java src\com\rs\cores\*.java src\com\rs\events\*.java src\com\rs\events\impl\*.java src\com\rs\game\*.java src\com\rs\game\item\*.java src\com\rs\game\minigames\*.java src\com\rs\game\minigames\clanwars\*.java src\com\rs\game\minigames\creations\*.java src\com\rs\game\minigames\duel\*.java src\com\rs\game\minigames\pest\*.java src\com\rs\game\minigames\roman\assault\*.java src\com\rs\game\npc\*.java src\com\rs\game\npc\combat\*.java src\com\rs\game\npc\combat\impl\*.java src\com\rs\game\npc\corp\*.java src\com\rs\game\npc\dragons\*.java src\com\rs\game\npc\dungeonnering\*.java src\com\rs\game\npc\familiar\*.java src\com\rs\game\npc\fightcaves\*.java src\com\rs\game\npc\fightkiln\*.java src\com\rs\game\npc\fightpits\*.java src\com\rs\game\npc\godwars\*.java src\com\rs\game\npc\godwars\armadyl\*.java src\com\rs\game\npc\godwars\bandos\*.java src\com\rs\game\npc\godwars\saradomin\*.java src\com\rs\game\npc\godwars\zammorak\*.java src\com\rs\game\npc\godwars\zaros\*.java src\com\rs\game\npc\kalph\*.java src\com\rs\game\npc\nomad\*.java src\com\rs\game\npc\others\*.java src\com\rs\game\npc\pet\*.java src\com\rs\game\npc\qbd\*.java src\com\rs\game\npc\sorgar\*.java src\com\rs\game\player\*.java src\com\rs\game\player\actions\*.java src\com\rs\game\player\actions\mining\*.java src\com\rs\game\player\actions\runecrafting\*.java src\com\rs\game\player\actions\thieving\*.java src\com\rs\game\player\content\*.java src\com\rs\game\player\content\agility\*.java src\com\rs\game\player\content\agility\courses\*.java src\com\rs\game\player\content\construction\*.java src\com\rs\game\player\content\dungeoneering\*.java src\com\rs\game\player\content\dungeoneering\rooms\*.java src\com\rs\game\player\content\magic\*.java src\com\rs\game\player\content\pet\*.java src\com\rs\game\npc\slayer\*.java src\com\rs\game\player\controlers\*.java src\com\rs\game\player\controlers\castlewars\*.java src\com\rs\game\player\controlers\events\*.java src\com\rs\game\player\controlers\fightpits\*.java src\com\rs\game\player\controlers\pestcontrol\*.java src\com\rs\game\player\cutscenes\*.java src\com\rs\game\player\cutscenes\actions\*.java src\com\rs\game\player\dialogues\*.java src\com\rs\game\player\dialogues\tutorial\*.java src\com\rs\game\player\quests\*.java src\com\rs\game\player\quests\impl\*.java src\com\rs\game\tasks\*.java src\com\rs\io\*.java src\com\rs\net\*.java src\com\rs\net\decoders\*.java src\com\rs\net\decoders\handlers\*.java src\com\rs\net\encoders\*.java src\com\rs\tools\*.java src\com\rs\utils\*.java src\com\rs\utils\huffman\*.java src\com\rs\vote\*.java 
    title Finished compiling!
    pause
    Quote Originally Posted by Fire Cape View Post
    I don't really understand your point about non JVM languages?
    I was addressing these points:

    Quote Originally Posted by Fire Cape View Post
    Scripting - Ever since Hyperion I remember sophisticated scripting systems based on Ruby, Python or some variant, and now recently Kotlin. The original design decision seems to be based on RAD (rapid application development) principles, ruby and python are considered more simple, interpreted, less barriers for content writing etc, however they do not appear to have been taken up much and they seem like they have been passed over for writing Java instead.
    The reason why we have generally ditched those (namely Jython and JRuby) was the lack of IDE support for those frameworks in their interoperability with the core.
    Attached image
    Attached image
    Quote Originally Posted by MrClassic View Post
    Arham is the official thanker!
    List of my work here!
    Reply With Quote  
     

  4. Thankful user:


  5. #14  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Arham View Post
    But my point was that even making the BAT/SH files are easier using a build tool. All one has to do is install Gradle (just like they installed Java) and run the BAT/SH file that would simple read, say,
    Code:
    gradle build
    Code:
    gradle run :core
    It's a lot easier than:
    Code:
    title Compiling
    "C:\Program Files\Java\jdk1.7.0_51/bin/javac" -cp ./data/libs/*; -d bin -sourcepath src src\com\rs\*.java src\com\rs\cache\*.java src\com\rs\cache\loaders\*.java src\com\rs\cores\*.java src\com\rs\events\*.java src\com\rs\events\impl\*.java src\com\rs\game\*.java src\com\rs\game\item\*.java src\com\rs\game\minigames\*.java src\com\rs\game\minigames\clanwars\*.java src\com\rs\game\minigames\creations\*.java src\com\rs\game\minigames\duel\*.java src\com\rs\game\minigames\pest\*.java src\com\rs\game\minigames\roman\assault\*.java src\com\rs\game\npc\*.java src\com\rs\game\npc\combat\*.java src\com\rs\game\npc\combat\impl\*.java src\com\rs\game\npc\corp\*.java src\com\rs\game\npc\dragons\*.java src\com\rs\game\npc\dungeonnering\*.java src\com\rs\game\npc\familiar\*.java src\com\rs\game\npc\fightcaves\*.java src\com\rs\game\npc\fightkiln\*.java src\com\rs\game\npc\fightpits\*.java src\com\rs\game\npc\godwars\*.java src\com\rs\game\npc\godwars\armadyl\*.java src\com\rs\game\npc\godwars\bandos\*.java src\com\rs\game\npc\godwars\saradomin\*.java src\com\rs\game\npc\godwars\zammorak\*.java src\com\rs\game\npc\godwars\zaros\*.java src\com\rs\game\npc\kalph\*.java src\com\rs\game\npc\nomad\*.java src\com\rs\game\npc\others\*.java src\com\rs\game\npc\pet\*.java src\com\rs\game\npc\qbd\*.java src\com\rs\game\npc\sorgar\*.java src\com\rs\game\player\*.java src\com\rs\game\player\actions\*.java src\com\rs\game\player\actions\mining\*.java src\com\rs\game\player\actions\runecrafting\*.java src\com\rs\game\player\actions\thieving\*.java src\com\rs\game\player\content\*.java src\com\rs\game\player\content\agility\*.java src\com\rs\game\player\content\agility\courses\*.java src\com\rs\game\player\content\construction\*.java src\com\rs\game\player\content\dungeoneering\*.java src\com\rs\game\player\content\dungeoneering\rooms\*.java src\com\rs\game\player\content\magic\*.java src\com\rs\game\player\content\pet\*.java src\com\rs\game\npc\slayer\*.java src\com\rs\game\player\controlers\*.java src\com\rs\game\player\controlers\castlewars\*.java src\com\rs\game\player\controlers\events\*.java src\com\rs\game\player\controlers\fightpits\*.java src\com\rs\game\player\controlers\pestcontrol\*.java src\com\rs\game\player\cutscenes\*.java src\com\rs\game\player\cutscenes\actions\*.java src\com\rs\game\player\dialogues\*.java src\com\rs\game\player\dialogues\tutorial\*.java src\com\rs\game\player\quests\*.java src\com\rs\game\player\quests\impl\*.java src\com\rs\game\tasks\*.java src\com\rs\io\*.java src\com\rs\net\*.java src\com\rs\net\decoders\*.java src\com\rs\net\decoders\handlers\*.java src\com\rs\net\encoders\*.java src\com\rs\tools\*.java src\com\rs\utils\*.java src\com\rs\utils\huffman\*.java src\com\rs\vote\*.java 
    title Finished compiling!
    pause


    I was addressing these points:



    The reason why we have generally ditched those (namely Jython and JRuby) was the lack of IDE support for those frameworks in their interoperability with the core.
    Yes but end users are not the ones writing the bat files. Gradle is easy to use when you know what to do, but it will never get more simple than running a single bat file. I think Greg has already pointed out there's no reason why the process couldn't be made simpler for newer users just have a shortcut to a Gradle run task or something. I know you're probably thinking why do we need these noobs who can't even use a build system but they won't be noobs forever if they realise what they can do with java. If they never start they will never get any better.
    Reply With Quote  
     

  6. #15  
    (Official) Thanksgiver

    Arham's Avatar
    Join Date
    Jan 2013
    Age
    23
    Posts
    3,415
    Thanks given
    7,254
    Thanks received
    1,938
    Rep Power
    3905
    Quote Originally Posted by Fire Cape View Post
    Yes but end users are not the ones writing the bat files. Gradle is easy to use when you know what to do, but it will never get more simple than running a single bat file. I think Greg has already pointed out there's no reason why the process couldn't be made simpler for newer users just have a shortcut to a Gradle run task or something. I know you're probably thinking why do we need these noobs who can't even use a build system but they won't be noobs forever if they realise what they can do with java. If they never start they will never get any better.
    That's what I'm saying... You supply a BAT / SH file with that inside to the end user...
    Attached image
    Attached image
    Quote Originally Posted by MrClassic View Post
    Arham is the official thanker!
    List of my work here!
    Reply With Quote  
     

  7. #16  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Arham View Post
    That's what I'm saying... You supply a BAT / SH file with that inside...
    Yeah sorry I misread your point.
    Reply With Quote  
     

  8. #17  
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Quote Originally Posted by Fire Cape View Post
    Multithreading - Discussed in detail in the past, in particular with respect to the player updating and packet processing in parallel, would this still be beneficial?
    Best to benchmark and find out

    Quote Originally Posted by Fire Cape View Post
    Do any current servers do this?
    Well Apollo still has it... ScapeEmu private fork does, not sure if it was included in the public release or not.

    Quote Originally Posted by Fire Cape View Post
    Does it introduce too many locks and synchronization issues?
    I don't think so. Most of the updating code is read-only, and writes are only made to the player's own object. So it isn't too difficult to make it run across multiple threads safely.

    Another thing fairly easy (and worthwhile imo) thing to multi-thread is path finding (particularly useful in revisions where all path finding is done on the server-side).

    Quote Originally Posted by Fire Cape View Post
    Build systems (Gradle, Ant, Maven) are they too intimidating for new users? You used to be able to just download a server and run it without much effort as long as you had Java, obviously to build it you needed to set the PATH variable but there was a low barrier to development.
    I don't think the PATH variable was a low barrier, many people struggled with it!

    I don't think setting up Gradle, Ant or Maven is that difficult in comparison to the JDK - the process is basically the same: download an installer/zip, install it and then modify your PATH. gradlew and mvnw make it even easier, as you just need a working JDK and it'll download Gradle/Maven for you and then invoke them.

    With my current project, I'm planning to do binary releases for people who aren't programmers to use. These won't depend on any build system at all.

    Quote Originally Posted by Fire Cape View Post
    Now most servers require an IDE because they do not ship a simple run script.
    I don't think pushing people towards IDEs is a bad thing, given how difficult it is to write Java without one (mostly cos of the import verbosity).

    Quote Originally Posted by Fire Cape View Post
    Do you think the growth of servers is suffering as a result of the initial learning curve being too high to attract new blood?
    I think there are a sufficient number of technically capable developers in the community these days (though it'd be nice if there were more). I think the main reason for the decline of RSPS is OSRS, which is related to players, not RSPS developers.

    The fact that nobody cooperates doesn't help though, I think it's all become far too commercial...

    Quote Originally Posted by Fire Cape View Post
    Scripting - Ever since Hyperion I remember sophisticated scripting systems based on Ruby, Python or some variant, and now recently Kotlin. The original design decision seems to be based on RAD (rapid application development) principles, ruby and python are considered more simple, interpreted, less barriers for content writing etc, however they do not appear to have been taken up much and they seem like they have been passed over for writing Java instead.
    The following quote is something I wrote on Discord a while ago about plugins, which is somewhat relevant to this point:

    @Tomm#0017 so... I think to understand my thoughts on plugins, we need to go back to when I was working on servers like rs2hd and the very initial release of Apollo. Back then development worked a bit differently in the RSPS scene - very little use of version control, people tended to just work on a server, post a code dump when it was finished and then abandon it. Although there were Git hosting services like SF, Assembla, etc. (and perhaps even GitHub itself had started by then?), GitHub wasn't that popular and none of the existing services had as much as a focus on collaboration and things like pull requests, forking or code reviews. Furthermore, the average standard of an RSPS programmer was significantly worse than it is now, and so was the code quality of all the servers. And I discussed this at length with Blake at the time, and we basically decided that a plugin architecture was the best way to go - you'd have a core team of decent, trusted devs who could commit to the core repository, and everyone else who wasn't necessarily trusted to have direct commit access could extend the server with plugins instead - so it'd solve the collaboration problem. Furthermore, the plugins could be in a simpler scripting language than Java (Python in rs2hd, Ruby in Apollo), which would make it easier for inexperienced programmers. The core server itself could be distributed as a binary (back then many people struggled to even configure their PATH variable), and there could be an online repository of plugins that people could download and enable/disable. So really a lot of the problems it solves, I think, were actually to an extent not technical problems, but the social problems of the scene and the state of collaborative tools like GitHub.

    In the subsequent years since I worked on rs2hd/Apollo, I've slowly come to realise that a plugin system does add additional technical problems. For example, how do you decide the exact API boundary? If too much is in the core, the plugin system isn't flexible enough (and even Jagex have this problem, with their content developers often claiming that they need to wait for "engine time" to be able to solve a particular problem). If too little is in the core, then plugin developers have to implement a lot more code themselves, and duplicating code between plugins might reduce their ability to interoperate with each other (e.g. imagine if two different plugins had to reimplement various functions for manipulating the player's inventory).

    Another problem (at least for rs2hd/Apollo) is mixing two languages, which caused the IDE experience (e.g. autocompletion) to be less good. However, this point is less important, as it is fixable - e.g. use the same language for both the core and plugins (e.g. like Bukkit did with Minecraft) or one that it is compatible (e.g. Apollo's new Kotlin plugin system).

    Refactoring also becomes more difficult with plugins (especially post release) as you have to maintain API compatibility and any sort of refactoring you want to do to that API boundary will take a long time to do, as you have to get everyone who is working on plugins outside of your main repository to upgrade before you can deprecate the old API, and you'll have to go through the hassle of having two copies of the same API running simultaneously for a while. In fact, this argument is quite similar to the arguments that come up when people discuss using several different repositories vs a monorepo, and I think there's definitely a parallel to be drawn here. (And no surprises, I'm also a big fan of monorepos).

    I think some people in the scene also misunderstand what plugins can be used for, or at least rs2hd's/Apollo's implementation of them. A common misconception back in the day was that plugins would allow content to be updated while the server was still running, but at some point in rs2hd's development and before I even started on Apollo I basically realised all the problems this causes (you have to deal with state - what do you do about variables that are added, removed or changed by the plugin that is reloaded, for example?) and I basically decided to ignore the problem by not supporting reloading at all.

    I think something that has come up with Apollo is that certain plugins ultimately need to depend on each other, which basically negates the benefits of doing out-of-tree development and the idea of having distinct plugins in a repository that you can pick and choose - they ultimately end up becoming intertwined with each other anyway. e.g. even something simple like the attacking dummies plugin needs to depend on whatever plugin implements certain parts of combat, as it needs to know the correct attack animation to use for the weapon that you're holding.

    Now, if we go back to the original social reasons for creating the plugin systems, I think that 10 years later the situation has changed. GitHub is significantly more popular than it was, and people are more familiar with it. You don't need to collaborate by trusting people with commit access - they can fork the repository, make their changes independently, submit a pull request, which you can then review to ensure they didn't go too crazy, and finally merge in. The simpler language argument goes away in two ways: (1) on the whole, RSPS programmers are better than they used to be and (2) to solve the IDE integration problems, modern servers like StrongHold are using the same language (or at least a compatible language, in the case of Apollo) for both the core and plugins, so the simpler scripting language for noobs argument becomes invalid.

    In reality, if a plugin-based server ever took off, I think we'd eventually see people settle around a common group of plugins that are always installed for base functionality like all the skills, combat, and so on. In general, I think the "pick and choose" argument isn't really necessary, and at that point it's much easier to just stick all that base functionality in a single monorepo. At that point, you can start blurring API compatibility and the exact API boundary, making development a bit more flexible as you can refactor things freely.

    So I think my chosen solution these days would to not have a server be plugin-based, and just develop the core and content in the same repository. Now, this isn't to say that they need to be mixed up like spaghetti - you can still architect things properly to split the server up nicely, use Gradle/Maven modules/subprojects, and so on - mainly because all the social issues can be solved in a different way these days, and plugins do actually impose additional technical problems. And I think a single repo also solves the social issues, but without introducing new technical problems.

    Now, there is one point I haven't addressed, and it's one I don't actually particularly care about because I'm a bit of a purist when it comes to RSPS development. But I think one good use case of plugins would be for people who are interested in custom content, rather than emulating what Jagex has done. As at that point the people developing the core server might not want any custom content, and would want to leave that to their users. And at that point, plugins still make sense imo.
    Quote Originally Posted by Fire Cape View Post
    Unit testing - Discussed rather recently, seems beneficial in respect of testing container systems and reducing dupes - Has this been successfully used in practice or is it just additional development overhead that we can probably skip?
    Well, there are trade-offs involved and some code is harder to unit tests than other code (e.g. I suspect testing content would be rather difficult), but for some code I think it definitely makes sense to unit test and I've definitely found bugs with it in my projects.

    Quote Originally Posted by Fire Cape View Post
    Object orientation - A common criticism of many modern servers is that they are very complicated in terms of design. Object orientation when used properly can provide great benefits and reduce unnecessary code duplication. However we do run the risk of creating artificial and inane systems (blakeman8192 pointed this out a while back). How many objects is too many?Runewiki points out around 83 client opcodes in the 317 server (there are probably more). If we have a system of event listeners that is 83 distinct classes (assuming one per class) you could probably significantly reduce in some cases (for example sharing banking ones or option interaction) however it is still quite complicated and you risk your server getting overrun by a gazillion classes where it isn't clear what is what.
    or you risk a 10,000 line client.java

    I don't think I'd get hung up on the exact number of classes (and fwiw modern clients have quite a few) and trying to minimise or maximize it. It's better to make them where they make sense. If you end up with a lot, I don't think it's a big deal as your code should be understandable if you follow OOP best practices.

    Quote Originally Posted by Greg View Post
    Proper deployment with docker, CI etc... I will agree is far more work than a "simple run.bat". There's no reason a developer couldn't include a gradle run task bat with ./gradlew build run for simple deployment on a windows vps. I assume there's a Maven equivalent, and as far as I'm concerned it's not worth bothering with Ant.
    https://docs.gradle.org/current/user...on_plugin.html

    The application plugin is good, then you don't need to have a build system to run the server in production at all (which is really the way things are meant to be done).
    .
    Reply With Quote  
     


  9. #18  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Thanks for the thorough and interesting response as always Graham.

    Just to clarify on the low barrier for development thing. Back when I started a long time ago being able to run my own server got me into programming (because I wasn't interested in programming I was interested in the game) the game helped me develop the switch and appreciate the technical difficulty too. I do think that many people get overwhelmed with how much there is to do, the IDEs, the build systems, the jdk it's all very unfamiliar noise to a new person. But yes as you, Greg and Arham have pointed out there are good ways around that while still retaining the system - they're just not done very much currently!

    Oh and as for the OO thing no one wants the days of 10k client.java hahahaha (actually laughing in real life imagining winterlove right now) I just think the naming and packaging can become very complicated when there are so many things to consider.
    Reply With Quote  
     

  10. #19  
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Quote Originally Posted by Fire Cape View Post
    Back when I started a long time ago being able to run my own server got me into programming
    I think that's true for a lot of people, but I also don't think there is any denying that private servers are ultimately fairly complicated systems that require knowledge of a wide range of topics (networking, databases, task scheduling, cryptography, compression, binary encoding/decoding, data structures, path finding, threading, etc. - I've probably missed loads).

    That said, I do understand that everyone starts somewhere (and working on RSPS definitely made me a much better programmer).
    .
    Reply With Quote  
     

  11. Thankful users:


  12. #20  
    Super Donator

    Join Date
    Apr 2020
    Posts
    21
    Thanks given
    6
    Thanks received
    9
    Rep Power
    21
    Quote Originally Posted by Corey View Post
    Not true, most of the top servers are buggy as fuck because they've been worked on by 5 trillion different shit devs
    This is true however if you go and read most server's farewell area or similar designation you would see most people leave due to this factor. Now i totally agree with the 5 developers lol.
    Reply With Quote  
     

Page 2 of 3 FirstFirst 123 LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. server design discussion
    By Shadowy in forum Requests
    Replies: 2
    Last Post: 10-26-2014, 03:19 PM
  2. Discuss best server design
    By Chelsea Grin in forum RS2 Server
    Replies: 34
    Last Post: 03-22-2013, 10:08 AM
  3. Replies: 1
    Last Post: 03-14-2012, 01:00 AM
  4. server designer
    By wizzyt21 in forum Tools
    Replies: 2
    Last Post: 12-14-2009, 03:26 AM
  5. Discussion about Silabs.
    By Raid in forum RS2 Client
    Replies: 6
    Last Post: 11-18-2007, 01:43 AM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •