Who wants to help make a game?

[Gurm]

Ok folks, I'm working on a game.

I'm dead serious about this.

It's going to be a new MMOG, but unlike Evercrack or Ultima Offline it will be 100% dynamic (using technology based loosely on MUDs and MOOs). No more stagnant economy, or level dichotomy. No more waiting 6 months for new areas to open up. No more paying for a new expansion once a year.

I need a team of dedicated (and slightly insane) individuals.

I need programmers, artists, level designers, game designers, and of course testers (alpha testers for now, there will be an open beta later of course!) of all varieties.

This is an exciting possibility. Am I crazy? Entirely possible. But at the very least we're gonna give this thing our best shot.

Imagine a game universe where things change continually. New construction happens on a regular basis - daily or weekly new areas will open up.

Imagine having ALL the game players online whenever they want to be. No more "pick a server near you".

Imagine being able to make permanent changes to the game world. You set off a bomb, it blows up a building... the building stays blown up until someone fixes it.

Current direction of the game:

- One persistent universe. Yes, there will be multiple servers. But everyone is on all at once. The servers will represent different virtual aspects of the game world. Some servers will run NPC's exclusively, some will run geography (dungeons, etc.), some will provide other functionality.

- Graphics will be reminiscent of Baldur's Gate or DiZablo. 2D sprites with a 3D top-down isometric style.

- Game style is likely to be traditional swords-n-sorcery, although we might move it towards a more Final Fantasy-esque "steam powered" world. Not 100% sure yet, of course.

- Development language is pure Java. Not crapplet Java but real 100% honest-to-god-this-is-a-kickass-language Java.

Additional questions or comments? Direct 'em my way.

gurm42@Hotmail.com (mail and MSN messenger)

gurm42 (AIM and Yahoo messenger)

453460 (ICQ)

- Gurm

[Gurm]

I, too, would really like to see it. I'm just ont convinced that the system wouldn't break on a regular basis as soon as you made a nasty enough change to the class. And how you'd read it in is WAY beyond me, you'd have to do all your own memory management. It just seems, at least on the surface, to go against so many of the improvements in modern programming languages, but maybe we're just missing something fundamental.

Wanna clue us in, Tom?

- Gurm

[Krome]

Here's my input on this project. Not that everyone need to hear it... I'll make it short... cos I myself hate reading crap... :)

I have to stand on what Tom Server was saying. I agree with his understanding on the magnitude of the project task. I personally think that Tom was just reminding everyone the reality and weighing it with dreams. But one other fact seems to weight the outcome of this project. If infact Java is to be used in this project, I don't think this project is going to go anywhere. Sorry for the skeptitism. Java is not practical for a network gaming. It's too slow.

Don't take this personally when I say this. It takes a real genuine management to pull this off. If you can manage who will take care of what and who will take care of what sub-program, then I think you can pull it off. From the beginning of the thread, I did not see such management at work. If it is, he should request a person with specific skill for the available specific task needed. Management is the key to all successes in life. That's all I can say...

[azcodemonkey]

You make a good point Krome.

Gurm, perhaps you should map out what tasks need to be accomplished, or if you aren't sure yourself, ask for someone to help map out a design. You said you're building off another MUD engine, so what would need to take place in order for it to meet your needs? If you know what the specifics are, it'll be much easier to recruit help based on those needs and the developers' strengths.

I thought about it in the shower, and I still can't figure out how you could load a class dynamically in C++. I don't think it is possible. Maybe Tom is mixing semantics. Exporting a class in a dynamic library is much different that what reflection accomplishes. You still need a class declaration in the client app so the compiler knows how much memory to allocate. Sharing data on the heap is not that big of a deal. Discovering new members of a class is.

Tom, please, kill my curiosity! :D

[Gurm]

Java is NOT too slow for network gaming. It IS too slow for the client side. Not because Java as a language is too slow, but because the graphics APIs thus far are.

If C# supports a sufficient amount of reflection, that might be a decent compromise.

I'm not building off a prior engine, I'm building off the theory behind a prior engine. I have a fair idea of what needs to be done, and how to dole out the work, but I was waiting for a substantial amount of interest and volunteers before I started seeing what everyone's strengths were and doling out tasks.

Anyhow, I'm going to try to be available as much as possible in #burningdesigns on dalnet. Anyone who wants to drop in and discuss this is welcome to - especially those who want to help.

If I'm not around, or not saying anything, IM me so my machine makes noise and I will come running.

