JDBC in Games

Game Play & Game Design
#21

[quote]For a stand alone game I think JDBC is overkill ressource and performance wise. You would need to distribute a database, the JDBC driver and the whole set of JDBC classes. Just too big.
[/quote]
There are some VERY small pure Java embedded JDBC database implementations. PointBase for instance.

The biggest issue for a game IMO is cost. Due to the complexity of implementing efficient SQL handling, JDBC databases don’t tend to be cheap. The two exceptions of course are mysql and PostgreSQL. These however are not small and don’t embed.

Frankly, for a stand-alone game I’d look at something small and simple like JDBM (available on sourceforge.)

#22

We’re using JDBC on both the client and server side for Galactic Village, which is an MMO game.

On the server side, we’ve used Sybase, Oracle, and Postgres (and soon MySql).

On the client side we’ve used Sybase, Postgres and CloudScape. I’m going to be looking at PointBase and MySql for the client as well, but would also be interested in other lightweight, Java-based client-side databases.

We’ve thought about using XML-JDBC drivers to let us read/write XML files (for editing tools and stuff), although I haven’t seen a good, free XML-JDBC driver that I like. Plus we’d have to create an XSD from our database schema, which takes time and effort.

We wrote our own persistence management layer, which is JDO-ish but not JDO-compliant (yet), and looks kinda like bean-managed persistence in EJBs . This has enabled us do true database-swapping, even with some of the databases not being totally ANSI-SQL compliant or having annoying things like names folding to lower-case in Postgres.

I’ve thought about using EJBs, but there’s overhead that we don’t need, so we’re not going to switch to it at this time.

Shawn, I’d be happy to go into more detail if you want to reference Galactic Village in your book! :wink:

#23

BTW, at CGDC we’ll be showing server-side technology that happens to be implemented using JDBC to talk to a VERY fast (and not cheap) database system. (TimesTen for anyone interested, a quick google should give you their website.)

I do recommend however others do what we did, which was first define what we needed in terms of data access functionality and built an Interface. THEN looked at technologies we could implement it with below that “firebreak.” Thus we are not tied only to databases that implement JDBC but can use any technology that meets our (much smaller) functional and (highly intense) performance requirements.

IMO by the time you are done tuning you end up having to do so much system-specific SQL for performance reasons that even using JDBC your code still ends up DB specific. So make your architectural break a level higher.

#24

Hi Brad,
Yes I would like a bit for the chapter, Brad please contact me in email.
Thanks!

#25

[quote]BTW, at CGDC we’ll be showing server-side technology that happens to be implemented using JDBC
[/quote]
Is this “we” the GTG or Sun generally? I.e. is it something that you guys have put together, or are you promoting an internal project from another part of the organization?

I’d just like to triple-underline this statement :). For all the things SQL manages to achieve, being a cross-vendor standard is not, in reality, one of them :). As Jeff says, as soon as you are done tuning (heck, IME almost the moment you START tuning!), you can kiss goodbye to vendor independence.

IIRC I’ve been told this is mainly due to the extreme slowness of the standards process (always the case…) and inadequate extension mechanisms - so most vendors had to add lots of proprietary language features just to keep their software up to date for customer needs. But I’m not a DBA, and I’m just repeating what I’ve heard…

#26

To go in another direction: If you’re going to do something large-scale, networked/distributed, then you might want to leverage EJB technology as well. Entity EJB’s wrap (basically implementation of DAO pattern) the database using using JDBC at the lower levels, and you don’t have to write SQL or JDBC code. The EJB container manages reads/writes for you, and can even manage transactions.

JBoss is a free J2EE environment and comes with okay EJB support, although I’d suggest using WebLogic if you had the money. Not sure what is quality enough for MMOG. In any case, EJB’s give you a managed environment. Either that, or check out JMS. JMS introduces the concept of MBeans (managed beans). Point is, for something large-scale, you need container management, proven scalability and reliability, and all that you might find in the J2EE (fault-tolerance, fail-over, clustering).

#27

EA’s Majestic used BEA Weblogic, IIRC on 7 dedicated j2ee servers (plus others running Oracle and Netscape enterprise products).

Bearing in mind that most of the servers (such as Weblogic, JBoss - even Oracle - etc) are much more than “only a j2ee implementation” (so may be great for MMOG’s but you have to examine each on a case-by-case basis):

On the whole, J2EE sucks for MMOG development. From an MMOG perspective, it’s slow, clunky, full of useless clutter, and ill-equipped to cope with the needs of MMOG development.

This is merely becasue J2EE was designed for a completely different purpose (i.e. there’s nothing particularly slow about J2EE in the environment it was intended for); Majestic, for instance, was much more like an enterprise app than an MMOG (IMHO this has a lot to do with why it failed commercially!) so J2EE was not a bad choice in that situation, technically.

#28

It is a major project of the GTG. The core (and IMO most interesting) part of it is new technology. However it does leverage and integrate with some technologies from the rest of the company.

BTW: I agree 100% with the statement that EJBs and Servlets were designed with enterprise needs in mind, not game execution .

#29

I don’t view DB as something usefull in most games.
My game, for example, would need 200 TB if it would use DB. Without DB it could be 24 GB (hopefully).

Also DB will not decrease development time, if you’d use custom development applications that would have part of game code inside.
More compex games need custom data manipulation, so aside savegame conversions there isn’t much what would create big problems in the next version. (if made) I consider lack of documentation as bigger problem than a outdated custom data format.