Coding Issue: Java 1.1 vs. 1.2

[Mark_Everson]

It seems to me that we should advantage of the new stuff in Java2 fairly soon. 1.2
will allow us to use Java2D, Drag'n'Drop, floating point math optimizations, increased speed for synchronized methods, and other features. Also, I think at some point we will have to bite the bullet anyway and switch over.

I know there are playtester browser problems if we do this. It will also make it difficult to post demos of the sub-games (diplomacy, or government or military) for people to play with. Perhaps we can allow people to download exes, since most playtesters will be wintel-based anyway. For others we can set them up with the JRE (Hopefully it'll actually work at some point).

Please think carefully about this. I don't claim to know all the answers, but its a big decision and we should think about it. If all/most of the more experienced programmers disagree I will certainly take their words for it.

What do you programmers both in and outside the project think?

-Mark

[JimC]

My personal opinion is move to JDK1.2 ASAP, but the stuff I'm doing at the moment isn't version specific, so it doesn't affect me very much.

Don't forget, we're aiming at a market 1-2 years into the future, and the later we leave switching, the more difficult it'll become.

If people don't have JDK1.2 compatability now, then they should be thinking about upgrading anyway (such is the pace of progress).

I've had first-hand experience with the numerous, minor but annoying bugs that come from switching a completed project from 1.1 to 1.2 (mainly down to the java.util.Vector class which has changed completely, not an issue unless you try to Serialize it).

Jim

[Vanguard]

If you are looking at a 1-2 year timeframe for completion, switch now. Why get deeper in than you have to when it will just increase the chances of problems later.

But the changes in 1.2 aren't that major and Java is, after all, fairly easy to maintain. So you can wait, if you've already got everything firm.

[Rong]

I just heard about this project yesterday, so bear with me for my ingorance. On the other hand, I have been working with Java professionally for 3 years. I belive I know a thing or two about Java.

Java 1.1 vs. 1.2

You definitely want to go the 1.2 route. Java 1.1 is incomplete as a platform. For any serious programming, you'd have to resort to third-party toolkits (e.g. JGL) to get the job done. I haven't played with 1.2 long enough to make a judgement, but it's going in the right direction.

Applet vs. Application

I saw this discussion popped up somewhere. Believe me you don't want to do applets. Aside from the norious browser java support, you also have the issue of having to download large jar files every time you start the applet. If clash is to have any decent graphics, that could go out of hand. Also there are security restrictions of the sandbox model that would seriously cripple the development, e.g., network play, or even writing to local file system. Forget about signing the applet, it's more trouble than its worth.

Finally, I have a question. Is this project going to be open source? If the answer is yes, here is my formal request to join the development team. If not, have you thought about how the licensing issue could work out on such a project cooperatively developed over the net?

[Mark_Everson]

Rong:

Yeah, I think you're right on both points. We need to do a little more thinking, but its my best guess we should try to go to 1.2 fairly soon. On the App question, I'm worried about the same issues on Applets, but we did also discuss running the Applets locally so the download problem would only be there the first time.

On your questions:
We are de facto now open source, but hope to be able to license the final product . If there are profits to be divided we will have to work out a fair way to do that. I will post soon on this point and see what people think. I will have to bite the bullet and talk to a lawyer at some point on all the details, but I'm not ready to shell out serious cash for that consultation just yet.

My notion is to close at least a portion of the source (but it would of course still available for all the project members) when Clash starts to resemble a game your average person might want to play. Right now, if you commit to the project I will send you what we have of my old code.

If you are interested in joining the project we would be very glad to have you. Just read over the stuff on the web site and poke around here in the topics of interest. When you've figured out what you'd like to do, email me and let me know. JimC and F_Smith are currenly working on coding various things, and we hope to accelerate the coding very soon when we have a few more design details nailed down.

Even if you don't join the project, feel free to comment or criticise what you see up here.

-Mark

[F_Smith]

Hi, Rong:

We'd love to have you!

I'm a network programmer with CSC, been working in Java for 2 years. I'm only peripherally aware of 1.2, so I'm not sure exactly what to think about the version question -- esp. in regarding distribution questions. I'll certainly go along with the majority, but I'm leary of jumping before 1.2 is a household standard, esp since the migration should be rather simple.

But maybe that's because I focus mostly on distribution of working code. I come from a world with both feet squarely in the new 'distributed' computing model, and our general game plan is to make sure that everyone can use the software without anything special having to be installed on their client machine. I'm nervous about going back to 'executable' distribution, personally.

Which unfortunately means I'm not fond of 'applications' -- perhaps it's just a personal bias. I prefer applets running away. The industry's move to 'thin client' architecture is going to be swift and irresistable, I think. Within a few short years, cable modems (and perhaps Internet2?) will blow the old download time worries away.

The old 'licensed executable' model of software development is just not a good way to make money. 'Distributed' applets are far and away more profitable. 'Origin' games, here in Austin, currently has 100,000 subsribers playing "Ultima Online" for $10 a month. $1 million a month.

Now *that* is a real business model . . .

[Vanguard]

Interesting. You're doing it all in Java? I would think that this would be an, um, ambitious Java project. And from your last post I assume you are planning to do it by Distribute-and-Compile rather than Compile-and-Distribute. Do you think there will be any performance issues?

Also, will it be pure Java or do you plan to go native for stuff like pathfinding?

[Mark_Everson]

Hey Vanguard:

Yeah, well we're um ambitious and perhaps not too bright . Actually, on the distribution thing we're not sure what exactly to do yet. For wintel machines it could just be an exe for all we know right now...

But we are shooting for pure java so we can hit all the niche markets, and run Clash on our kitchen appliances :J) if we want to.

