Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


What to do first?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
18 replies to this topic

#1 Azrael   Members   -  Reputation: 128

Like
Likes
Like

Posted 08 November 1999 - 10:28 PM

What is the best way to start learning multiplayer techniques? where should I start?
jumping to winsock? or try to make a direct play aplication? what about http? how does that work? I have some programming experience, but I dont know where should I start.


Sponsor:

#2 Sphet   Members   -  Reputation: 631

Like
Likes
Like

Posted 20 October 1999 - 06:31 AM

If you don't have any experience with Winsock, I think your best bet would be to start with DirectPlay. It will give you a chance to understand the methadology behind multiplayer gaming (ie. game packets, latency, messaging, etc). Once you have that done, you can look at Winsock (Windows) and BSD Sockets (*NIX). HTTP is a protocol that works over TOP of TCP/IP (Winsock/BSDSockets), so it should be left for later. It is relatively simple once you know how to handle TCP/IP.

I would try doing something simple with DirectPlay (not a game, just some chat code, or something) and then try to build it from scratch using Winsock. You'll see the pitfalls, but also see how nice it is to be able to tailor your work. (Also affords you portability if you don't use any of Winsocks WSA_ calls [except init and shutdown]).. anyways, good luck!


#3 Niels   Members   -  Reputation: 122

Like
Likes
Like

Posted 20 October 1999 - 10:34 PM

I don't see any particular advantage in DirectPlay (I'm currently using it in my DX based game, but if I were to do it over again, I would use std sockets). The + in DirectPlay is supposed to be the "transparent" support for multiple protocols. Only problem is, it is not transparent (and besides, who cares about anything but TCP/IP these days?)... On top of that, all the nifty features such as latency calculcation works like sh*t...

Just mho.

/Niels


#4 vince   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 October 1999 - 04:29 AM

I think one of the easiest ways to get started with network programming is to do TCP/IP socket programming in Java. Java has a very simple socket interface and there are a ton of samples out there.

Once you get a handle on the concepts you can move to Windows sockets or BSD sockets in C++/C. The concepts are generally the same, its just a more complicated syntax.

I would NOT recommend DirectPlay for someone just starting out. It is probably the worst designed interface of all the DirectX components, and the documentation is bad.

------------------
-vince




#5 Niels   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 October 1999 - 02:14 AM

Dead on: Java rulez, DPlay doesn't

/Niels


#6 Zenroth   Members   -  Reputation: 127

Like
Likes
Like

Posted 23 October 1999 - 04:38 PM

Hmm just gonna add my opnion about directplay. You really want to spend the time writting tcp/ip,upd(not hard ive done it in winsock myself)IPX(very popular i hear winsock 2.2 can maybe do it? But then again win95 doesnt ship with 2.2..)Modem (still popular),and finally Serial(very popular for ppl that want to bring over there comp and play a quick game ect.)

So even though dplay might have some pitfalls i say its very usefull.


#7 vince   Members   -  Reputation: 122

Like
Likes
Like

Posted 24 October 1999 - 05:28 PM

I agree DPlay has advantages over pure socket programming, but I don't recommend it to someone who is just starting out with network programming. The docs stink.

I stand by Java sockets as the easiest way to get started with network programming - moving on to other things such as DirectPlay can be done later.

------------------
-vince




#8 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 04 November 1999 - 11:33 AM

Java Sockets? That sounds great! I already know a bit about java programming, where can I find more info about them? how do they work?


#9 Zenroth   Members   -  Reputation: 127

Like
Likes
Like

Posted 04 November 1999 - 04:08 PM

I agree java is pretty easy to start off with. Though myself i like the idea of java just not the results i got. (i started off learning java then moved back to c/c++)I think i miss pointers. But anyways here is alink to something that might help you some with java game programming.
http://www.informit.com/content/1575211483/chapter_15027.shtml

#10 Niels   Members   -  Reputation: 122

Like
Likes
Like

Posted 05 November 1999 - 11:28 AM

Just a footnote: Any object reference in Java IS a pointer (you just don't get to do all the dangerous stuff with it, that you do in C++ )

/Niels

Oh, and garbage collection rules !!


#11 Splat   Members   -  Reputation: 122

Like
Likes
Like

Posted 05 November 1999 - 12:06 PM

Garbage collection is nice, but that's just because we don't expect Java to be high performance. If we didn't expect C++ to be high-performance, we'd just new memory (or malloc) and never bother to delete/free it. The operating system would clean up for us When we get to high performance apps, we want to control our garbage collection explicitly, because there are times we can afford to clean up while other sutff is running concurrantly.

- Splat


#12 Niels   Members   -  Reputation: 122

Like
Likes
Like

Posted 06 November 1999 - 12:56 PM

I tend to disagree with that - There are scenarios where garbage collection can be faster than having the app manage memory by itself. The problem is 1) Fragmentation and 2) Pooling. Neither malloc nor new care about any of these two things, so unless your application does, you'll suffer from fragmentation and lack of pooling. A well implemented garbage collection system will deal with these issues for you.

