3D Browser-based Game Development

I am developing a video game in JAVA, called "Universe Storage". It is going to be a multi-player online browser-based 3D video game. You will control a character who has been accidentally thrown into the future by a company called "Universe Storage". A disgruntled robot will be your guide as you learn to construct your home, go to school, earn money, build and program robots and weapons, and fight in futuristic battles. I am planning to post progress here throughout development, and problems I encounter along the way. Anyone interested in getting involved, providing feedback, beta testing, or obtaining source code, just send me an email to paul@paulscode.com .

This is a progress update for my game. Earlier this week, I did a little research on using OpenGL within a JAVA applet. I came across an interesting 3D browser based game called "Zoltar's Return" (I can't post the link, since I am a new member, so if you want to see more about it, just email me, or google it). It is launched from something called JOGLAppletLauncher. This program has a lot of features I really like, such as simplifying the whole digital signatures and JAVA sandbox thing. I decided to try it out, so I downloaded everything I need to use the applet launcher. I made a simple test program which runs the famous JOGL gears demo as an applet. I know, there are plenty of intelligent folks out there who have done that before, but it was a learning process for me to figure it out for myself.
The next thing I decided to look into was putting a 2D overlay on top of the rendered 3D scene (basically a "heads-up" style overlay). I googled around a bit, and came across an interesting program called "Photo Cube". The source code for the program has a really sweet class in it called CompositeGLJPanel, which simplifies the mixing of JOGL and Swing. I only had to alter the class a little bit to get it working in a test applet, which combines the gears demo with a 2D background and forground.
Both these applets test important concepts I will need for my game. If you would like more information on them, you can post your questions here, or email me directly if you would like the source code.

There are several things that are essential to most games, like processing input, playing sounds, and the like. While I have made a few games in C++ before, I have not ever attempted one in JAVA. Therefore, I think the best way to pick up some of the basic skills I will need for Universe Storage, is to write a simple 2D game in JAVA first. Based on the applet-launcher and CompositeGLJPanel infrastructure I have now, I am going to create a 2D browser game. I decided that, since one of the things I want to have in Universe Storage is the ability to program robots, this test game will be a 2D robot builder game.

This is a progress update on Robot Builder. The basic idea of the game is to create IC chips, then wire them up inside a robot to make it do stuff. It is a little like the concept of an old game I used to play called "Robot Odyssey" (This game was a great way for anyone to learn the basics of logic and electric engineering in a relaxed-pace, fun environment - one of my favorites back in the day. I recommend googling it). I created a class called "Part", which is managed in a class called "PartManager". From the "Part" template, I created the following logic gates: AND, NAND, OR, NOR, XOR, XNOR, and NOT. I also made TFlipflops and SRFlipflops. From my tests they all seem to be functioning correctly, and the PartManager works like a charm. I am now moving on to the graphical components. If you are interested in reading more about electric engineering, Wikipedia has some great information on the subject.

I have been making headway in the graphics for Robot Builder. I discovered two ways to load image files into BufferedImages (which can easily be put into Textures for use in 3D when I finish Robot Builder and work on Universe Storage). One way is (in NetBeans) to put the images into a package, and to get the image in the program, use:

This appears to make the image part of the compiled jar. The other way is to use:

This allows the program to pull the images of the web. I decided the best way for me is to use the URL method. That way it won't take as long to download the applet, and I could potentially display a message to the player while the images are loading. I created a simple template class for drawing animations. From this class I created a simple robot. It doesn't do anything yet, but it is animated.

Today I added a map to the Robot Builder game. It is a really simple 2-layer tile map, with tiles being either solid or not (I'm not going for awesome looks just yet).



If I ever decided to take Robot Builder to the next level: a real, distributable game, I could easily add in a foreground layer, draw a collection of really nice-looking tiles, and expand on the basic functionality I have in place now.
I also completed the code for object movement on the screen and hit-detection to prevent an object from passing through solid tiles. I've run several tests, and everything seems to be in order. I am now ready to move on to the wiring and IC chip creation parts of the game.

Today I created Robot Builder's tool menu, which has two buttons. The first one will open the IC Chip tool. The other will open and close the "Toolkit", which contains all the logic gates. I am also receiving and keeping track of mouse events from the two menu buttons and the robot.
When these interfaces are complete, this is how the game will work:

1) Open the Chip editor to create a new IC Chip
2) Open the toolkit and pull logic gates out
3) Hook them up inside the chip however you like.
4) Save your chip.
5) Click the robot to work on it.
6) Pull the chip out of the toolkit
7) Wire it up inside the robot.

When you are done, sit back and watch the robot go (or not go, depending on how good your logic skills are )

Today I completed the code for bumpers (wall detectors), drive (robot movement), and antenna. I hotwired the robot with a simple wallhugger circuit, using 2 SR FlipFlops:



I am continuing work on the graphics interface for hooking up chips and logic gates. There is still quite a bit of work left to do on this.

I have been asked a few times how the concept of robot building is going to fit into Universe Storage, so I thought I would take a little time to explain it here, in case anyone else was wondering about that. Universe Storage is going to be an economy-driven game. Characters will have skills, which various activities in the game will increase. Higher skill numbers will mean better weapons you can use, more quests you can do, and more valuable things you can make. Robots will be useful for assisting players in combat, obtaining items, or completing quests. It will be possible to construct robots and weapons from parts you make yourself, buy in shops or from other players, or win in quests. Where the "Robot Builder" concept comes into play, is players will then be able to design chips, and wire them up in their robots and weapons. They can then either use the weapons and bots themselves, or sell them to other players who don't have the logic skills to design chips, or who are more interested in other aspects of the game, like leveling other skills, questing, or PK'ing.

