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

Demitri

Making a Graphical Mud...

8 posts in this topic

Hello, a few friends and myself are going to make our own graphical mud. Currently, I am the only programmer, and am looking at where to start. I plan on using DirectX for the game, as it will be a simple, 2D, windowed game with chat interface. As for the networking code, I don''t know where to start. I''m thinking about using DirectPlay since it is included with DirectX. Well, however I plan to implement this. Should it be TCP/IP or UDP? It will be real time, but doesn''t have to be super fast. One machine will be the server (mine on a cable modem, for now) and all the clients will connect to mine. The world will be divided up into smaller maps, and each time someone moves their character or does some action, it will send their current map, location on map, what they''re doing, etc.. to the server. then the server will send out that information to everyone who would see this action happen. Does this sound like a good plan, on ideas? Criticism, anything? Thanks -Tim Elliott
0

Share this post


Link to post
Share on other sites
well, ill begin this by saying i have no netwroking expierience, so feel free to correct me
your system sounds like it will require alot of band width
a map is quite a large thing, and to send it practically every frame is alot of time
since you said the map was in regions, you might want to send almost all of the information needed for a region to each user in that region, and send updates everytime someone switches regions, and more often if multiple users are in the same region
just some stray thoughts
0

Share this post


Link to post
Share on other sites
I must have led you to think something different, the client portion of the game will already have the maps on their computer. It will be just a matter of telling it where it should place another player''s sprite on the map that they currently see. Actually, shouldn''t be very much data at all.

One thing I do wonder about, is how would I handle battles? I mean, the network part of the code. Would it send back and forth every attack, or maybe let a client attack it and only tell the server once something dies? But no.. that wouldn''t work.. because other clients would want to have a chance to help that player slay the enemy or maybe even save their life.. Any thoughts?
0

Share this post


Link to post
Share on other sites
I don''t see a problem with using DirectPlay for the networking piece. It works fairly well and you get all of the protocols for the price of one.


Breakaway Games
0

Share this post


Link to post
Share on other sites
Battles - yes, having the server keep track seems like the best (easiest, yet still performance OK) idea.

There are more optimized solutions, tho - for example, you could have the server "hand-off" the battle to the first client machine to attack, and from then on the client would act as a "mini-battle server" for anyone else who joins in the fray. Then at the end the "mini-battle server" client could upload the results back to the main server.

Just a thought - and actually, rereading that, it sounds a tad complex... but I''m sure there are many other ways to do this sort of thing too.

Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com
0

Share this post


Link to post
Share on other sites
What kind of scale are we talking about on the MUD? 10 people? 100 people? 1000 people? More?

For a small number of people, TCP/IP would be easiest. As your population increases you''ll probably want to switch to UDP instead.

Also, how much to you trust your players? If it''s just you and your friends, then handing off mini-battles might not be a bad idea. However, handing off to clients may open a risk in terms of client-side hacks, such as someone trying to go into "god mode" by sending death signals upstream prematurly.

DirectPlay is a matter of taste. I personally use berkeley sockets for most of my network code, because most of the time the server is running on a *NIX machine.
0

Share this post


Link to post
Share on other sites
I got something really good for you if you are going to code
it in VC using UDP. Search for mAngband for Windows. That could help you get going with UDP and Winsock.

Sending the players position every frame ain''t to efficient. Try instead sending ''when'' the player started to move and ''when'' he stops. You could use GetTickCount for this.

Hope I helped you
0

Share this post


Link to post
Share on other sites
quote:
Original post by Geradian

I got something really good for you if you are going to code
it in VC using UDP. Search for mAngband for Windows. That could help you get going with UDP and Winsock.

Sending the players position every frame ain''t to efficient. Try instead sending ''when'' the player started to move and ''when'' he stops. You could use GetTickCount for this.

Hope I helped you


Well, that would probably work, but I would only want to do this if they were going in one single direction, right? Then if they changed a direction, send an update? But actually how less-efficient could it be? I mean, each map would probably only have on at, at any time, a maximum of 10 people. So that wouldn''t be that much data to transfer, and something as simple as movement, could be easily kept in a few bytes..

I plan this game to not be very big, more of a just a project me and some friends will make. Probably only will have max''s of 10 people when we start.. maybe around 50 once it''s more advertised.. but as you see, very small scale. So would TCP/IP be easier to code, or should I still go UDP just in case it does get big. Actually, what is the difference between TCP/IP and UDP?

Thanks,
Demitri
0

Share this post


Link to post
Share on other sites
We had a spat about TCP vs UDP last month in the multiplayer forum, you might want to check it out if you want in depth pros/cons.

Basically UDP has lower overhead, but you need to code error conditions yourself. TCP is easier to program, but it''s a one size fits all kind of solution, that can really backfire on you if you have even a small number of flacky connections.

If you plan not to get past that 50 mark, starting with TCP is probably ok. That way you''ll be able to get your game logic going without having to worry about weird special network cases.
0

Share this post


Link to post
Share on other sites