If you sincerely believe that Java can't be high performing, try searching the web for a demo called "forward" by a group called "komplex" (ftp.hornet.org might have it). Also "apex" by "digital nerdz" is quite cool. Both will convince you, I'm sure

/Niels


#13 Splat   Members   -  Reputation: 122

Like
Likes
Like

Posted 06 November 1999 - 04:08 PM

Oh no. I certainly do not dispute that Java can be fast. However, everything in Java can be replicated in C++. I can do "Java" like garbage collection, but keep it under my control. During less time-crucial periods and only then I will deal with memory reallocation and garbage collection.

With Java, there's no way (or if there is, I will pick up Java again as a primary language) of telling java that THIS TIME is when you want it to deal with its automatic garbage collection, not when I'm in the middle of a tight loop or dealing with sending a network packet out.

However, Niels, I am writing a game engine right now to be interfaced with Java as the "logic" code for a series of games, since I like the simplicity of Java. Its just I don't think I would like giving up control in speed-critical code. That's why I moved away from VB in the first place.

- Splat

Oh yeah, I can't find either of those Java demos. I'd love to see them, so if you have a copy putting it up would be real cool.


#14 Xai   Crossbones+   -  Reputation: 1458

Like
Likes
Like

Posted 06 November 1999 - 05:39 PM

Here is a simple anti-java post. I am not saying Java is a bad language, I just want to stand up and speak against a few things I consider misconceptions.

1) Java is portable, C/C++ is not. This is absurd. The ANSI C language is the single most portable development language in existence, and why, because it was designed with a STRONG relation to the basic architecture of the computers that are dominant in almost ALL markets. It is the ONLY language I know of that I can write a function implementing an algorithm once, and then compile it to run on 8 bit embedded machines, PCs, Unix servers, mainframes, AND consoles. THIS IS CROSS PLATFORM, and the added benifit is that the compiling process generates code as effiecient as the author of the specific compiler (for the intended target) can write. I acknowledge that you can compile Java to generate native object code, and so this is not an argument against the language itself, but just against the idea that BYTE code and Virtual Machines are the end-all of cross platform compatibility. Inheirently this is NOT cross platform, that would be like saying PLAYSTATION games are cross platform becuase someone writes an emulator for the PC. This is DICTATING the platform, not bridging differences in platform.

Side Note - I do not use C except when needed for embedded platforms, because I like C++'s power WAY TOO MUCH. And I will be the first to admit that C++ is not CURRENTLY cross platform in ANY way at all (the state of compilers is atrocious).

2) Java is simple. I dissagree. For anyone that has ever written a program in ANY procedural language (including assembly) I believe C/C++ to be much easier to learn, and I don't mean easier to get a window up and displaying "hello world" while a sound plays in the background. I mean "learn" in the sense that the programmer actually UNDERSTANDS what the program is doing, and can predict what the effects of a new change or addition will be. I admit that because of many built in functions/classes it is EASIER to acomplish a task in than for a first time C++ programmer, but the same is true for C++ if you add a good class library/framework. But C++ doesn't tie you to one framework, nor does it require you to understand the meta model to understand a simple program. Current computer architectures are inheriently procedural, they have the concept of stacks, address spaces, instruction pointers, and data built into their machine instructions; but any aditional framework on top of that is an EXTERNAL FRAMEWORK that is not necessary to understanding the machine itself. I admit the programming advantages of OOP are more than worth their miniscule trade off in size or speed, but they OBSCURE the learning of computer programming in general, because computers are NOT object oriented. Just ask yourself how many or the current programmers here understood BASIC or Pascal when you were just a child, then ask yourself if you could have learned Java, interfaces, polymorphism, etc. just as easily. More importantly, ask yourself if you ONLY learned the concepts of OOP, without first understanding the procedural nature of the machine, would you be able to make the right trade off decisions necessary to writting the kind of code required by a game.

3) Multiple inheritance is a useless feature that isn't worth the cost to add it to a language. In my experience this lack is major flaw of all OO languages that have it. Mulitiple inheritance is often the only method of implementing a good, clean OO system. Just look at how much nicer the C++ iostream hierarchy is because of it, and the STL iterator system makes good use of it. I personally use it in my own game designs, fo such things as tying together classes such as AutonomousObject and DisplayElement to create a class such as NonPlayerCharacter, or FreeOrbitingSatalite (this is not my best expample, but it's my quickest). I also realize Java has at least added the "interface" keyword to support this functionality, but it's usage is by no means as straight forward as multiple inheiratence (although I do have to say if the keyword was added JUST to replace the stupid =0 notation for pure virtual functions, but multiple inheritence was kept, it would be ok).

Oh well, enough for now....