- Gurm

[Glowstick]

lol

it's Tom Servo, not Server :D

The 'class loader' wasn't written in C++, it was C. And it was all about modules exposing functions, see it as services (as MS would name it now). I just call it class loader coz someone else named it like that i think. I have to find the source code, coz it's like over a year ago I quitted it.

It mainly consisted out of a DLL loader which manages the loading, resolving/updating of entrypoints and calling the other modules back if one does unload. There was also a 'memory manager' which stored the data structures of each module, so they're preserved on unload. If you reload a newer module, it has to use the same data structures. It was pretty simple and only few lines of code, but was pretty robust. Each module announced its type and capabilities (which were a predefined set of constants).

E.g. in case of the MP3 decoder module, it would serialize stuff like the file handle, file position and various info about the file in a data structure and stuff it on the heap. Naturally the written modules should have been written with dynamic (un/re)loading in mind, coz you just cant rip some code out of memory and assume it working again after reload.

It worked this way (using the MP3 player as example). One module is the main module, which was the GUI. It looked out for a MP3 module with a set of functions it needed and 'linked' it. On start of playback, the MP3 module itself looked for an output plugin and a file reader, then started work.

You could make use of a derivation of it, when you write your server, as long the functions are threadsafe. A class ain't much different from a function that works on a data structure. Classes are just easier to use.

As said, you should avoid Java. It's pretty slow, at least my personal experience tell me that. You should also consider using .NET if you don't want to write native. Especially coz you can mix the languages, incl Managed C++. I compiled the Rotor version of it on FreeBSD and it works nice, the FCL ain't ported yet (which is on the way).

These days I don't program C anymore. I fell in love with C# and am writing my own IRC client in it atm (it was supposed to be a bot before) :D

[azcodemonkey]

It makes sense now. Thanks, Tom.

I've been thinking about it still, it would take a lot of work to mimic reflection in C++, but it is probably doable. I'm not volunteering... lol. It would be an interesting case study, tho. It would probably kill any performance you would hope to get from C++.

Managed C++... (shudders) ewwwww! ;)

[Krome]

Originally posted by Tom Servo

lol

it's Tom Servo, not Server :D

OOPS! :) My apology... kekeke :p

[Gurm]

Ahh Tom, this isn't what we're talking about. But you knew that, right? We're talking about reflection, and you're talking about dynamically hot swapping modules with similar exposed methods - something which while tricky and extremely useful, is not reflection by a long shot.

- Gurm

[Oogle]

Sorry if I'm not too familiar with the Java side of things, but..

Is dynamic class loading achieved via RMI? If so, isn't RMI a Java version of RPCs? I'm familiar with MS's version of RPCs, COM/DCOM. COM can be done through any MS supported language: C++, C#, VB, etc. What are the differences between RMI and COM? Advantages? Disadvantages?

From what I understand, both of these technologies achieve the same thing: Distributed computing. To me, that means:

• Loading/unloading components/classes on the fly
  Accessing components/classes from basically anywhere
  No need to recompile old components
  

If those are some of the goals of this project, why should one technology be favored over the other? Is it because of actual technological limitations or user preference/experience?

Definitions for the acronymically challenged:

RPC - Remote Procedure Call (very old stuff)

CORBA - Common Object Request Broker Architecture (more current technology)

RMI - Remote Method Invocation

COM - Component Object Model (MS version of CORBA)

DCOM - Distributed Component Object Model (another MS technology)

[Osiris]

This is the best project ive heard of since sliced bread. This sounds simalr to an online game I use to play if only I could remember its name ah well.

EItherway id love to join the team.

[azcodemonkey]

Oogle, what Gurm is trying to accomplish is quite different than RMI. Invoking a method remotely is only half the battle. Reflection is an API in the java.lang.reflect package. What it allows is the construction of new classes and modification of those classes' fields. It allows for on-the-fly discovery of the class interface, where as in RMI/RPC you have prior knowledge to the class interface you are working with. In COM/CORBA/et al, it is the onus of the component developer to publish and keep their interfaces immutable as to avoid breaking the client. In reflection, you aren't a fully aware of the classes capabilities, but you can discover what it can do during runtime.

I think that is the largest consideration when choosing a platform for this project. I do think it would be possible to write something in C++ to acheive reflection, but it would probably perform no better than the Java implementation. .NET support reflection, too, and from what I've seen, .NET performs much better than Java.