I have finished drawing the images for logic gates and chips. I am still working on the code for wiring parts together.



This is a bit more complicated than you might think. The wires that connect parts must be able to dynamically change their length and orientation as the player moves already-wired parts around on the screen. The player will need to be able to move parts and change the orientation of wires to avoid the "birds nest" effect (messy jumbles of wires and parts) that can happen when designing a complicated circuit.

Well, as every developer knows, sometimes you try a path that looks good for a while, but then you hit a brick wall.
I have been trying some compatibility tests with the RobotBuilder program. I have been developing the game from my desktop PC, which is pretty fast, has a fair amount of RAM, and has a nice graphics card. For me, the game runs fast and smooth, exactly how you would expect such a really simple game to run.
However, on every one of my friends' computers, as well as on my two laptops, there are numerous problems. For more than half of the computers trying to run the game, the applet never loaded at all. This problem had a simple fix: updating the JAVA runtime environment. However, then there are more serious problems. It seems that for run-of-the-mill computers with fairly good graphics cards, the game will not crash, but it will run really slow and choppy. With run-of-the-mill graphics cards, computers will not only run slowly, but the game will crash the browser. On one machine, the program actually affected Microsoft Windows so badly, the computer had to be rebooted! I have done a lot of digging into the problem, rewritten some things, streamlined code. Nothing seems to help.
It occured to me that perhaps the problem is not from my code, but in the AppletLauncher technology I am using to launch the game. I had some of my friends run the Zoltar's Return game I mentioned earlier which also uses the AppletLauncher, and sure enough, many of them had problems running it too! The most common problem seemed to be only half the screen being drawn, and the browser eventually crashing.
This leaves me with a couple of options. One, I could simply require the user to have a fast computer with a good graphics card. That, of course, would limit the number of potential players, and could cause problems for people trying to run the game on not-so-good machines. The second option is to do some more research to see if there is a more stable way to run 3D within an applet (any suggestions would be appreciated!). I definitely prefer the second option, because if a tiny little game like RobotBuilder is so resource-intensive, who knows what a full 3D game would require!

I did some research into other methods of running 3D inside an applet, and came across an interesting project called 3DzzD, located at:
http://www.dzzd.net
It has a couple of features I really like, such as working on all versions of Java back to 1.1, and the ability to let the user switch between either software rendered or hardware accelleration modes. Also, the library has a function for loading 3ds files, which is something I am going to need to be able to do in my game. 3ds files are loaded on seperate threads, allowing me to put up a progress indicator, which is also nice.
I ran the demo applets on three different machines, and they seems to run without problems (btw, if a few of you would go try them out and let me know how they run on your computer, that would be awesome).
As nice as it looks, I am having a tiny problem, though. I have been trying to re-create my 3D-gears test applet using the new 3DzzD library, but I do not seem to be able to load any 3ds files I create - only the 3ds files used in the demo programs will load. I even made a really small simple cube model, but it will not load. Tests show the code is getting into an unending loop in render3DObjectMonitor (the place where I would put the progress-bar). The file just never finishes loading. I am not sure if maybe I am creating my models incorrectly (wrong lighting, material, etc).
I am not giving up just yet - I really would like to get this library to work, as it would make things a lot easier down the road. Any help on this would be really appreciated, too, if any of you out there have either had experience with or at least an interest in 3ds files.

I am now using the jPCT 3D engine, which can be found at:
http://www.jpct.net
This library is really awesome. It is compatible with all versions of JAVA, back to 1.1, allows switching between hardware-accellerated or software-rendered modes, and can load .3ds 3D model files (definitely a bonus!)
BTW, if any of you want to know how to make 3ds files, here is what I am doing:

1) First you need to install "Turbo Squid gmax" (it's a free 3D modeling program), located at:
http://www.turbosquid.com/gmax
2) Next, you need the "Quake-3 MD3 exporter beta v1.0 - gmax" exporter pluggin, which you can get at:
http://www.davidhsmith.net/Essential_Tools.htm
3) Finally, you need LithUnwrap, located at:
http://www.sharecg.com/v/5169/softw...per-for-Windows

I simply create a model in gmax, export it to Quake MD3 format, open it in LithUnwrap to add materials etc, then save it as 3ds.
I made some gear models (which I am pretty proud of ), and recreated the gears demo - this time in jPCT.
Go take a look at it: http://www.paulscode.com/source/jPCTGears/
Let me know if it runs slow on your computer or any other issues.

Next, I will look into adding in a 2D overlay (that sounds familiar ...)

I finished writing the code for mixing Swing 2D background and foreground with jPCT.
To see the demo program I wrote, go to:

http://www.paulscode.com/source/jPCTSwingMix/

Let me know if any of you have problems running this applet. I am going to start transitioning the Robot Builder code over to this new framework.

In case anyone went to paulscode.com before and found the gears demo applet not working, I was doing some work on it at the time. I am trying to implement the ability to switch between hardware-accelerated and software-rendered modes. This will allow my programs to be useful to more people. I am using a program called lwjgl to load the applet, which allows me to display a logo and progress bar while the applet is loading. It will also simplify the digital-signature thing, and give me that hardware-accelerated capability, if I can ever figure the darn thing out, lol.