• 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

22971 Excellent

About ApochPiQ

  • Rank
    Moderator - General Programming

Personal Information


  • Twitter
  • Github
  1. I'm guessing that (thanks to the lovely state of political climate regarding healthcare) you don't have access to an actual medical professional that would, you know, be remotely qualified to tackle issues like this. So I'll stick with the standard disclaimers: trying to find mental health advice on the internet is dangerous at best, nobody here is (likely) able to actually solve your problem, and relying on support from fickle anonymous strangers can become literally deadly if you take it too far without seeking professional help.
  2. Note that if your rate of path searching is relatively low, you don't even need to cache paths. Cache invalidation can be tricky, so if you're not doing hundreds of path plans per game tick, you can totally get away with not caching at all and just recomputing paths from scratch every time you need to.
  3. Merging architectures based on "time into the future" can sound appealing on paper, but often degenerates into really difficult sub-problems that end up making the whole thing less than ideal. For example, in your suggested scenario, what happens if I find the utility of an already-formulated plan to be zero? What happens if I plan to do something but ignore its utility? Obviously that's not going to fly, so we have to compromise and integrate utility into the planning heuristics somehow. But now we need to know the utility of future hypothetical gamestates, so all we've really done is complicate both algorithms substantially. The handoff between the two designs is not clear or well defined, meaning that it will be hard to keep the two from polluting each other. This is of course just an off-the-cuff example. When you get into the weeds of blending architectures, it often turns nasty because of this kind of thing. It is actually pretty hard to find disparate architectures that "hand off" well between them in the general case, when you're talking about time into the future blending. If you're lucky and your particular case doesn't have those thorny edges, cool; but otherwise you end up just writing a lot of special case hacks and workarounds that don't really suit the goal of getting the game done. Layered architectures are a different thing. That's where you have a system that controls the fine-grained details and one or more additional systems that control the big picture stuff. They are designed to feed data back and forth, and to cooperate. Layering is a good thing and used all the time for things like strategy-vs-tactics distinctions, for example. Occasionally there are architectures that work well across the "time into the future" spectrum. For example, utility architectures can be set up to do partial planning with some careful forethought. When you have a single solution for a wide range of problems, it's much more appealing to use that solution generally than to try and wire together a bunch of special cases.
  4. Your account of the problem is inconsistent. Is the error rate 0.5 or 0.25 or some other number? This is a red flag to me. You haven't posted any actual ANN code, which makes me guess that you're using a library. Have you contacted the library provider and/or consulted the library's documentation and example code? You didn't answer the single most important question from Kylotan, which is: what have you done to try to figure this out yourself? Do you know how to use a debugger? If so, have you tried stepping through the code to understand it better? If not, that's your starting point.
  5. What are you trying to implement? AI is not about picking a nifty-sounding algorithm and throwing it at anything and everything under the sun; starting with a solid understanding of the problem you want to solve is key.
  6. Algorithm

    Sounds like a job for a broadphase structure?
  7. This generally goes by the name of "UV mapping" and is a whole chunk of mathematics unto itself. It has close relationships with projections - as in the transformations used to get a 2D map of a 3D planet, although obviously you want to go the opposite direction. Put simply there is no single perfect solution to all variations of this problem. Most of the time it is solved by just throwing human brain power at it - that is, having an artist construct a UV map by hand.
  8. Controlling simultaneous accesses is exactly what semaphores are meant for - see Wikipedia for example on how to think of their functionality.
  9. You should be able to just drop your control inside a Panel control and call it a day, if I understand your requirements correctly.
  10. This article may be of some use to you. IIRC you can directly access the display's DPI (dots per inch) settings from a Graphics object in C#/WinForms, but I'd recommend reading the whole article as there are some subtle gotchas in DPI-awareness.
  11. Python is not my strong suit so I apologize if this is vague, but... What you want to do is store a reference to the PC (or NPC) in a variable. Then instead of having an if check, you just ask the variable for its alacrity stat directly. When the turn switches, you can point that variable to the "other" character instead, and off you go. This way the code uses the same exact checks for everyone, but it can be "configured" to point to one character or another on the fly. Hope that made some semblance of sense :-)
  12. An abstract class is a different thing than an interface. Please don't perpetuate the confusion :-) Aside from that: I am slowly losing the habit of using I-prefix anywhere in C++ I personally hate naming files after classes Do whatever feels like the least friction for you. I tolerate a huge amount in other people's code that would bother me in my own
  13. Note that simultaneously locking multiple mutexes for any reason can lead to deadlock if you are not extremely careful. When it is necessary to lock multiple mutexes for some operation, there is a common pattern called locking order which is employed to defend against deadlocks.
  14. The main thing I'd suggest keeping in mind is that you might be artificially limiting your options by trying to find an entry-level job which also is a dedicated AI role. Entry level is hard enough to break into as it is, and AI is a specialization that typically involves some baseline experience in making games. Your best bet (IMO) is to get a good title or two shipped first as a gameplay programmer, and pick up the AI as you go. Once you have the basics of shipping code under your belt, you can start looking into the specialization. You should ideally be conversant in all of the following: Decision making systems (scripting, utility-theory, behavior trees and similar architectures, planning, state-search, machine learning [ugh], and so on) Path planning algorithms and data structures Perception modeling (sight, sound, etc.) Animation techniques at least at a high level (know what a blend tree does, how to play animations, etc.) I'm sure there are more things. Pick up a good game AI text and you should at least be comfortable talking about every subject in there. Hopefully that explains why entry level and AI specialization is a hard combo :-)
  15. Wikipedia's definition agrees with mine; storing data in a table structure is generally considered an example of deserialization, i.e. not storing things in a flat byte buffer of transmissible data. Anyways, my point stands; if you're having trouble with basic terminology you're going to have a lot more trouble with anything sophisticated like justifying a multi-DB infrastructure (for one wild example). JSON versus normalized tables is a pointless debate for now; you're still missing fundamental concepts. It will be all but impossible for you to succeed unless you work on your fundamentals first. You need to get rid of this notion that you have a giant database-shaped hammer and everything that involves data must be smacked with it like a nail. The whole point of my description of game servers is not that they do things in memory. The point is that they do it in the same memory as the game. Your "in memory database solution" is not the same thing as writing your game logic to work independently of a database. You must understand this fundamental concept or any further discussion is going to be a waste of time. What I'm telling you is that storing all your game data in a DB will have performance implications. More specifically, it will be impossible to scale to more than a handful of players if you do this. You need to stash the data for the game simulation in the same program as the game simulation itself, and only use databases for recording player/character data when it is time to do so. In fact there's really not much point in using a database at all unless you actually know what you're doing with them (and - nothing personal - you clearly do not). When it comes to games implementation, doing Floyd-Warshall, Dijkstra, or A*, or any other graph search/analysis algorithm on a database is just silly. You can find implementations of those algorithms in practically any mainstream language you can imagine. Just do the search in your own simulation code and you're done. I virtually guarantee it will perform better than trying to shoehorn a game into a shrinkwrap DB solution. By the way, my "choices" (read: experience deploying real, successful MMOs) are largely independent of things like language. You can do all the things I'm talking about atop Node.js just as realistically as you could do it in a homegrown C or C++ framework. Again, pretty much any mature, robust language is fine as long as you can design the architecture right. There will be differences between how well a Node implementation performs versus a highly tuned C++ implementation, sure, but those affect things at very high numbers of users. By the time you need to worry about it, you can probably afford to worry about it (i.e. pay someone to worry for you).