[Oogle]

Neat. This reflection stuff looks like magic :)

I guess my only question now are use-cases and scenarios with regards specifically to this project? How would the main program handle these "unknown" classes? Will it query the class about what it does, and then "change" itself accordingly to use the unknown class' methods? Man, I wish there was a design doc to explain how this stuff fits in.

I love it when programs program themselves. That leaves me with less to do!

[Gurm]

There is obviously a level of tinkering which WILL break the system. A core set of classes must be left alone in order to maintain stability.

And of course in order to keep track of things, there will of necessity be a large database of currently loaded classes and objects based on those classes, in order to make sure you're not trying to dynamically load up a class that has a dozen critical objects already created.

And yes, obviously you can't just make a new class that nothing references and expect it to magically DO something.

An example would be that you want to make a new room. Each room is an object of type room. But THIS room is going to be a new type of room, of a derived class named "transporter_room". You make the new class, then you figure out how the user gets there, and hook the exit of the previous room to this new room.

All of this sounds pretty mundane, until you realize that the engine has no idea what a "transporter_room" is, and will have to go load it up off the disk, or over the network, or wherever you specify for a location.

Now, let's say that nobody uses the transporter room because the transporter function is broken, for whatever reason. You modify the class, recompile it, and tell the engine to reload it. Of course you have to go through and make sure that objects based on it get refreshed (and perhaps in some cases destroyed and re-instantiated), which is why you maintain the master table.

But you can see how powerful this can be. You don't need to know ANYTHING about the class. Not its interfaces, not its methods, not its members. You just pull it off the disk, and start using it.

The program can query this new class to learn its interface if you so choose... or, if you're actively maintaining this program as it runs (as would be the case here) you can simply begin using those interfaces, since they are known to you.

- Gurm

[Oogle]

But you can see how powerful this can be. You don't need to know ANYTHING about the class. Not its interfaces, not its methods, not its members. You just pull it off the disk, and start using it.

The program can query this new class to learn its interface if you so choose... or, if you're actively maintaining this program as it runs (as would be the case here) you can simply begin using those interfaces, since they are known to you.

Does "maintaining" mean modifying? If so, wouldn't reflection be unnecessary then? If you (not the program) are actively maintaining the main program to coincide with new or modified classes, couldn't you just use RMI or IDL to accomplish the same thing? Both ends (main program & new/modified classes) ARE basically "agreeing" to a set of known interfaces every time you modify the main program, right?

Besides that, it seems to me like you'll end up with this problem:

• Create new classes.
  
• Modify the main program to use those classes.
  
• Add more classes
  
• Remodify the main program to use those classes.
  
• Change some classes
  
• Remodify the main program AGAIN to be compatible with those classes.
  
• etc.
  

Doesn't this defeat the idea of "plug n' play" components? If outside dev. people wanted to contribute and you allowed them to make their own classes and derive their own custom interfaces, you'd have to constantly keep maintaining the main program to adjust and use those custom classes. Eventually you'd get into a situation where outside devs. are complaining about your main program's lack of support for their classes and interfaces. Components should be made such that the outside dev. can make basically whatever class they want without having to ask you to modify your main program.

There are 2 ways that I know of that can remedy this:

1. Define a strict set of KNOWN interfaces that all devs must follow (i.e. the CORBA way)
   
2. Have the main program query the class for its interfaces and adapt on the fly (via reflection)
   

I've always thought that the 2nd way was impossible until weenur showed me this cool reflection stuff. Keep in mind that in order to make the 2nd way work as efficiently as possible, you'd have to also implement some AI algorithms to make the program learn about unknown classes.

[Oogle]

I found this neat article on reflection from the java web site.

http://java.sun.com/docs/books/tutorial/re...lect/index.html

It mentions that reflection should only be used "if you are writing development tools such as debuggers, class browsers, and GUI builders". So does that mean that the player will also be able to make their own stuff while they're playing, using the game itself as an IDE? That would make for some awesome (albeit unbalanced) scenarios. It would also make it unneccesary to include a lot of AI, because the player himself/herself is describing and using the stuff.

[h71y6]

i haven't seen a single soul on the channel... am i going in at the wrong time or something?

[Gurm]

*ahem* Yes, those suggestions about reflection are just that - suggestions. As for continually updating the code, yeah. It'll happen. The idea is NOT to allow outside developers to create code. The idea is to be able to add to the game without shutting it down, or to be able to fix bugs without rebooting the server.

