Page 2 - 3D Browser-based Game Development

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.

Ouch, I would not want to write an algorithm for that, let alone attach it to a gui. I wonder if its already been done? Oh well, I can't wait to see how it turns out.

I do know that this has been done at least twice before. It was done for the game "Robot Odyssey", which I mentioned in my earlier post. It was done even better in some software I used in college on real-life programmable IC chips (I don't recall the name of the software off hand). Unfortunately, a little searching the web didn't revealed any useful source code on the subject, so it looks like I get to reinvent the wheel
The algorithm really isn't too bad. Basically the idea is, every connection will be two right-angles (two horizontal, and one vertical line):

The height of the vertical line is the difference in y-value of the two connected pins. The player will be able to drag the vertical line (like resizing the vertical edge of a window). The length of each horizontal line will be the difference in x-value between its corresponding pin and the vertical line

Hi Paul,

I'm enjoying this thread, I'll be interested to see how you approach the problem of integrating Robot Builder in the final game.

Keep it up!

B.

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.

Hi

I have a website
http://www.game4tress.com
and i can provide the means for you to test your game online.
You just have to secure your files and give me what you want/need to post in my web site and i'll post it with your name and the information you want.
(In the future, my web site will allow users to post their games, for free, and manage their info throw a login, but for now i don't have my web site working with registered users)
if you are interested, my e-mail is:
app_developer@sapo.pt

Best Regards

Ricardo Furtado

No thanks, I have a considerable amount of web development experience, as well as a good relationship with a software company I used to work for. I won't have any trouble hosting the game when it gets to the point where I need a game server. Also, on my website http://www.paulscode.com/ I have already designed a system for managing the project and releasing progress information, downloads, and source code.