In my early version of the game, which is missing a lot of stuff of course, I can crank a turn in 1 sec using a JIT compiler. That's on an out-of-date P133. I think 20s/turn running flat out will be easily achievable with the full developed package and a P3/500.

-Mark

[F Smith]

Naw --

Oracle 8i is an *ambitious* Java program. Oracle claims that will replace Windows.

We're just out to make a simple game . . .

[F Smith]

Oh, and applets are "compile and distribute". Just distributed the same way that television is -- right to your home.

It's kinda like 'pay per view' v. going to Blockbuster video.

[JimC]

Applets vs Applications:

BIG DEAL!!!!!

Simple solution: code everything independently; the major differences between Applets and Applications are security, IO and sound, so:

- write an interface with methods to be called for all security, IO etc. operations

- whenever the program needs Applet/Application specific code executed, have it call the interface

- write separate Applet and Frame containers that implement these abstract methods in their own specific ways

- run the program either way....

btw to new team members; hi, my name is Jim, I'm based in the UK, I'm a Comp. Sci student; I'm relatively new to Java (~1 yr experience) but have been using C++ and Assembly since I learned to walk.

re - performance issues; I've had this discussion several times already; maybe I should start a separate thread based on it - as long as we aren't going full-out RTS then the performance issues will be minor. If you can be bothered, search out my long-winded technical answers in one of the other threads (I forget which one).

JimC

[Mark_Everson]

Jim:

Whats your take on doing 16-bit graphics with Java? Dominique would really like it, and I think it would be a good idea if it won't bog down the speed too much. Any thoughts? We need to pick a general tile graphic spec Soon.

Thanks,
Mark

[F_Smith]

Jim:

I'd like to disagree, if I may. There's a huge difference in architecture possibilities.

The most critical part of any large program, like we're doing, is in the initial architectural design. Bad choices now will limit what we can do later in ways we can't even foresee now.

And there's a *huuuge* functionality difference between applets and applications. Check out the thread I've started on other Java games for examples of what applets can do. Applications are the 'old' way of programming. Thin Client architecture/Distributed apps (applets) are an entirely new breakthru, and allow a level of program quality that is just not possible in 'installed' applications. You won't believe what is now possible, that wasn't before.

For example -- do we plan to force players to aquire new versions of the software somewhere else (buy it at a store) or do we plan to allow them to simply play it whenever they want, always getting the newest, best version? Do we want users to buy a license, or just pay when they play? Do we want advertising revenue? Is connectivity important? Do we want to create an online 'community' integrated with the game?

We can certainly include 'main' methods for direct execution of the code. But I don't see what that will gain us, except the ability to test some modules 'stand-alone'.

[JimC]

How do you know what the 'bad choices' are? Do you have a crystal ball? I certainly don't, which is why I'm in favour of being flexible.

Anyway, simple Software Engineering methodology, regardless of Applet/Application, says that the more separate we keep interface and implementation, the better.

At the end of the day, the Java.awt.Applet or Java.awt.Frame classes are going to be 2 out of (potentially) hundreds of classes.

My point is that, if we keep our coding flexible, then we keep our options open. If we are smart about this, then making a mistake now won't result in a complete redesign being necessary.

re 16 bit graphics; again, depends how real-time dependent we are going to be. If we're going for purely turn-based play, then go for it. If not, then it depends on what frame rate, AI complexity, map size etc. we're looking at. There are too many unknowns at the moment to hazard a guess.

Jim

[F_Smith]

Jim:

I'm sorry, I didn't mean to suggest that anyone was making 'bad' decisions. Verbal diahreah (sp?) on my part.

The difference won't be in awt v. Frame. We can use both from either. Our biggest differences between applet and app will come in how we use Sockets, File IO, and that sort of thing.

We don't see the future with a crystal ball, but with a clear vision of the project's functionality. For example, if we're going to want multiplayer, an application will require a built-in server socket thread, and some system for trading IP address (likely a java applet like Microsoft's Zone). An applet is ready-made.

I hope I didn't upset you. I have a habit of shooting from the hip. Sorry.