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

ClickerMonkey

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

141 Neutral

About ClickerMonkey

  • Rank
    Member

Personal Information

  • Location
    Everywhere
  1. Here's my second article, it's on managing game entities!   http://www.gameprogblog.com/managing-entities/   Thanks for any input!
  2. Thanks for the input!
  3. 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. 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. [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. [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. 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!