Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  JGN vs. Darkstar  (Read 9379 times)
0 Members and 1 Guest are viewing this topic.
Offline lhkbob

JGO Knight


Medals: 32



« Posted 2007-09-25 15:06:56 »

I'm just looking into networking libraries and I was wondering how the uses and features of JGN and Darkstar compared.  I've heard on these forums that JGN boasts about 1 million messages/sec, but it seems to be a library designed to handle mostly networked game events.  Is Darkstar capable of handling and transmitting similarly fast-paced events, or would it be better to use Darkstar as a hosing system and switch over to JGN for the actual game networking?

Offline sunsett

Senior Member




ribbit!


« Reply #1 - Posted 2007-09-25 16:40:16 »

I think a "versus" comparison is probably not a good idea here since they each aim at different audiences.  I don't want to speak for Darkstar (particularly since I'm the author of JGN) but from what I've seen and used it is primarily focused towards MMO style games and provides some really great features to that style of game.

JGN is more focused as a general purpose and lower-level game networking API that provides commonly used functionality to game developers in order to simplify the networking aspect of game development.  For example, in just a few lines of code you can synchronize scenegraph objects in your game between a client and server (and the server will validate the synchronization events and broadcast to other connected clients).

A game simply needs to define an implementation of GraphicalController (there are already some simple implementations for jME, jME-Physics, Swing, and GTGE) that actually handles the application and generation of synchronization messages.  See below for the jME implementation as an example:
http://captiveimagination.com/svn/public/jme-networking/trunk/src/com/captiveimagination/jmenet/JMEGraphicalController.java

Also, here is an example utilizing the FlagRush tutorial from jME to synchronize the motorcycles across multiple clients:
http://captiveimagination.com/svn/public/jme-networking/trunk/src/com/captiveimagination/jmenet/flagrush/

This is one of many enabling features of JGN.  Also, I'm currently writing a massive extension to JGN to support MMO games (since I'm currently writing one) but for classical MMO games Darkstar is probably going to be your most reliable option at the moment.  Also, there is some interesting functionality that Darkstar has that JGN has no plans in the near future to support.

I'll leave it to Jeff or someone else here give more details on the benefits of Darkstar.
Offline lhkbob

JGO Knight


Medals: 32



« Reply #2 - Posted 2007-09-26 05:37:07 »

I'm needing a mix between mmo and more standard instance-based multiplayer sessions.  I envisioned using darkstar for the hosting and connecting and most metagame server-client transactions and JGN for the faster paced game events.  I was mostly wondering if either could be used for both metagame and game events.  For metagame, I'm referrring to chat messages, locating hosting, viewing statistics and other transactions that aren't necessarily time dependent.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sunsett

Senior Member




ribbit!


« Reply #3 - Posted 2007-09-26 14:01:52 »

Yes, JGN has full support for all of that.  However, to be fair I believe Darkstar is probably competent at accomplishing all of those tasks as well.
Offline lhkbob

JGO Knight


Medals: 32



« Reply #4 - Posted 2007-09-26 21:20:37 »

From the sounds of things, JGN was built to be fast and efficient, although I'm don't know anything about its scalability.  I know Darkstar loves to tout its scalability and mmo features.  These features are needed for my current work, but I also need the efficiency that JGN would offer.  Does anyone know how Darkstar compares to JGN in raw performance ability?

Offline sunsett

Senior Member




ribbit!


« Reply #5 - Posted 2007-09-26 21:49:44 »

Stability and scalability is definitely something to bear in mind when making a decision.  Darkstar has the backing of Sun and JGN has the backing of several developers writing games...doesn't really compare, but one big benefit of JGN over Darkstar I would say is that if you find a bug you're likely to get a fix in less than a week (sometimes overnight).  We don't compare to Darkstar in terms of support or probably even stability, but if you want raw performance I'm willing to back JGN's performance against any networking solution. Smiley

To sum up, please use JGN and help us make it more scalable and stable.  Tongue
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #6 - Posted 2007-09-27 06:38:33 »

Hi

Darkstar has 2 communication techniques, in one, a client talks directly to the server, at this point the server stars a transaction, with all the scalability, and performance implications that come with that. The other way is using channels, as long as you have not set the server to listen to the channel, messages are not much more than bounced right back at the other clients on the channel, thats about as fast as is possible Smiley.

