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?

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).

quote:

---

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.

quote:

---

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.

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

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.

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.

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

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).

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.

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?

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.

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 know what the differences are - I've outlined how to get around them in one of the above messages.

I'll give a brief example - say a class wants to load a file. It should call, say container.loadfile(FILENAME) where container is an interface which will be implemented differently for the Frame and the Applet versions.

I've used it before, it works.... and like I said, it'll save redesign time if we screw up.

Agreed, we can do some things in duplicate on a class-by-class basis. But I'm referring to the architecture.

This is a big project. We have got to decide on an architecture before we get started. We can *not* make major architecture changes in a project this big later, without seriously impacting the success of the project. That's one big problem with 'scope creep'.

We really must decide now what our vision is for the functionality of the game. That will dictate whether we go with applet or app. I've tried to point out some of the functions I believe clearly point us in the direction of applets. Do you agree with those points?

To reiterate:

* build-in robust multiplayer support

* easy one-stop upgrades

I believe that you can not achieve either one of these with application code, therefore there is no reason to continue to spend time on application functionality. Do you agree?

Problem is, it stubbornly refuses to run in a browser-based environment, despite working beautifully using Sun's Appletviewer.

It also works fine as an application.

Luckily, I'm sticking to my principles of making the design as flexible as possible.

If anyone wants to attempt to run it from the web, it can be found here.

Stubborn Applet

If it works on anybody's system, or if anybody has any ideas as to why it isn't working, please let me know.

I'll distribute the class files for the application version to the coding team ASAP.

If I understand well the Java system, when we use an applet, it can't read or write something on the drives of the slave machine. How can somebody use a scenario or modify the rules of the game for him/herself? If we can write the best AI in the game programming history, the real selling point of this kind of games are the scenarios and the add-ons. I'm affraid we need to stick to a traditional application version. I know the applet version has a lot of advantage, but the modification possibilities are very important, practically this can be (must be) the strongest part of the game.

I read an interesting thread in the CIV III forum. Somebody propose a client/server method to produce a game program. Can we develop the Clash program with client / server architecture? This way we have one advantage: easy to implement the multiplayer version.
The AI(s) and the user interface(s) (clients) use the same interface of the server.

It is work for me.
AMD K6-II 300
Win95 OSR2
Netscape 4.51

Well, it loads for me, but when I click on 'start search' it manages about 1 path every 5-10 seconds.... (this is using IE4)

In Sun's Appletviewer or in application mode it manages about 10-30 paths every second.

What kind of speed can you get?

Hmmmmmm - maybe it's Microsoft's fault, since it runs fine using Netscape and Sun's Appletviewer and Java VM.

Anyway, if it works for anyone else, please let me know what kind of speed you get when you click 'start search'.

Temperamental Applet

If things seem OK, I'll have the demo fully functional within the week.

When I try to check the speed, the applet sended an error message and wouldn't like to work. Anyway the applet was not so slow, but I really can not remeber the speed.

Tempremental Applet worked great over the web with IE5.0. It took about 10s to transfer and 30s to run on default settings.

WoooHooo I can Run something!

Tempremental Applet worked great over the web with IE5.0. It took about 10s to transfer and 30s to run on default settings.

WoooHooo I can Run something!

Is there an echo in here?

-Mark

RE: the saving of files. (Loading local files is no problems -- getDocumentBase() does the trick).

There are several options.

1) Best: a client/server architecture which uses a browser's 'save' function and cookies. By downloading the applet to a local drive, you can read from the local machine without a problem. This is how Yahoo's "Games" works.

2) Second best: we can sign the applet, and gain full file i/o capababilities. This is how Microsoft's "Zone" works. It isn't as difficult as some people make out.

3) Third best: we can use copy / paste for saving files (since they'll all be in text). I've seen this used smoothly in several amateur designers. Look in the 'Java Games' thread for examples.

Sorry to hear real life has swallowed you up. We'll take you when we can get you!

Thankx! I think in this case the best to use APPLET format.