 |
| |
|
|
JimC
|
|
Birmingham, England
May 1999
time: 05:13
|
|
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
|
|
Monster Island
Apr 1999
time: 05:13
|
|
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
|
|
Euless, Texas, USA
Apr 1999
time: 05:13
|
|
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. 
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.
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
|
 |
Canton, MI
Jan 1970
time: 00:13
|
|
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
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
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
|
|
Monster Island
Apr 1999
time: 05:13
|
|
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?
|
|
| |
|
|
|
F Smith
|
|
Austin, Tx, USA
May 1999
time: 05:13
|
|
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
|
|
Austin, Tx, USA
May 1999
time: 05:13
|
|
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
|
|
Birmingham, England
May 1999
time: 05:13
|
|
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
|
|
| |
|
|
|
F_Smith
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
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
|
|
Birmingham, England
May 1999
time: 05:13
|
|
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
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
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.
|
|
| |
|
|
|
JimC
|
|
Birmingham, England
May 1999
time: 05:13
|
|
re differences between Applet,Frame
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.
Jim
|
|
| |
|
|
|
F_Smith
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
Jim:
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?
P.S. -- of course we will be using standard 'object oriented design' methods of black-box methods.
|
|
| |
|
|
|
JimC
|
|
Birmingham, England
May 1999
time: 05:13
|
|
Well, I have a demo Mark's path-intensity ideas up and running now....
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.
Jim
|
|
| |
|
|
|
JimC
|
|
Birmingham, England
May 1999
time: 05:13
|
|
REALLY????
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.
Jim
|
|
| |
|
|
|
F Smith
|
|
Austin, Tx, USA
May 1999
time: 05:13
|
|
Worked fine for me using both IE4 and Netscape. Took a while, but not too bad.
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.
P.S. -- work is getting pretty heavy. Might not be able to respond much until next week.
|
|
| |
All times are GMT. The time now is 05:13.
Apolyton Time is 00:13. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
18-05-1999 05:53
|