• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

Azrael

What to do first?

18 posts in this topic

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!

0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites
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


0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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


0

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
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 !!

0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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).]

0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites