• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

141 Neutral

About ClickerMonkey

  • Rank
  1. Here's my second article, it's on managing game entities!   http://www.gameprogblog.com/managing-entities/   Thanks for any input!
  2. Article - Generic Game Loops (gameprogblog)

    Thanks for the input!
  3. Article - Generic Game Loops (gameprogblog)

    Thanks for the advice, I meant to do that but forgot/was not motivated to.   It has been done!
  4. I posted this article yesterday (fairly detailed article about game loops, with code and applet), let me know what you think.   http://www.gameprogblog.com/generic-game-loop/
  5. Since you know the client update time is 100ms... I don't know how you're updating the server, but you could increment a counter by 1 every 100ms and make sure a sequence sent from the client is never more than 2 (or something) more than that counter. Or if your server reacts based on input rather than an update loop you could just keep track of the last time the server received a packet, and the sequence of that packet. [b]For Example[/b] Client { lastPacketTime, expectedPacketSequence, updateInterval } [i]on packet receive[/i] [code] elapsedTime = currentTime - client->lastPacketTime; elapsedFrames = floor( elapsedTime / client->updateInterval ); client->lastPacketTime += ( elapsedFrames * client->updateInterval ); client->expectedPacketSequence += elapsedFrames; if ( packet->sequence > client->expectedPacketSequence ) { // sending packets too quickly, no no! } [/code] [b]Notes:[/b] 1. Account for expectedPacketSequence overflow. 2. Maybe let there be a difference of += 2 for expectedPacketSequence just to account for a slight unsynchronization in packet->sequence and the initial value for client->expectedPacketSequence. 3. If they appear to be coming at once, just think of it as the first one (or several) came late and the other one is perhaps on time (it can never be "early", thats what the above code should account for )
  6. How do you test servers?

    In the past I've used [url="http://www.vpsfarm.com/"]http://www.vpsfarm.com/[/url] to quickly boot up some nice VMs, run the simulations, and then stop them. With the cheapest package it was 3 cents (US) an hour for 1gb ram (or 12cents for 8gb). That would be sufficient I'm sure for a set of simple bots per machine.
  7. Game Engine - Networking Library

    [quote][color="#1C2837"][size="2"]It sounds to me as if you're targeting MMO games and virtual worlds, perhaps?[/quote][/size][/color] [color="#1C2837"] [/color] [color="#1C2837"][size="2"]Correct.[/size][/color] [color="#1C2837"] [/color] [color="#1C2837"][size="2"][quote][/size][/color][color="#1C2837"][size="2"]What kinds of games are you going to support with this library? I can think of at least six kinds of game networking structures[/size][/color][color="#1C2837"][size="2"][left]- RTS games, lock-step simulation[/left][/size][/color][color="#1C2837"][size="2"][left]- FPS games, high frame rates, optimized for deathmatch[/left][/size][/color][color="#1C2837"][size="2"][left]- Action games, medium frame rates, server-side physics[/left][/size][/color][color="#1C2837"][size="2"][left]- MMO games, server-side game rules, RPG style[/left][/size][/color][color="#1C2837"][size="2"][left]- Virtual Worlds, complex objects, varied gameplay (also mil/sims)[/left][/size][/color][color="#1C2837"][size="2"][left]- Turn-based games[/left][/size][/color] [color="#1C2837"][size="2"][left][/quote][/left][/size][/color][left] [/left][color="#1C2837"][size="2"][left]I hope to keep it generic enough so that any of these types can be done - with a proper set of interfaces and implementations. My current stall on design exists I assume simply because I've never done networking for a multiplayer game before. My end goal is a little ambitious, but you're right - currently I'm targeting MMO games to get my feet wet (or soaked rather). [/left][/size][/color]
  8. Professionalism and it's impact on your team.

    [color=#1C2837][font=arial, sans-serif][size=2][quote][/size][/font][/color][color=#1C2837][font=arial, sans-serif][size=2]COMPANY is looking for a few brave individuals to help us change the world. The person should dream in game mechanics, shout stories from the rooftops, eat ideas, and poop prototypes[/size][/font][/color] [color=#1C2837][font=arial, sans-serif][size=2][/quote][/size][/font][/color] [font="arial, sans-serif"][size="2"][color="#1c2837"] [/color][/size][/font] [font="arial, sans-serif"][size="2"][color="#1c2837"]Hey I can do those things! I must be a great game developer then! Yay me.[/color][/size][/font] [color=#1C2837][font=arial, sans-serif][size=2] [/size][/font][/color]
  9. [java] Java 2D Tile Sandbox RPG

    Cool game, not a type of game I would get sucked into however. Something I think you should find a work around for: Whenever I would use the Z or X key it would enter in the textbox (even though I was just trying to pick up or drop an item) - I didn't see an obvious way of unfocusing from the textbox to avoid entering in unwanted input.
  10. I've been working diligently on a 2d and 3d game engine for a couple months now (actually 6 years if you were to count all the times I started to make one and then switched graphics or languages). Currently I've developed the engine in Java utilizing LWJGL. I'll share with you my current networking design (what I have programmed), and I hope you can help me decide how to structure the final pieces! [b]Terminology:[/b] [list=1][*][u]Attribute[/u]: any variable that can be read or written to a buffer and can be interpolated between a start and end value.[*][u]Field[/u]: has the reference to a specific attribute, the value of the attribute in the last update frame, and the most recent value from the server ( for interpolation )[*][u]FieldType[/u]: defines several properties of a field, such as how often it gets sent to the server, when it gets sent (on entity creation, deletion, on request, on update, on change)[*][u]RemoteEntity[/u]: has a remote state and is notified when it has been created, updated, or deleted (remotely and locally).[*][u]RemoteType[/u]: defines several properties for a remote entity, such as the list of field types, and how often the entity is transmitted.[*][u]RemoteState[/u]: has a remote type, a reference to the remote entity, and a list of all the fields in the remote entity.[*][u]Message[/u]: something that's sent across the wire, an entity create, update, deletion, event, RPC, etc. Has a priority, a retry count, among other things.[/list] You may be thinking "a lot of these sound the same" or "are all those classes necessary?" and to that I say yes, here's an example class with angle, center, velocity, and health. I use the static FieldType and RemoteType to avoid repetitious data in memory. I have the class level fields final because "immutability" in Java games is really important to me. [code] public class Example implements RemoteEntity { // the unique ID that says "I'm an Example entity" public static final short TYPE = 23; // a generic factory for creating this entity public static final Factory<RemoteEntity> factory = new Factory<RemoteEntity>() { public RemoteEntity create() { return new Example(); } }; // the set of types that describe a field private static final FieldType angleType = new FieldType( 2, OnCreation | OnChange ); // sent at most every 2 network updates private static final FieldType centerType = new FieldType( OnCreation | OnChange | OnDeletion ); private static final FieldType velocityType = new FieldType( OnCreation | OnChange ); private static final FieldType healthType = new FieldType( OnCreation ); // server controlled // the type that describes the entity private static final RemoteType remoteType = new RemoteType( TYPE, angleType, centerType, velocityType, healthType ); // the set of attributes private final Scalarf angle = new Scalarf(); private final Vec2f center = new Vec2f(); private final Vec2f velocity = new Vec2f(); private final Scalari health = new Scalari(); // the state the holds the fields of this instance private final RemoteState state = new RemoteState( this, remoteType, // the set of fields that hold the attributes, and their types new Field<Scalarf>( angle, angleType ), new Field<Vec2f>( center, centerType ), new Field<Vec2f>( velocity, velocityType ), new Field<Scalari>( health, healthType ) ); public Example() { } public RemoteState getRemoteState() { return state; } public void onCreate() { } public void onUpdate() { } public void onDelete() { } } [/code] So basically when I do: [code] Example ex = new Example(); network.create( ex ); ... some time later network.delete( ex ); OR ex.onDelete() is invoked because server said so. OR ex.expire() was invoked by client, notifying "network" to automatically delete it. [/code] It will send the create request to the server, which can deny it, or accept it (and give proper field values if any are wrong). then the server (if accepted) will notify all clients that should care about the entity a creation notification. this also will automatically handle when the entity changes values, to send a proper update message. [b]Features Done:[/b] [b] [/b] [list=1][*]Prioritized messages[*]Retry count on messages (if a message can't be fit in the next payload to be sent, it will be queued)[*]Optional interpolation of attributes between the last update cycle and the most recently received.[*]Each attribute has its own "reliability", when its sent ( on create, delete, update, request, changed ), and how often it would be sent (if its sent on update)[*]Easy integration into existing game (using engine). Nothing additional needs to be done, it can track the attributes of an entity by it self and handle synchronization. Only thing that needs to be done is the server logic.[/list] [b]Todo:[/b] [list=1][*]Define the interface for the player view.[*]Define the interface for the player. It has an id, a view, a set of created entities, a set of currently/previous/maybe interested entities.[*]Define the interface for the server. It must have all players, an optional set of non-player entities, and must permit the network to accept creation, updating, and deletion. Through various methods this interface must give permission, adjust incorrect information, manage the sets of interested entities for each player, maintain a set of game states for the past 128 (?) updates to properly handle collision detection (so when player A thinks they hit player B, the server can actually test that), and many more things ([b]need help here[/b])[/list] [b]Thoughts[/b]: [list][*]Should I enforce that each entity has a "bound", and I should use this for determining interest (intersects with players view, or the area which surrounds their view - "may be interested in") I could use this then to make the world a huge grid of bounds - essentially an index for quick searching and collision detection. [b]Is there an instance where you think an entity won't have a bound?[/b][/list] So basically, I was wondering what you think are good designs for the player, player view, and server interfaces. Important note: I also plan on adding continuous world functionality into the networking library - so you can span a world across multiple servers. Anything would be well appreciated!
  • Advertisement