 |
| |
|
|
Mark_Everson
|
 |
Canton, MI
Jan 1970
time: 00:17
|
|
quote:
Originally posted by Sir Ralph
I suggest you to give it a try and write a simple chess program in Java.
If you succeeded and your games last less than a month, think about a chess game at 64000 tiles, with 10-20 terrain types and 60 different units.
Forget Java.
|
Hi Sir Ralph:
Man, you Are cranky in the morning 
What you say wouldn't be significantly easier to do in C++. You are arguing in hyperbole! While Java is slower than C++ it is Not a significant amount slower in number-crunching, which is the critcal factor in Everything you talk about. The only place Java is significantly behind C++ is in making fast sexy graphics, mostly 3D ones. Frankly graphics are about 5th in importance, if that, for many of the in-depth gamers like me. Gorgeous graphics are only the tiebreaker when Immersive Gameplay, Good AI, and Reduced Micromanagement, among other things, have been achieved. The graphics limitations would be a big disadvantage in a High-volume commercial release. That's not what the project here is trying to achieve AFAIK.
In addition Java is easier to code in, especially for non-pro programmers. There are no memory leak bugs. Built-in thread support will let the AI in a Java game think in the background while the player is moving. There are many other advantages also, but this is already long enough. We are using these advantages in Clash, and look forward to showing your analysis to be faulty 
|
|
| |
|
|
|
xRamsesx
|
|
of Candle'Bre
Oct 2001
time: 00:17
|
|
Language efficiency aside (even though I think c++ is the better choice for performance reasons), if this game is to be commercialy viable too, as Vel mentioned, it needs to follow industry standards. Currently the industry standard in game programming is c++.
And lets not forget that we're starting a new project with little (or maybe even none) experience in the field. I'm assuming we're all beginners in game programming, and we're going to need all the help we can get, so we need to look at available resources on the net too. There are tons of articles on the web written specifically for game programming for c++ and directx. I haven't specifically looked for Java articles but in the gaming sites I was looking at (gamasutra.com, gamedev.net) there wasn't a whole lot of those.
Last edited by xRamsesx on 18-01-2002 at 19:27
|
|
| |
|
|
|
Sir Ralph
|
 |
Long live teh Schwampel!
Dec 2001
time: 06:17
|
|
Libertarian:
Hey, since when is Basic a programming language? 
Understand me right, I am not against Basic, and I know writing a Windows application with VB is a charm and with VC++/MFC (or even w/o MFC) it's a pain, but...
1. Basic is really not a language, it's a language family, it has no common standard and every Basic is different. Even successing versions or the same Basic are often incompatible. So you have to write "Written in MS VB 6.0" and not "Written in Basic". Plus, porting a Basic application on another platform (Linux, Mac) is a real pain.
2. Basic has definitely performance disadvantages even in arithmetical statements. One example is, that it tends ways too much to convert lengths and data types (at least the versions I know). Albeit your integer incrementing example is true, but not all formulas are that easy. And a char-to-float-to-long-to-char conversion mess costs lots of time, especially if repeated 10000 times in a row. Right, in C it's the same, but the programmer has the opportunity to program type clean or use casts.
3. I don't trust the memory management of Basic, especially if handling huge dynamic arrays (and you need a lot of them if programming an AI). Is the time of memory leaks and garbage collection really over?
4. We'll need threads (Mark_Everson is right). I even don't know if they exist in VB. Do they?
I have an example. A few years ago a friend of mine took VB classes. One of his exercises was to write a silly game, if I remember clearly it was some variant of tic-tac-toe. (Guess all programming classes have to do that ) He couldn't get along with it and asked me to help. I didn't have the time to work into VB and light handed wrote him a couple of C (not even C++) routines. A simple recursive move generator and a minimax controlled selector. Pure arithmetics, no I/O. We translated it into VB, he added a simple I/O interface and ran it. Then he complained, it would make his computer crash. In fact, the computer didn't crash, but was busy to compute the first move. It didn't finish in a couple minutes, what my C routines did in a few seconds. It was VB 6.0. Don't ask me why and what was wrong, but that was the point I decided not even to think to take Basic for any program that needs big calculations anymore.
Anyway, feel free to show me that I'm wrong. I am not jealous. Good luck!
|
|
| |
|
|
|
Libertarian
|
|
Well, a lot of it is just perspective.
Language v Language Family
There are a lot of varieties of C++ as well. You'll find keywords with Microsoft's compiler that you won't find with Borland's, and so on. You'll even find differences in type handling.
Type Casting
With VB, you can be as loose or as tight with type casting as you wish. In fact, you can, if you wish, declare everything as a byte (equivalent to char) type and handle all the casting yourself, or you can declare everything as a variant (no equivalent in C) and hope for the best. VB handles the stricter types no differently than any other language (within OS context and constraints).
Memory Management
VB has completely revamped its garbage collection routines. Gone are the days of the long hangs after heavy string manipulation, which brings us to your next point...
Threading
VB was using apartment threading as early as version 5.
-----
I can't say, obviously, what happened with your friend's code. I've no idea what the optimization settings were on the compiler, or even whether the code was run in the DE (where the code is interpreted). And I really don't want to get in the rut of defending BASIC, except to say that, despite what C-snobs might tell you, when you get into real-world programming, you'll find VB to be your friend.
There ARE certain algorithms that might run better in C than in BASIC, but the reverse is also true. In the end, it all washes out. The only valid complaint, in my opinion, against BASIC is portability. But that's true of C as well, where cross-portability tools can create nightmares for support infrastructure. (Just look at the trouble Civ3 had with Windows XP.) As I said before, if portability is an issue, then Java is the way to go, but its VM is an interpreter, and therefore slow.
The advantages, on the other hand, are legion. Very fast development. Incremental component object modeling. Vast scalability. Easy maintenance. Intrinsically capable of data driven design. And many more.
If your approach is to do brute-force calculation, I guess I'd go with C (or C++). But if your aproach is to emulate intelligence, I'd go with BASIC any day.
|
|
| |
|
|
|
Velociryx
|
 |