[This message has been edited by Xai (edited November 06, 1999).]


#15 Rambo_Bill   Members   -  Reputation: 114

Like
Likes
Like

Posted 06 November 1999 - 07:13 PM

I haven't had a lot of cross platform exposure with c, but the little I have had the functions behaved completely differently. Even in very low level crap like getch(). The one version I used after a call to getch() you had to call flushbuffer() or something like that to clear the keyboard buffer otherwise you would get the same char over and over once the user pressed a key. Also I've never known a cross-platform graphic library existed for C. If so, what is it?
To me it seems the only thing that remains a constant is the syntax which stinks anyway, but thats another story.


#16 Niels   Members   -  Reputation: 122

Like
Likes
Like

Posted 07 November 1999 - 11:12 PM

Xai: I am not going to start a C++ vs. Java crusade - I use both in my work, and right now, couldn't do without either.

However, there's a few things in what you say that I feel stems from misunderstandings:

Java IS portable - meaning the distributed code (binaries) are portable. And the Java run-time should not be compared to a Playstation emulator since the latter is mainly a HW emulator, the Java RT is not. There is a huge difference between an emulation of a system and a system that is "designed to be emulated", so to speak.

Reg. creating code as efficiently as the platform allow: That is exactly the problem with conventional programming languages (C/C++) - most code we write today is targeted at - Two PCs today are not just two PCs, they have different processors (instruction sets), different pipeline technology, different cache size and memory, different bus speeds, not to mention various add-on HW (3D accel., sound cards w/ DSP etc.etc.). Byte code can be optimized on the fly to match the environment, machine code cannot (or, it is extremely hard to do so). IOW: I do not believe in "byte code" processors, the strength of bytecode is that it is HW independent.

Java is simple compared to C/C++ because:

1) The file structure is simple - one file, one class. If you want to create a re-useable component, the .class is all you need. No .lib, no .h, no typelibraries etc.etc.

2) Garbage collection removes the most annoying pitfalls of C/C++. (And yes, you could write your own, but that is NO easy task if you want one that works fast without annoying artifacts)

3) Java is typesafe (which C is not)

4) A lot of the "smart" features of C++ (IMHO) only add to the confusion when learning the language: operator overloading, templates, multiple inheritance.

Finally, reg. multiple inheritance - there are really good reasons not to have it. In particular that it can't be implemented in a clean way. Java has "interfaces" as the way to solve the problem. Intefaces are not a 1:1 substitute, but it works well in most situations. (I've missed mutiple inheritance a couple of times myself, but in the long run I prefer a clean language).

Splat:

You CAN invoke the garbage collector (System.gc() I believe)

For cool stuff, check out the following sites:

ftp://ftp.gathering.org/pub/TG/TG99/javademo/

ftp://ftp.gathering.org/pub/TG/TG98/java/

(forward.zip is available in the latter)

/Niels



#17 Niels   Members   -  Reputation: 122

Like
Likes
Like

Posted 07 November 1999 - 11:15 PM

Splat: I'd love to here more about your experiences with using your engine from Java - It's been on my todo list for a while (converting my game engine to a DLL, and the game code to Java)

/Niels


#18 Splat   Members   -  Reputation: 122

Like
Likes
Like

Posted 08 November 1999 - 11:15 AM

A bunch of things:

Java's "interface" and "final" are great, exactly what's lacking in C/C++. Interfaces, being supported natively and explicitly in Java, are a great asset, and I think mostly get rid of the need for multiple inheirtence (since all I use that for is multiple pure virtual "interface" classes).

As soon as we have run-time optimizing byte code virtual machines in Java, there will be few excuses not to use it.

However, I disagree in several respects. I think operator overloading is a natural extension of object oriented programming. In fact, I think operators should be expanded to allow an opbject to create new operators. This would facilitate a new means of interacting with objects, and would create code that more resembled english.

Also, templates in their current form are merely a simple convinience, but if they were designed into a language from the beginning and therefore more carefully implemented could also be VERY useful.

The beginner C/C++ student does not need concern himself with the more advanced concepts of C++. The beginner who uses CString to write simple text based console apps need not nor should know how CString really works inside.

That aside, I must say that forward demo is really cool.

Lastly, I'd love to talk to you about the Java - Game Engine interfacing DLL stuff, but either you need to email me or give me your email hehe

- Splat


#19 Niels   Members   -  Reputation: 122

Like
Likes
Like

Posted 08 November 1999 - 10:28 PM

Reg. operator overloading - I still don't fancy it too much - the problem is that people tend to focus som much on operators that they overload them with functionality that doesn't resemble the original operator at all, making the code VERY hard to read (and debug).

Reg. templates - I agree VERY MUCH that templates as a concept is brilliant - it is just that the C++ implementation suck so bad.

Reg. e-mail - Whoops, forgot I didn't make that public niels.jorgensen@image.dk should do the trick

/Niels






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS