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


  • Content count

  • Joined

  • Last visited

Community Reputation

157 Neutral

About Queasy

  • Rank
  1. I've updated the game with a much needed stability patch. Eight player multiplayer games should not be a problem anymore. Details are in the changelog. Enjoy! -j
  2. Hello, It's been a couple months since the last update, but I've finally released a new version of Gate 88 last night. The update includes many gameplay tweaks, single player adjustments, and a new Alliance feature, which allows players to coordinate cooperative attacks against the enemy. Conversely, betrayals become a strategic possibility as broken alliances will cause former allies to suddenly turn against you in a vicious backstab. This often marks the decisive moment in a match. The game itself is described by Warcy.com as a “fast-paced, frenetic blend of real-time strategy and 2D space shooter.” Players dogfight in an upgradable command ship while developing base defenses, issuing squadron attacks, and researching new technologies. Though Gate 88’s abstract vector-art is unabashedly old school, Gamehippo.com says, “the gameplay is anything but retro. It’s new, fresh, and exciting.” The links: Gate 88 Website Download Screenshots and the Queasy Games website. Enjoy! -j
  3. Hi, I just wanted to add a few things to what hplus said. One thing you should watch out for is how often your clients sends a packet to the server. For instance, if 10 players decides to click the screen a gazillion times a second, it may flood the server (note: a large number of individual, physical UDP packets, although small, may still cause problems for the server -- at least in my testing it has). The easiest thing to do is just to limit the amount of clicks the user can do a second. However, another problem that crops up is that if you use UDP (and I think you really should), then the packets may not arrive in time. What if a player clicks on location X and then quickly clicks on location Y. The server may see it as "player clicks on Y then X." You can go into all those mechanisms for handling in-order delivery, but if it's the end result you're after (ie. what was the last position the user clicked on?) then an easy way to solve this is to simply send the current click position at regular intervals to the server. The added bonus of this is that it solves the first problem (the gazillion click problem). Also, I strongly advise that you do not use threads so you do not have to worry about race-conditions, deadlocks, and all the other associated hairyness of multithread/multiprocess programming. Hope this helps! -j
  4. Hi, There's also a good random number generator here: mersenne twister It's the one that kenta cho guy uses for his games (eg. parsec 47) -j
  5. Hi. If you want to a generic file loader that operates on grammars, then you want to write a parser. Writing a parser from scratch is crazy and not worth the effort. Instead there are automated tools that spit out parser classes for you (based on a grammar, usually in bnf). When I was in school taking a compilers course, we wrote a compiler in java. We used Jflex to scan it (parse it into tokens). We then used CUP to check if the tokens conform to the grammar. If I recall correctly, CUP also spit out an AST tree for us to walk. There are equivalents in the c++ world. In fact, I'm pretty sure jflex and CUP were based on existing c++ scanners/parsers. I seem to recall the prof mentioning something called "bison" and "yacc". Anyway, for a generic file loader (if you are serious about writing one) I would suggest looking into topics such as "parsing" and "compiling". Just remember that you're in it not to compile programs, but to compile and store data. But I also suggest you reconsider your actual needs for your projects. Do you really need a generic loader? Could you not whip up a loader more quickly in a couple days (given a file format)? Worse yet, what if you do write a generic loader, but one day you need the loader to do something it can't do (eg. load on demand or via web). Sometimes, reusing a logical format, but writing special code for each project is the way to go. Sometimes. I hope this was helpful. -j
  6. pseudo-code: // initialize listenSocket = socket() listen(listenSocket) loop: select to see if any sockets have data ready (with a timeout of 0) if listenSocket has data: newSocket=accept(listenSocket) put newSocket in the collection of already connected sockets if alreadyConnected socket has data: recv do something with new data This is just to illustrate how to do it without threading. Notice, as sharkyx has pointed out, that we POLL for incoming data with a timeout of 0. This means we ask windows if there's any data on the sockets. If there is not, it returns immediately and you can keep your program running. Anyway, a completley different solution to this would be to set your sockets into non-blocking mode... but that's not really recommended. -j
  7. Hi, It should. I don't use winsocks directly myself, so I'm not 100% sure on that function call, but if you use a "select" like function, then you don't need a separate thread. Just sleep until there's data available and then process it. I *think* WSAAsyncSelect does that for you. -j
  8. hi. go on ebay ans search within the "musical instruments" section with "midi keyboard"... ebay is by far the best place to by gear cheap. Also, you have to ask yourself how many octaves you will actually use during ONE recording pass. Ie. are you going to be recording passages involving > 3 or 4 octaves? If not, then just get a small keyboard. Remember, if your composition goes over 4 octaves, it doesn't mean you need a four octave keyboard. For instance, you might record the bass parts separately from the treble parts. In that case, who cares!? Just hit the octave up button before you record. Also, since you're getting into software AND you have a baby grand piano, onboard sounds should be your lowest priority. -j
  9. Hi, just looking at it from another angle here. Are you doing any sort of prediction? If your client works like this: get (x,y) from server move ship to (x,y) then it will be choppy (ie, there's no way the server can send that much data 60 times per second or whatever). You have to do something like this: get(x,y) from server AS WELL AS velocity (u,v) move ship to (x,y) and set it's velocity to (u,v) while i'm not getting any more information from the server, move the ship to (x,y)+(u,v)*theTimeThatHasElapsed. -j
  10. Hi, it looks like your argument "msg" and the return value of "cript.encode(msg)" is not returning a format. For instance, in your call to obj.write, your msg is "wrong name" with no format info involved. I know you said that you're sick of looking through the internet, but I found this via a simple google search: http://www.sunspot.noao.edu/cgi-bin-local/man-cgi?vprintf+3S It even has an example of an error routine which is quite applicable for what you want to achieve. -j
  11. Hi, You have to be more specific in how often you're sending packets. Right now you've told me how fast the packets are sent in one iteration. I need to know overall (ie. how many times per X milliseconds). for instance writing the following is ok: for (;;) { send send do some stuff (or sleep) for a 100 ms } but writing the following is a recipe for disaster: for (;;) { send send } In the second instance, you are constantly calling send ALL the time, which is bad. Even if you had: for (;;) { send send do some updates } It's sitll too fast. However, lord bart makes a good point in that if you're sending to localhost, it may not matter. It might also be a tricky logical error. Does your client take into account (as lord bart suggested) the fact that you may receive less than a packet's worth of data from a call to "recv" ? As well, is it taking into account that "recv" may return BOTH pieces of data (ie. the notification data AND the snapshot) at the same time? Will your client know to read one buffer and pull out two or more packets? -j
  12. Hi, the simplest way would be to use non-blocking socketes like you have in your client. The problem with threads is that you have to worry about synchronization. That is, you have to guard against the case where two ore more threads are manipulating the same piece of data at the same time. Having said that, threads are sometimes convenient in that you can use blocking sockets. My suggestion however, would be to just run the server single threaded (keep it simple) and use select (or some varient) to sleep until there is incoming data (so the server doesn't busy-wait). I hope that helped. -j
  13. I assume you're using tcp (as opposed to udp) since that was in your title... but normally tcp will try to make it reliable. As well, calling send consecutively should not cause any problems UNLESS you are calling it extremely fast (ie. you're pushing too much data through). Going over the bandwidth limit usually causes a huge and sudden spike in packet loss. At what interval are you issueing the send command? -j
  14. mumpo: thanks! Yea, the community is still rather small at the moment :-/ rolando: heheh... i'd like to think of it as an orgasmic experience filled with colour and motion ;)
  15. hey, thanks for the comments :) It's true the controls are tricky at first but the good part is they're learned quasi-procedurally. So you'll never forget 'em (it's like learning how to do the fireball in street fighter). -j