- Gurm

P.S. I _am_ open to suggestions for alternate ways to do this. The problem is that any non-reflection-based solution involves reading in massive amounts of data files. And every time you want to change how those data files are interpreted, you have to recompile the entire server. This is thoroughly time-consuming... UNLESS you set up a scripting language of sorts with very simple commands that build into bigger commands... and then you're basically building an interpreter and reflection. So why not just use what's already native?

[Oogle]

As for continually updating the code, yeah. It'll happen. The idea is NOT to allow outside developers to create code.

Allowing other devs to add to programs is just one advantage to componentization. Other more important advantages include easy upgradability and maintainance. I strongly recommend that you don't strive to make your program monolith in nature. It'll be built like a house of cards. As it get larger, it'll be harder to upgrade and it'll have a higher chance of failure.

The idea is to be able to add to the game without shutting it down, or to be able to fix bugs without rebooting the server.

Unfortunately, I realized just now how inexperienced I am with real-time systems when I did a google search on this idea. This problem isn't new. But the solution requires more knowledge than my BS degree education can currently provide. (pun intended :))

I _am_ open to suggestions for alternate ways to do this.

I did find some tech papers that deal with the topic. They're fairly high level, but it should give you an idea of what you're dealing with.

http://citeseer.nj.nec.com/update/485958

http://citeseer.nj.nec.com/update/433167

(Just click on the pictures to move to the next page)

[Glowstick]

If will program it for the .NET framework, I might consider taking some minor jobs on it, just to get my time passed.

[Gurm]

Ok, I'm on hiatus on Cape Cod until Monday (visiting friends/family), but I'll still check my e-mail if anyone needs to get in touch with me.

I looked into .NET last night (Border's cafe - a stack of reference manuals and a large Espresso. Gotta love it!), and it DOES seem to do the sort of reflection we need, albeit in a similar manner to Java 1.0 - meaning that we'd have to write an API around it, and precompile that API.

I'm more than willing to consider C# or J# as a viable alternative to Java. It would even allow us to write the client in C#, which would allow for code pushing and dynamic client updates as well.

Anyone else with an opinion on this - please either post here or e-mail me! We need to get the platform nailed down, and it seems that disparate schedules have prevented us from having meaningful dialogue in-channel.

Once we nail down the platform, however, we will be able to communicate more efficiently - the first engine prototype we build will have a chat, note-posting, and task logging system in it.

Oh, and the tentative working name for the engine, in case I failed to mention it before, is the "Persistence Engine".

- Gurm

[BeeJay]

Would someone be willing to direct me to a good example or two of this style of game (that I can try -- hopefully at least with a free trial :))?

I have thoroughly enjoyed following this discussion. Not being someone who plays games very often, I am having trouble picturing the end result of this project. I don't even know if I have played this type of game before.

Of course I realize this project will try to create a more advanced game than has been done before. So some roughly similar examples would be nice.

[Vlad]

As an experienced mmorpg gamer (I've practically played them all) and a programmer, I wouldn't mind helping you as well. However, this is a fairly major project, and without a financial backing, it wont be easy. Either way, I would love to help.

[Glowstick]

I would also program the server platform for the .NET framework. Especially coz this leaves more freedom to the programmers. If someone wants to code stuff in Fortran.NET he shall do so. Same for me, refusing to program J# or Java. ( :D )

I think also there's Pascal.NET, so the Delphi programmers feel comfy.

[Gurm]

I have looked into C#, and its reflection DOES seem sufficiently robust to support what we are looking for. However, some wrapper code would have to be written which already exists in the Java 1.x API. I'm not opposed to writing this, especially if it would let us target the increased speed of the .NET platform. Additionally, this move would eliminate the need to have the server written in one language and the client in another. Thus, if we wanted to enable load-sharing on the client side, writing the client in C# as well as the server would certainly facilitate that process.

I _do_ still need to discuss it with the entire programming team. Folks, give me a ring on messenger, or drop into the channel. We all need to talk, and I know that working out disparate schedules is a pain, but it DOES need to happen.

- Gurm

[Gurm]

Ok, here's the skinny.

Everyone who wants to be on this team, report to:

http://pub34.ezboard.com/bburningdesigns

Sign in, introduce yourself in the greeting thread, and we'll get this show on the road.

Also, ongoing realtime chat is happening in:

#burningdesigns on Dalnet.

- Gurm