Jump to content
  • Advertisement

Queasy

Member
  • Content Count

    148
  • Joined

  • Last visited

Community Reputation

157 Neutral

About Queasy

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Queasy

    Massive Gate 88 Update Released

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

    Sending Game Data

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

    randomness over the net

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

    File Loading design

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

    Questions on a simple Chat Program

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

    Questions on a simple Chat Program

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

    What do I need to compose music?

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

    Lot's of Lag, need help.

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

    TCP packet drops

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

    Questions on a simple Chat Program

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

    TCP packet drops

    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
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!