of Candle'Bre
Apr 1999
time: 05:17
|
|
Hi all...UGH...home sick today! My boss came down with a nasty bug a few days ago, and I think I got it from him when we went to lunch. Was trying to make it thru the week, but man...I feel like a pile of reconstituted crap today (nice imagery,eh?).
I've been reading the ongoing discussion about what language to use with great interest. I won't pretend that it makes a *whole lotta* sense to my left-brained self, but here are my concerns/questions/desires:
* Graphics: I agree that the numbers and routines behind the graphics are more important for compelling game play, but, I DO think we should select a language that won't have a bear of a time handling some pretty darned good looking graphics. Oh, it doesn't have to be on par with, say, HOMM3 (where you open the map and you get wind moving thru the trees, windmills turning, shadows falling over the map, etc....but attractive is generally better than ugly, and the more attractive we can make it, the better. (I'm hoping, for example, that we can have graphics on par with Civ3....those aren't exactly state of the art, but they are appealing to the eye).
* Scalability: Beginning with something as close as we can get to the "boardgame rules" I posted here, my desire is to ramp the game's complexity up from there, adding additional layers/features to it until we have a really quite intricate system. As it stands now (glancing back over the rules posted yesterday), I think the system is fairly robust (if admittedly somewhat primative--intentionally primative, btw, based on earlier comments here).
* So...my main question/concern is: Can Java deliver the goods as the game's design stands as mentioned above? Can Java continue to deliver the goods as the game gets scaled up? I've heard from people who know both C++ and Java that they are, structurally, rather similar. I don't know HOW similar, so I'd not even attempt to fathom what a conversion from one to the other might entail (ie - if we started in one, and eventually migrated to another...that sounds to me, like it'd be a pain, similar or no...so our initial selection should be made with future goals--including making it commercially viable--in mind.
I suppose it might be easiest to break it down categorically, and simply ask the question, which language would have an easier time handling the following:
* Graphics on par with Civ3
* Scalability as the game increases in complexity
* Artificial Instinct routines
* Which would (generally) cause the game to run faster
Other questions would be:
* In looking at the "boardgame" version of the game posted last night, what technical hurdles exist in making that version of the game playable/fairly easily codable?
* What kind of timeframe would anybody guesstimate as far as getting a playable, bare-bones mock-up put together? (nothing fancy AT ALL...just the bare bones, formulae and place-holder icons for graphics).
* Simultaneous moves (per Yin's mentioning of Risk2) would be really cool, but how much of a bear would it be to impliment?
* For starters, would it be easier to create the game with no AI at all, and simply make a MP/Hotseat version, or would there be sufficient extra coding involved for that to make it a push? (I'm thinking that if we can make an MP/Hotseat version, we could use that for testing against each other, work the kinks out, and worry with developing the AI later, once we had something workable).
I'm sure there are more questions in my fuzzy brain, but the cold meds are causing the synapses in my brain to misfire....UGH...gonna take another hefty slug of Nyquil and lay down, but before I do, I'd invite anyone interested in the project to do two things:
First, look over the boardgame rules to get a feel for what I have in mind for the initial release, and tell me what won't work/what will be a nightmare to impliment, and why. There may be ways of streamlining the processes without sacrificing what intricacy exists in the system as it stands now.
Second, if you've not already done so, shoot me a PM or an e-mail at WebMaster@velociryx.every1.net with your e-mail and include what aspect(s) you'd like to help out in so I can compile a list of everybody who's interested (for easy communication with all), and see what skill sets we have to work with, and what we may still be missing.
Lib, I thank you *heartily* for your offer. It was suggessted to me earlier in PM that perhaps the Creative Design Lead (me) would not be the best choice for the project and resource management aspect of the project, considering it's vastly technical nature. I'll readily admit that while I'm a fair hand at coming up with the overall system and design, and doing the eventual documentation, I just don't know enough about the technical stuff to make informed decisions. Therefore, I accept your offer, so long as you don't mind me peeking over your shoulder to learn (cos I get the sense that it's something I'll eventually need a handle on).
And on those notes, I'm dragging myself off to bed again, but when I next pull my carcass outta the sack, I'll peek back in here....
-=Vel=-
(in the Quarantine Zone)
|
|
| |
|
|
|
Libertarian
|
|
No no no!
As I said, I'm NOT recommending that we use BASIC for this project. I just wanted to set the record straight from the BASIC bashing that took place a couple pages ago. That's all.
If I were selected as project manager, I would recommend whatever tools are available, and then apportion them according to what I believe to be their best assets. VB is a real option for the final interface package especially, which could call the other routines, each written in its own native language.
But we have to wait for Vel anyway.
|
|
| |
|
|
|
Libertarian
|
|
Oops, sorry. Just saw Vel's note.
|
|
| |
|
|
|
Libertarian
|
|
I've sent Vel my phone number. When he's feeling better, he can call me, and we can get everything rolling. By starting with a good game design, the rest is made much easier. But even before that, there are certain other essential concerns, such as resources, assets, and capital, as well as establishment of rules of equity distribution.
Sir Ralph, thanks. I enjoyed the insider banter on coding. You seem to have a good level-headed approach. That bodes well for us all.
|
|
| |
|
|
|
SlightlyMadman
|
|
Baltimore
Nov 2001
time: 00:17
|
|
VB is out of the question for something like this. VB only has 2 uses in this world: Cheap business apps and macro viruses.
C++ would be a great choice, as would a 3d graphics engine, and a full musical score composed by U2. Unfortunately, none of these options are available within our limited resources.
Java gives us quick, easy development, and its OO foundations are well suited to the ambitions of this project. It also provides platform independence, and access to the wide range of great tools out there that have been developed by others to help people like us (the beanshell scripting language, for instance).
Another great reason to go with java is that I'v already started development. It's incredibly basic (I've spent about 1.5 hours on it, so far), but it's got a simple client-server framework (multiplayer will be available from the beginning).
Anybody who wants to check it out can get the code via anonymous cvs access to sourceforge.net. The project is called candlebre.
|
|
| |
|
|
|
SlightlyMadman
|
|
Baltimore
Nov 2001
time: 00:17
|
|
Oh, I forgot to mention: The client and server are considered completely independent applications, and the AI players will actually be seperate client apps running independently.
This means that a client could be written in vb, or C++ with a 3d graphics engine, and an AI opponent could be written in assembly, or QuickBasic for all I care.
|
|
| |
|
|
|
Velociryx
|
|
of Candle'Bre
Apr 1999
time: 05:17
|
|
Step ahead of you, Master Wolf! Board game rules start on this thread, page 2....
And yes, I totally agree....having made some board games in the past, I knew much more about what would be involved there....putting everything together and doing some quick mock-ups for testing. Of course, being somewhat on the ILL side today, there's little I can do testing wise....mostly, I'm laying in bed, but I DO check here each time I rouse myself back to a standing position.
Perhaps the worst part of all is, my BRAIN is on overdrive....the body is simply not cooperating too well today...:: sigh::
-=Vel=-
(And thank you for the well wishes, by the way! Both here and in PM's!)
|
|
| |
|
|
|
xRamsesx
|
|
of Candle'Bre
Oct 2001
time: 00:17
|
|
Ok, now that i've finished eating, i'd like to give my humble opinion about some of vel's questions.
-----------------------
Language Choice
-----------------------
Graphics:
If our goal is to achieve graphics on par with Civ 3 then I would say, C++, Java, and VB are all viable options. But personally I think it would be nice if we could maybe even go beyond that level. For instance 3d glows around units to represent strength, the more power the stronger the glow. A sort of halo around cities representing importance. Economic center cities would have a specific halo above them, capitols would have another one, etc. And for stuff like that, although it still is possible to do it with all 3 languages, I believe C++ is the best choice because of speed, and support (by that I mean existing libraries and code we can use).
As a side note, the stuff I mentioned above might seem too high an objective, but I think we can set our standards high, and do our best to reach them, accomodating as we go along. Personally I like the challenge
Scalability:
This is a simple answer. Any object oriented language will do for that. So Java, and C++ are both on the same wave-length here.
AI:
This really is asking, which language can do routines the fastest and efficiently? And I think the answer to that one is C++. Java, although a serious contender, doesn't match c++'s speed.
Speed:
By now its probably obvious that I think C++ is the fastest language for our purposes. Again, Java isn't that far behind, but c++ is definitly faster.
Conclusion:
For what its worth, I think we should go with c++ for almost all aspects of the game, for the above reasons, and the others already mentioned in the previous posts.
----------------------
Game Questions:
----------------------
Timeframe:
I think at this point this is anyone's guess. We still don't know how many people are willing to work on this. How much time each person is willing to dedicate. And most importantly what our exact goals are.
Simultaneous moves:
I have a couple ideas on how to implement that, and won't bore you with them right now, but I think we can pull it off. It'll be much harder than the standard turn after turn, but it'll add so much more to the gameplay that I think its worth it.
AI vs MP initially:
I think it might be easier to start with the AI. We can start with a dumb AI and beef it up as we go along. But with multiplayer, in order to start testing it you need to have most of the MP code written and tested before moving further.
Those are my opinions for now
Ok, some socializing now then back to work
|
|
| |
|
|
|
Libertarian
|
|
Attention all who are interested in participating in the programming aspect of this project:
Please PM me, providing your e-mail address, your IRL name and age, your geophysical location, and a best time (US ET) to make contact with you. Vel and I have now discussed the project's preliminary goals, and I'd like to get your input on the programming aspects of our discussion.
|
|
| |
|
|
|
tjwojo
|
|
East Syracuse, NY
Jan 2002
time: 00:17
|
|
The way it is going, this project is already doomed.
You have most of the people making suggestions about fancy details (like glowing units) and arguing about programming languages.
You have one guy (Madman) who has decided the architecture for it already and has begun coding in a language that has not been agreed upon.
Meanwhile, Vel is still working out the design: something which could very well take months.
Even a simple project would fail with these things stacked against it. No one should be coding anything at this point. No one should be worried about nice features (or multiplayer). Everyone who is going to work on this should be concerned about the core design.
Also, what are you going to do about configuration management. It is hard enough for three or more people to put a piece of software together when they are all sitting in the same room.
I respect the enthusiasm, but the premature loss of focus does not bode well. You all need to slow down and concentrate. Do not get excited about this project, because the grander your dreams, the longer they are going to take to realize. Take small steps and you are more likely to stick with it in the long run.
|
|
| |
|
|
|
SlightlyMadman
|
|
Baltimore
Nov 2001
time: 00:17
|
|
xRam: good ideas, but way too ambitious to think about right now. The graphics will all be handled by the client, which can be rewritten later to be more flashy. For now, I'm keeping it simple.
As for the AI, if you're really that worried about speed, OOP is the wrong approach. If anyone who will be helping out with the project is really good enough to be able to attempt something more than the most basic of AI approaches, they might want to write it in assembly.
Me, I was thinking something simple and script-based. This isn't chess we're talking about here. All the AI needs to do is build things and shuffle around armies. The removal of tactical concerns is pretty much the only thing that I feel makes this project possible.
I could be wrong. Maybe I'm underestimating the skills available, and the time people are willing to put into this. Even if I am, though, we're best off putting together a simple playable proof of concept, and then completely rewriting it if it doesn't meet our needs. We'll learn enough in the process of writing the first version to more than make up for the time we spend on it.
Sir Ralph: very insightful ;) . The same approach is used by the WorldForge project, as well. I have the feeling that both of these will be valuable resources for us. If not for actual code, then for architectural insight. WorldForge actually has a java client that is similar to what we'd need for the "battle zoom" component.
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:17
|
|
Two comments from a professionnal programmer:
quote:
There are no memory leak bugs. |
Sorry, Mark, that is false. There is hardly any memory management in java, but there can be memory leaks. We can discuss it elsewhere, and it is not a first priority concern.
Language choice:
First look at what programmers you have. If you don't have pro software coders (or hackers who read hexadecimal figures fluently), do NOT go C++. It is a very difficult language. It is very tricky. There are so many nice things you can do with it that they are prone to abuse. I do C++ at work, for nothing would I do some more at home. Learning C++ is hard. Really. When you want to create an object of class toto, do you use toto obj; or obj = new toto()... every single line of code you have to wonder about memory management... #includes can be messy if you don't code your .h correctly... If you didn't understand these and bash them away as newbie errors, do NOT try to code in C++.
VB and java have an advantage over C++: they are far easier to learn. In the long run, you will need the same programming skills in all languages, but for a large project, you should not use something complicated if you are not proficient with it. Or be ready to throw everything away and restart from scratch when you reach a certain point.
OTOH, VB for UI is a good idea, at least to begin with.
|
|
| |
|
|
|
Velociryx
|
|
of Candle'Bre
Apr 1999
time: 05:17
|
|
Up from a nyquil nap to answer a few questions and make some sleepy-eyed comments!
Chowlett: The combat in the boardgame design works almost exactly like it works in the MB Game "Shogun" which came out slightly after Axis and Allies. Unlike Civ2/Civ3, there are no hit points and such in the boardgame iteration (and possibly not even in the computer version's early iterations....combat is either hit and kill, or hit and capture). A detailed example of the combat system is below:
Attacking Force: 3 Archers, 2 Cavalry, 4 Infantry
Defending Force (let's say a neutral province valued at 50g, so there'd be 5 Infantry to defeat)
Round One:
Attacker rolls first:
Tier One Combat (First Strike Units - Archers), 3 rolls, one hit. Defender loses an infantry. Since the infantry is not a first striker, he dies without even getting a defense roll.
Tier Two Combat: Cavalry Issues a Charge Order. They do not attack this round, but will be ready to attack next round. (Note that Cavalry may either attack with the Infantry or issue a charge....if a charge is issued, the cav. baseline attack values are doubled on the charging round, but they must pay for that in advance, by giving up one round of attack). Since the Cav are setting up for their charge, there is no tier two combat.
Tier Three Combat: Attacker rolls first, and two of his four infantry hit (so, three of the five defending Infantry are now dead) however, the defending infantry DO get to return fire, since they are a part of the Tier Three combat group. They roll against their defense values, score one hit (in this example, to keep it simple, we're considering this is a "standard attack" and not a "precision strike" so the player losing the unit decides where the loss is taken, and loses one Infantry.
Since this is a neutral province, there is no defender withdrawl option, so the combat moves to round two.
The archers have horrible luck this round, and none of them hit.
The Cavalry though, is ready for their charge, and with their double attack values, they both hit easily. Again, since this charge took place at the tier two combat phase of the round, the Infantry are unable to "return fire" and so they die.
No more defenders remain, so the combat ends, and the Province is captured.
Using this system of combat is a very simple way to foster combined arms attacks. You'll want a heavy infantry base (cheap) to soak up losses, but you'll want some troops attacking and defending at the higher tiers of combat to inflict pain on the enemy.
Also, to provide still more strategic consideration, there's the option to issue standard attacks or precision strikes. Precision strikes will halve your damage, but the advantage to them is as follows:
Under a standard attack, the player losing the units gets to choose where he takes his losses. Precision strikes don't kill as many men, but the player doing the killing can select which type of units are killed (ie - you could specifically target your opponents cav, striking them with massed archer fire before they had a chance to wheel around for their charge...less overall damage, but pinpoint damage to the opponent's force).
Game design: The core rules stand at about 90% completion. In fact, the only thing that's NOT done at this point is play-testing balance, tweaking costs, and fluff stuff like calling the techs something besides M1, M2, etc.
The only other aspect of the design that was (intentionally) left unfinished is the "Book of Fate" representing the game's Event Engine, and this was left unfinished to solicit ideas for it here....
All in all, not bad for two day's work!
-=Vel=-
Last edited by Velociryx on 19-01-2002 at 00:05
|
|
| |
All times are GMT. The time now is 05:17.
Apolyton Time is 00:17. |
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-01-2002 17:02
, that's what I meant by "a mess". 
. Point for you Lib. And I definitely don't want to start a Basic bashing, that would be unprofessional, just expressed my bad experiences.
|