I've not tried JGN, so I can't really compare the two either.

Endolf

Offline Conzar

Junior Member




There is nothing common about common sense


« Reply #7 - Posted 2007-09-27 14:11:01 »

Are there any benchmarks for Project Darkstar?  The basic test is creating an object on a client -> sending it to the server -> server unpacks it and then -> sends it back to the client.  There is a byte buffer of size 10bytes inside the object that is being transfered.

JGO claims to do this at 0.001ms.  What about Darkstar?   

BTW, I saw Darkstar's booth at AGDC but didn't stop by (regretting that right now especially b/c they had that nice mini-lecture thing going on ... didn't have enough time on the show room floor).

Ubuntu
Offline sunsett

Senior Member




ribbit!


« Reply #8 - Posted 2007-09-27 15:28:58 »

Perhaps I'm just in the dark (maybe a little pun intended) here, but what games are currently written and available using Darkstar?  Are there any production quality games out there using Darkstar for their games or even any big companies relying on it for an up-and-coming game?

We can talk all day about Darkstar being cool because Sun is pushing it, but nothing speaks louder than examples.  That might be a good way to show how great Darkstar is.
Offline Conzar

Junior Member




There is nothing common about common sense


« Reply #9 - Posted 2007-09-27 16:44:50 »

Taken from the FAQ on their homepage (www.projectdarkstar.com)
Quote
Who uses Project Darkstar?
NCSoft has been prototyping a new game using the SGS

A great many smaller developers are taking advantage of the Darkstar opportunity right now as well.  Project Darkstar fundamentally changes the economics of massively multi-player online game development to open it up for small developers as well as large ones.

Ubuntu
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lhkbob

JGO Knight


Medals: 32



« Reply #10 - Posted 2007-09-27 17:56:12 »

Thanks for the help, you've given me much to think on.  I still need to look carefully at the api's to see which best fits my needs.  Plus our multiplayer setup has yet to be finalized (although it's close), which is definitely  going to have an impact on my decision.

Offline sunsett

Senior Member




ribbit!


« Reply #11 - Posted 2007-09-27 18:52:52 »

Would anyone be interested in working with me to resolve this question once and for all?  If someone is willing to work with me to create a basic (unbiased) game and then use both Darkstar and JGN I would be happy to write all the JGN code for it.  This question has been raised on various forums and this would help to give concrete evidence to support one or the other.
Offline Conzar

Junior Member




There is nothing common about common sense


« Reply #12 - Posted 2007-09-27 20:21:16 »

Quote
For example, in just a few lines of code you can synchronize scenegraph objects in your game between a client and server (and the server will validate the synchronization events and broadcast to other connected clients).

Can someone explain this more in detail? 

For instance ... say you have 2 players in a room.  You also have a room object that contains all the players in the room. 

Each player is associated with a client (in the real world).  If there are 2 players (A&B).  If A's position changes, how is that change propagated through the system ?

If this were RMI, there would be a server class that has the room object.  A Player would connect and be added to the room.  Any other Players in the room would be then sent to the Player that just connected (via method calls on the Player Object ... also note, that both the Room and Player objects would extend RemoteObject.  Any time a player updates their location ... this information is propagated throughout the system (basically any time the system is getting the location of a Player).

Also, what is the performance difference between auto synchronization (like above) then writting our own method of doing it (player sends location to server, server then broadcasts that out to appropriate players)?

Thanks for ur help

Ubuntu
Offline sunsett

Senior Member




ribbit!


« Reply #13 - Posted 2007-09-27 21:28:45 »

In the case of JGN this is taken care of for you via the synchronization system.  Refer to the FlagRush tutorial link I referenced above for more details about how that is set up, but essentially you tell the SychronizationManager that you want to "register" an object (the object would most likely be your scenegraph object) and then how frequent you want to send updates out.  This is primarily beneficial for realtime games where you have so much movement going on all the time that if you were to go the RMI route you would have to be sending messages just as fast as you possibly can to keep up and then it wouldn't be fast enough unless you've got some mediation thread that is actually updating your RMI object based on your scenegraph object.

The idea is to simply "register" your object on the client that is responsible for the positioning of this object and it will send positional information down to the server on the frequency you specify.  The server receives those messages and validates them (which is another thing you really don't have in RMI by default) and if it validates it is broadcast to the other clients to apply to their scenegraph.  If it doesn't validate a message is sent from the server to the client telling it the position where the object should be.

While we're on the topic of synchronization another HUGE advantage to JGN is that it prefers UDP communication for synchronization messages since it doesn't matter if some get missed along the way.  Further, there is something called a RealtimeMessage (that all SychronizeMessages in JGN extend) that keeps you from managing useless updates.  Classically you could queue up updates to be sent from one machine to another (or even updates that are queued up upon receipt to be processed on the recipient) and if you get any system pause or any performance hit or even an unability to send messages because of lag you could potentially stack up multiple positional updates for an object when really you only care about the most recent.  Classically you'd have wasted time processing and applying all of the old updates (I've seen this happen even on Battlefield 2 when I lag)  and you'll see yourself sliding forward back into "now" but in JGN a RealtimeMessage only one of a specific "id" (or object reference) can exist in the queue and so you can add 5000 every second and it simply replaces the old one with the new one and you never have to worry on either side of having to process old synchronization messages.  UDP if you're not familiar with it is really great for this type of work because using TCP can often exhibit much more lag given that you are using guaranteed delivery, so when you send 500 messages 500 messages are guaranteed to get there no matter what.  UDP will happily drop messages along the way which is beneficial in scenarios like this.

It's important to point out that I'm not suggesting UDP is better than TCP though.  JGN is about leveraging both in the places where they are beneficial.  For important information that MUST arrive it is always best to use TCP when possible.  However, JGN does support a CertifiedMessage that guarantees delivery on both UDP and TCP (sort of necessary in the way JGN abstracts the type of server being used) and even provides a Receipt message letting you know that the message was successfully received on the remote machine.

JGN is an easy to use framework but a LOT of thought has gone into the way it was written and providing support for common game development needs.  I think this is starting to become obvious as point-by-point comparisons between RMI and JGN are examined.  Yes, RMI can work for what you are doing, but if you have the ability to run an arbitrary server I don't see any advantage that RMI provides over JGN.
Offline Jeff

JGO Coder




Got any cats?


« Reply #14 - Posted 2007-09-28 18:02:45 »

Okay so, here's how I see it:

JGN:  Object level communciation.  Lower requirements server side.  Great if all you want is communication

Darkstar:  Byte packet level communication.  More server requirements, a lot more functionality.  Great if you need/want that functionality.
The other thing Darkstar brings you is some industry standardization.  We have big industry players using it now (NCSoft, Gaia Online, etc),  integration with other key game service components like Perpetual's backend,  and are developing a market for hosting providers.  That last can be very important to small developers.

Performance is for the most part a non-issue.  We haven't gone through a tuning phase yet because we are finishing multi-node now but there is no reason why performance doing the same *kinds* of operations (pure channeled message passing) should be markedly different in the long run.
Darkstar *does* push for near linear scalability by adding new nodes to the system.  I honestly don't know what JGN does there.

RMI: A straw man.  It ain't designed for games.  Don't use it for anything where latency is going to be an issue.

For the latest Darkstar information see the sister Darkstar forums at www.projectdarkstar.com

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline sunsett

Senior Member




ribbit!


« Reply #15 - Posted 2007-09-28 18:44:06 »

JGN:  Object level communciation.  Lower requirements server side.  Great if all you want is communication

True JGN focuses explicitly on the "networking" aspect of games and doesn't attempt to be the juggernaut that Darkstar tries to be, it is quite misleading to say that all it does is communication.  Further, JGN DOES support byte packet level communication.

I heard quite a while back on NCSoft's evaluation of Darkstar.  Have they officially decided to move forward using it?   Roll Eyes

In shear number of features Darkstar probably blows JGN away, but I can say there are some very powerful features that JGN has that Darkstar can't touch.  JGN is about simplicity to the developer while providing all the power to accomplish their networking goals.  Also, there's no reason you couldn't use Perpetual with JGN as well.  Hosting providing is a great feature and one that JGN will never attempt to compete with Darkstar on, but that's because I don't believe it's a front that a networking engine has any business touching.

There is a major extension being developed for JGN that provides clustering, fail-over, and redundancy functionality in addition to data storage backing for MMO games.  This is a massive project I've been undertaking in my spare time while developing my own MMORPG that uses it.  It will still be a few months until that is publicly available, but even without this extension JGN in the core has features that do not inhibit "nodes" the same way Darkstar does (and even allows you to create your own architecture).

One of the greatest features of JGN over Darkstar is that it does not force you into some pre-defined architecture but rather provides you all the low-level tools you might need and even provides you with some extensions should you choose to use them.  This is where I'll tie back to my preliminary statement that Darkstar and JGN have different market focus.  JGN is all about the developer and enabling them to write network games however they see fit while helping to hide some of the complexity.  Darkstar does much in this respect too, but in many ways forces you to use their architecture.

Both have their strengths and weaknesses and a decision to use one over the other should be based on how closely your game's architecture falls in line with the architectural decisions made for the respective framework.

Can you give a little bit of clarification of what you mean by Darkstar bringing industry standardization?

Jeff, I've actually done quite a bit with Darkstar and take a little offense at a statement like your opening argument about JGN as I don't believe you ever took me up on my suggestion to even take a look at it.
Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2007-09-29 03:49:19 »

I'm sorry you took offense.  I tried to hit the high points and focal points.

I didn't mention that JNAG has been ported to Darkstar, and does the object level over Dakrstar channels, either.

We don't feel we force  much of any architecture  on a game, we're hardly a game engine.  We do require you write your server code in an event driven style with fairly short events.  Thats about it that I can think of.  In return, we take mono-threaded code and make it scale out massively across a large scale back-end automatically.  We  load balance, and we fail-over.  We also make the back end logic automatically persistent and gaurantee referential integrity.

In general, I am afraid that such general characterizations as you have given above can devolve quickly  into flame war and  opinion and thats not at all where I wish to go.  Your proud of what you've built.  I'm proud of what we've built. Thats as it should be.

People should take a good look at the technologies and what they offer both in terms of functionality  and in terms of market place.  On our end we are more the just a technology, but a technical initiative.   We are trying to redefine the market for massively mult-iplayer online games in a way that opens it for small developers.  If we are successful, thats another thing to consider.

Once they have done their homework, then they should make an informed decision.  partisan voices will be partisan and thats the sum total of it.

*fine*



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline sunsett

Senior Member




ribbit!


« Reply #17 - Posted 2007-09-29 20:06:55 »

I agree, a flame-war is not beneficial to either side and I apologize for my part in working that direction.

Definitely we are both going to be defensive of our own products and if we didn't agree with the way they were written we obviously wouldn't have written them that way. Wink

People should take a good look at the technologies and what they offer both in terms of functionality  and in terms of market place.  On our end we are more the just a technology, but a technical initiative.   We are trying to redefine the market for massively mult-iplayer online games in a way that opens it for small developers.  If we are successful, thats another thing to consider.

In many ways that has been my goal as well with JGN.  However, somewhat on a more general level my idea was to reduce the complexity of adding network support to games and get all the complex logic out of the game itself and into an abstraction API that handles it for you.  I have high ambitions in the MMO realm as well, but definitely have not accomplished as much as Darkstar has at this point.  Darkstar's goals are much broader than mine though and I respect the desire Sun has to go beyond just the software aspects of an engine to helping with the hardware ramifications of the servers necessary.  It's a large step in the right direction toward helping indy projects have a potential of being successful with broader scoped games.
Offline Conzar

Junior Member




There is nothing common about common sense


« Reply #18 - Posted 2007-09-30 15:53:12 »

As for as the Indie Developer ... ProjectDarkStar I thought wasn't designed for small systems.  In fact, this quote is from DarkStar's FAQ

Quote
Please note that the development server  (also called "the SDK server") is not intended for production use.

A full production level SGS back-end takes a machine room with a number of hosts and sophisticated interconnect.  The intent of the SDK server is to allow the game developer to write and prove his or her SGS application code without needing such a machine room.   The SDK server will run on a single host, but does not support many of the SGS production features such as multi-node operation and production level administration.

A server room is a huge barrier to entry for any small indie shop.  Does JGN have such requirements?

Ubuntu
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #19 - Posted 2007-09-30 19:31:13 »

Part of the point of SGS, the way it can farm out the work between nodes, means that it's possible to sell game hosting, like web hosting is sold now. That means that indie developers don't need any hardware of their own. It has always been said that you *can* run it on a single node if you wish, but that removes the redundancy and scalability that SGS provides. To scale across multiple nodes, depending on the amount of data that is needed, gigabit network might do the job, but only for a small number of nodes. As your data increases in complexity and size, faster, lower latency node interconnects are needed.

Endolf

Offline sunsett

Senior Member




ribbit!


« Reply #20 - Posted 2007-09-30 19:35:39 »

Wow, I hadn't seen that before.  With such a requirement (or maybe just strict recommendation) that looks to alienate the majority of the indy projects currently being developed for Java.  Perhaps that is taken out of context though or that has changed?

Quote
A server room is a huge barrier to entry for any small indie shop.  Does JGN have such requirements?

Not at all.  JGN is extremely light-weight so you can make your games as bloated as you like.  Tongue

JGN really adds very little weight on top of the NIO functionality of Java and attempts to smooth the development of networking through use of an OO approach to network versus the raw communication requirements that NIO puts on your shoulders.  However, you can still do raw data packets even in the OO approach that JGN uses.  Like I said, it's designed to be flexible and cater to whatever the developer may want to accomplish, and as I've heard some crazy ideas I did my best when developing this framework to not make any assumptions on what the developer would want to do.  Conversely, I did add extensions on top of the core functionality to simply common tasks though so you really get the best of both worlds.
Offline sunsett

Senior Member




ribbit!


« Reply #21 - Posted 2007-09-30 19:41:51 »

Part of the point of SGS, the way it can farm out the work between nodes, means that it's possible to sell game hosting, like web hosting is sold now. That means that indie developers don't need any hardware of their own. It has always been said that you *can* run it on a single node if you wish, but that removes the redundancy and scalability that SGS provides. To scale across multiple nodes, depending on the amount of data that is needed, gigabit network might do the job, but only for a small number of nodes. As your data increases in complexity and size, faster, lower latency node interconnects are needed.

That's a valid point, but in my scenario, I'm developing a MMORPG game and I'll be starting with a single server that I'm going to manage through a company like 1and1.  The great thing here is that when I start to reach the limitations of the single server I can simply apply the image to another server and adjust my server space to universe allocation (meaning that specific areas of the universe are designated for specific servers but also provide fail-over to others).  In addition, the system I'm developing takes into account that certain areas of space may at some times get a LOT more traffic than others, so the system I've been developing dynamically takes traffic into account and will adjust 3D space allocation accordingly (meaning that more than one server could share an area or that the area is reduced in size and allocates the trimmed space to other servers to decrease load until the traffic trims back).  However, this is all just an extension to JGN and though it's quite complicated to code, it's still freakishly light-weight.
Offline lhkbob

JGO Knight


Medals: 32



« Reply #22 - Posted 2007-09-30 21:01:43 »

sunsett, you had mentioned earlier someone to do a game test with both darkstar and jgn to see how they compare.  For our project, both solutions seem to be applicable and useable (although depending on a choice, I'd just to have to focus a little more work somewhere else).  Since the comparison is also useful for me, instead of just the community, I'm interested in writing my game for both api's in which case I could be able to give you the comparison you so desired.  However, I must admit, my project wouldn't be a simple test case in which case it might inadvertently favor one api over the other.

Offline sunsett

Senior Member




ribbit!


« Reply #23 - Posted 2007-09-30 22:39:31 »

That sounds great.  Feel free to post on the JGN forums if you have any questions as you go.  I'm not too concerned about it being biased as the likelihood is that it would be in favor of JGN since it's so darn easy to use. Wink
Offline Mr_Light

Senior Member




shiny.


« Reply #24 - Posted 2007-10-01 02:09:39 »

That's a valid point, but in my scenario, I'm developing a MMORPG game and I'll be starting with a single server that I'm going to manage through a company like 1and1.  The great thing here is that when I start to reach the limitations of the single server I can simply apply the image to another server and adjust my server space to universe allocation (meaning that specific areas of the universe are designated for specific servers but also provide fail-over to others).  In addition, the system I'm developing takes into account that certain areas of space may at some times get a LOT more traffic than others, so the system I've been developing dynamically takes traffic into account and will adjust 3D space allocation accordingly (meaning that more than one server could share an area or that the area is reduced in size and allocates the trimmed space to other servers to decrease load until the traffic trims back).  However, this is all just an extension to JGN and though it's quite complicated to code, it's still freakishly light-weight.

that gives all kind of overhead, if you have 100 games running on that backend you can for the same price or cheaper have onsite ppl keeping it up redundancy in hardware  etc. With that one server and growing you haven't got redundancy nor someone to perform tasks 24. Also you don't have up front costs. If after 3 months reality hits and your game isn't catching on, etc. you have the cost of your server, setup cost for the rack, etc. And that all even less relevant if your like me, I like coding software engineering, NOT system administration. I'd pay extra not to be bothered with it. Perhaps I got the wrong impression but your making it sound like darkstars approach is bad or something while I see only plusses.

I wonder how darkstar handles isolation, can jeff shine some light on that.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #25 - Posted 2007-10-01 06:46:52 »

Hi

Isolation in terms of what?, nodes being isolated from one another?, isolation of games? (SGS is also designed to host multiple games in one environment, again, for hosting services companies or larger studios who have already created 1 SGS back end), isolation of the client from the back end mid game?

Endolf

Offline Conzar

Junior Member




There is nothing common about common sense


« Reply #26 - Posted 2007-10-01 12:59:10 »

Quote
Also you don't have up front costs. If after 3 months reality hits and your game isn't catching on, etc. you have the cost of your server, setup cost for the rack, etc. And that all even less relevant if your like me, I like coding software engineering, NOT system administration. I'd pay extra not to be bothered with it.

Um ... what are you talking about here?  You don't actually have to buy a server ... there are hosting services that you can rent an entire server or u can buy a server and co-lo it.  Its cheaper to just rent it initially.  So if ur game doesn't take off ... u just cancel the service. 

The Darkstar project requires someone that knows the system plus a room full of servers right.  Its my thought that right now there are a lot less sys admins that are familiar with Darkstar which means that their prices are gonna be much higher then just doing a standard co-lo or rent ... and the monthly cost for renting the extra servers is gonna be huge for indie devs.

Ubuntu
Offline sunsett

Senior Member




ribbit!


« Reply #27 - Posted 2007-10-01 13:56:07 »

Mr. Light, if you like Darkstar's approach that's great, but realize that JGN offers the same potential it just doesn't force you into anything.  You're welcome to use JGN in any way you see fit.  You can start out with hosting it through your home network and using DynDNS for all I care.  Tongue

I was simply explaining the approach I'm using to get my game out there.

My statement was to simply state that the choice is yours.  A big distinction that should be made between the two is Darkstar ultimately is out to make money.  There's nothing wrong with that and in many ways you get a lot of features you would otherwise not get, but JGN is a true open-source project.  I will probably never make a dime off of it, but I'm developing because I need it for my own games and I see a need in the community for such a framework.  If that need ever goes away I might be a little sad for all the work I've put into JGN, but I'll happily switch to something better that I don't have to maintain.  I haven't seen anything come close to the simplicity and power that JGN provides though, so until the next re-write of Darkstar is released I think I'm safe. Wink
Online Riven
« League of Dukes »

JGO Overlord


Medals: 783
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #28 - Posted 2007-10-01 17:38:24 »

Quote
Darkstar's approach that's great, but realize that JGN offers the same potential

Oh come on... I really hope that was only very poor wording?

The two really can't be compared. It's like: what is better: a FPS shooter or a MMORPG


Both parties can endlessly show their strong points, point eachother at the weak points or react to misinformation by stating their own thing luckily doesn't have this 'awful requirement'.

The only fair comparison is that Darkstar is aimed at the heavy blah blah blah blah blah blah

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline sunsett

Senior Member




ribbit!


« Reply #29 - Posted 2007-10-01 18:48:48 »

hehe...I will also state an advantage of using JGN is that Riven contributed a lot of assistance in its early development as well. Wink
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (15 views)
2014-08-28 18:26:30

CopyableCougar4 (25 views)
2014-08-22 19:31:30

atombrot (38 views)
2014-08-19 09:29:53

Tekkerue (33 views)
2014-08-16 06:45:27

Tekkerue (32 views)
2014-08-16 06:22:17

Tekkerue (20 views)
2014-08-16 06:20:21

Tekkerue (29 views)
2014-08-16 06:12:11

Rayexar (66 views)
2014-08-11 02:49:23

BurntPizza (42 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!