• 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

530 Good

About _winterdyne_

  • Rank
    Advanced Member
  1. It's difficult to provide feedback without knowing more about what you need the physics to do. Architecturally, I can see some issues: You have this structure, if I read your post correctly... simulation server -> actor server -> client -> client -> actor server -> client -> client ... but you don't clearly define the responsibility of an actor server (in fact you say explicitly it's not a static zone). What it boils down to is you need to inform clients of what happens in the simulation WITHOUT explicitly checking for their position at the simulation layer. To this end, zones are generally used (if something affects a zone, it *potentially* affects what's in it) and the zone performs fine checks (possibly subzones also). You certainly would want to avoid the situation where two 'actor servers' or zone servers, operate on overlapping areas. A single point of containment for an effect is required. Realtime physics in an MMO environment is never going to be as easy as dropping in an open-source physics API. The simple matter of latency to your clients is a massive issue. Synchronisation between client states is also a key requirement. That said, depending on what you need the physics to do there are ways of producing a comparable result - for example letting client-side physics handle things like ragdolling whilst the server simple calculates a trajectory for the centre of gravity of the entity, and force-updates the end position. Many effects that you'd want a physics system for are on non-game critical items (shards of broken furniture, particles) and are the result of a cruder force (grenade explosion producing X force from Y point, dealing Z damage). I'd spend some time considering what you want to simulate and how constrained the effects of it are. It'll help you decide on how to divide the world for sumulation.
  2. MySQL's easy to configure, especially if you use the MySQL Admininstrator front end. In fact I'd say that tool is ESSENTIAL. It lets you check queries, examine all the tables and generally play with your database, including its service (so you can tweak the networking and so on). Port 3306 is the MySQL service port to leave open on any local firewall, although you can change that if you want.
  3. IIRC, Eve's problem was database retrieval speed as it had basically a single database server in its (very) large cluster, and it was getting thrashed. They went for a solid-state (ram) drive in the end. Any indie game isn't going to need that, certainly not in early operation. Most high connection volume solutions use some form of clustering. This basically means that the machines/processes that comprise your server communicate on at least two levels: Firstly and separately to their own clients, and secondly to each other. Perhaps the bulk of them are 'gateway' machines that eventually communicate with a core game server, or perhaps each node controls a zone in the game world. In either case, the purpose of the cluster is to divide the work of at least communication with thousands of clients and / or the persistent simulation of the game. Edit: Regarding UDP/TCP. UDP can basically means you have receive from multiple clients on the same port, gives you more of a fire-and-forget networking feel, and requires some work to implement reliable (verified) communication. TCP requires a socket per stream, plus the listener, as you should know. It does guarantee sequential delivery, so it's useful for state management, as you can assume a newer state message is more valid. Regarding Threads. These aren't evil, but they are dangerous if you can't hold it in your head that each thread you have can be messing with data, and that all threads of a given process use the SAME MEMORY SPACE. I recommend an event subscription scheme of some sort for dealing with them. For example, my networking threads represent various services and service users. You could think of them as guys on the phones. When they receive a message, they drop it in a relevant queue and fire an event, which my main game threads can respond to, getting the message from the queue and handling it. Of course, you need to code the subscriber pattern in a thread safe (mutexed) way.
  4. My 2c. To scale up, in any cost effective method you're going to need to cluster. You need to be able to assume that your work is being done on a variable number of processes which might not be on the same physical machine. The cluster makeup I have is as follows: 1 Simulation database. This is the persistence database for the (instance of the) game. It includes all stats, inventories, descriptors for zones, everything. 1 Login database. This is for account information and locally (cluster) stored characters. These refer to entries in the simulation database. 1 Master domain process. I use the term domain to cover the allocation of simulation nodes to a server process. This particular process exposes a service to joining processes to register them with the cluster. They can then later be informed of other processes (to which they connect) and be allocated their own collection of simulation nodes either arbitrarily, or by means of load balancing. Incoming clients connect first to the master domain, and then to a specific slave domain. Optionally, the direction of incoming clients can be performed by a standalone login process, which is the better bet in very high traffic scenarios. N Slave domain processes. Once the master domain is running, slave domains can join it. They inform the master of their exposed network services (for players, admins and other domains). The master informs all other registered domains (and potentially the login process) of such. The master may provide the slave with a list of simulation nodes (zones) to be responsible for. Cross-domain traffic is direct between the relevant processes for the most part, with certain exchanges being marked as critical. Critical exchanges occur in a single transaction, and as such are limited to governance by a single domain. Domains are entirely authoritative - although entities on another domain may be visible, these are 'ghost' copies, they cannot generate or respond to events. Entities are ONLY simulated on the domain they exist on, everything else is an exchange of events between the domains. A bit long, maybe, but it might provide some ideas. :-)
  5. I'm all for procedural generation on a lot of things, but city layout is (and always will be) tricky to do. For Primogen, part of the mandate is *very* rapid world design. To this end there are some procedural techniques in assembling the modular buildings I've come up with - but these really are more of the form of 'draw a box and make it a room by placing default components correctly', rather than randomly generating the entire building. We'll also have pre-defined 'drop in' buildings (comprised of components) that designers can place. Sure, we could implement a system of adjoining boxes and door insertion for generating floorplans (constructive geometry) but really, a well designed tool can save a whole lot of effort in this regard anyway. Random generation can have its uses (in maze-like dungeons and other inherently unpredictable or unintuitive layout types) but for some things (like a town that has to operate correctly as a cohesive whole) it'd take more time to tweak the seed than to lay out by hand with appropriate tools. When it comes to something like forest or woodland entity (tree) placement, you positively WANT a random scattering of entities within a given area, and a procedural placement method becomes the best tool for the job.
  6. Personally what I find fun in games is learning how the system works, and having a plan *I* (or at least to my perception, I) came up with pay off. I like that moment of realisation that you get when something 'clicks'. The see-saw with the cinder blocks in half life 2 springs to mind. I like playing with the game as a toy -throwing corpses through basketball hoops in Deus Ex 2, planning the biggest multiple pileup and grenadefest I can in GTA... oh - not to mention the unique stunt bonuses. I *loved* looking at the world with a 'how can I catapult a fast vehicle off that' bias. I don't find 'grinding' enjoyable. Repetively performing a single-minded task for the purposes of getting better at that task brings me no joy. Conversely, I do like getting better at the things I do a lot, I just don't like being forced to do them.
  7. Umm... this is not good - he is possibly my favourite BBC presenter. I hope he recovers well.
  8. In my opinion the server should only really track interactive objects - there's no point in allocating an ID to a transient particle system (like an explosion), or non-interactive beasties. Basically, you only *really* need to track things that have bearing on more than one entity (player, typically) or are persistent. Anything else can be handled as an event directed towards or triggered by the relevant entity. Say you have a woodland zone - you may have a number of things happen that although you want to inform the client of, have no bearing or interaction as far as the game mechanics are concerned - an example might be a 'falling leaf' particle system, that occasionally drops a few leaves from trees. I'd trigger the 'falling leaves' as an event on a tree, now and then. When passed to a player, their client spawns and drops the leaf particles. The server doesn't need to know about them. If another player enters the area after the event has fired they simply don't see the leaves drop - it's not game critical so it doesn't matter. Tracked projectiles are actually a pretty bad idea because of lag constraints - by short lived I mean things like individual mobs, or potentially (if you want to make a feature of it) relatively static 'clue' objects for recent history like bullet holes and blood splats. Long-lived entities are more things like resource generators (mining points, harvestable trees) and interactive artefacts or components thereof (scalable cliff walls, doors, windows).
  9. Sometimes this is called a 'mesh exemplar' method - the primary mesh(es) (factory) in Crystalspace terms is not deformed by animation, and each instance carries its own animation states. Basically you don't want to carry around a whole new model for each instance. This is especially true if you're using a vertex animation (mesh tweening) method - they get heavy.
  10. If you're after realistic melee combat, about the best thing you can do is talk to re-enactors or live roleplayers who use the things in a manner fairly close to authentic. These guys will often be able to tell you about various fighting styles with weapons (rather than swing and hack) that may be appropriate to your setting. The SCA in the states have branches all over the place - they're probably a good source of information. One thing that will be difficult to get into a game is the reliance on footwork and tactical movement in a fight. To get this to *look* right, you effectively need to remove fine movement control from characters engaged in melee (which can be a bit limiting) in order to correctly synchronise your animations (parry to strike to parry or riposte). Go along to a local fencing club (or martial arts centre that do sword or weapon work), you'll rapidly get an idea for what I mean. If I recall correctly, Palladium books have some source material on medieval weapons that include diagrams of strikes and blocks with halberds, and various types of sword. I wish I could remember what the book was called, but I'd borrowed it off a friend and don't have it to hand. Some 'teach yourself judo' books have appropriate unarmed responses illustrated against armed attackers.
  11. True - you're going to want the downtime just for maintenance now and then, or the implementation of revised subsystems.
  12. Messing with thread priority often results in situations like this. Try a more friendly setting for your thread. In fact, it's more often the case that you'd want to set up LOWER priority threads than the parent, for housekeeping tasks, and leave the main thread with its default priority.
  13. Having a local (zone) ID generated per entity is one approach - but you may need to consider a larger internal ID to allow for intra-zone interactions, prefixing a zone ID onto the entity ID, and issuing a renomenclature if the entity moves into another juristiction. I've used 16 bit base ID's because I'm lazy and don't want to type lots. ;-) Anyway, the design I have is vaguely similar to this: Example: We have 2 zones, Forest and Town: ID's 0x0001 and 0x0002. 'Gunther the Orc' is spawned in the Forest, and given an ID 0x00010001. He moves around there with his local ID - if he approaches the town, the town zone is issued an event announcing his presence, and ID. Any events to do with him can immediately be passed on for resolution by the other zone server, as his ID is non-local. If he actually moves INTO the town a handover event is issued - data is serialised and transferred from zoneserver to zoneserver (or simply flat copied if using 'virtual' zones within a process), and the new entity is created from that data and given a NEW ID: 0x00020001. The new entity is introduced (remember its status has been transferred so is apparently unchanged) to the original zone. This is robust for identification of entities across boundaries, but you still don't want to do too much transferral; there's inevitably an overhead in the serialisation and selection of a new ID, even given the smaller range demanded by localising ID generation. We allocate ID's in two ways, from different ranges. Temporary IDs (for short-lived, mostly individual entities like fire walls, campfires, etc) are drawn from a circular buffer at the high end of the ID range. Longer-lived IDs are drawn from a range map (like a block allocation scheme) at the lower end of the ID scheme. Drawing long-lived entities from the circular section of the range is not a good idea, since you're more likely to run into overflow with long-lived entities, which can trigger a very slow lookup process. The range map holds start point and runs of free allocations. Often we're spawning more than one entity as a result of an event (and so we can allocate ID's by block). We look for the first block we find with sufficient allocations in it as our best solution. Optionally, we can search the 'fragmented' space, but this isn't a great idea. On release, entries are made back into the range map, producing a fragmented table. Since the entities may be referred to from elsewhere, we can't easily implement a sliding block mechanism (as you might for a memory allocation table). We're left with a couple of mechanisms that help - firstly, if you spawn something in a group, chances are it'll move on or get destroyed in a group - if you don't deallocate the ID's immediately but instead wait for the release of the entire group you save yourself a big headache. Secondly, and perhaps more reliably, we operate a housekeeping process that spends a little time defragging the allocation table. Hope this helps.
  14. The short answer, yes, if you can get the artwork done, and a suitable engine together. There are a large number of open source engines capable of doing the job admirably, or at least being adapted to do the job. Pretty much all entry level hardware now supports normal (peturbation) maps in a single pass with diffuse lighting. Multiple light sources and shadow casters are still fill-rate intense and cause big framerate hits. I will say, the graphical portion of an MMO is not the hard part - as far as rendering goes they're no different from any other game. Graphically, what you're most likely to run into these days are fill-rate issues and asset load time issues. Piling on a million and one different shaders doesn't do your framerate any good, but shouldn't impact too severely on gameplay (assuming you're networking asynchronously). If your art is not efficiently done (lots of differing materials and geometry sets) you'll run into problems when rapidly trying to load and render lots of them. This is true of ANY game where the visible context is likely to change rapidly, or contains a large number of draw calls. There are many tricks to getting a good looking game to have a large visual distance. Many revolve around cutting down the number of potential material and shader swaps to keep the number of draw calls down. The only real problem an MMO (or any game where the exact appearance of a new entity is not known until very close to when it needs to be drawn) adds is an extra layer of importance on the asset load time - especially as far as player, dynamic structure (player houses) and mob assets are concerned. Asynchronous (and ideally predictive) asset loading schemes and some form of area caching are well worth looking into.
  15. Quote:Original post by Edtharan I think the part of most medieval (or fantasy) RPGs is the goal of the game. Usually it is the player trying to save the world or avert some catastophy. This has become a fantasy (or even just a game) cliche. Damn straight. I feel that a 'lower level' playing 'space' in terms of setting works much better - look at the GTA games - they're loads of fun, because you're not trying to save the country, you're just trying to get by (and getting deeper and deeper in trouble as you try). MMO's, oddly, don't focus on saving the world (apart from CoH) that much - putting such 'endgame' content in them just doesn't work. Even for single player games, it limits the use of the IP if it's 'serious' - just how many times can the world be saved BY THE SAME FRICKIN' PERSON? (Austin Powers aside obviously). Era and equipment do not a clone make, as drakostar says. The activity that is done by the player can make it a clone, even if it's wearing a different skin. What's needed for originality in a Role playing game, is originality of the Role - and this is more than just what you look like and what you use, it's how and why. My 2p.