• 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

22962 Excellent

About ApochPiQ

  • Rank
    Moderator - General Programming

Personal Information


  • Twitter
  • Github
  1. Algorithm

    Sounds like a job for a broadphase structure?
  2. 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.
  3. Controlling simultaneous accesses is exactly what semaphores are meant for - see Wikipedia for example on how to think of their functionality.
  4. You should be able to just drop your control inside a Panel control and call it a day, if I understand your requirements correctly.
  5. 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.
  6. 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 :-)
  7. 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
  8. 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.
  9. 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 :-)
  10. 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).
  11. I'm going to be as gentle as I possibly can here. All data stored on disk or transmitted over a network is "serialized" by definition. That's what the word means - putting the data into a "serial" stream of bytes, or an ordered sequence if you will. If you're not proficient in basic terminology of the trade, you are not ready to be making the kind of decisions you seem to want to make here, and you are not ready to make the kind of game you're talking about. You need to do a lot more research and drink a lot less NoSQL koolaid. A graph database is massive overkill for the kinds of graph searches used in games. For example, the canonical pathfinding algorithm is A* or some variant of it; this algorithm operates on tiny slices of memory in the game itself - not a separate database - and as such will probably be around an order of magnitude more efficient if coded correctly. Even social network mapping can be done with the same graph code in game memory and eliminate the need for a fat DB entirely. I have no idea how you have reached your conclusion that a document DB makes sense for implementing a game simulation, but you could not be more wrong. A typical MMO implementation is a custom piece of software - the "game server" - which stores all of the world's information inside its own memory space. It handles everything from physics and moving around the world to item drops from creatures and rolling on loot tables. It handles the core implementation of everything the game needs to do in order to be a game. There is a reason for this, and it is (plain and simple) compactness. You may have heard of "locality" as well. If I have to ask a DB server on the next datacenter rack for the position of a player, and the response takes ~1ms to reach me, I've burned literally one hundred thousand times the time it would take to just fetch that position from RAM. If your game can run at N speed in a database-driven configuration, reading documents for all of its game state and whatnot, it can run N*100,000 speed if it's doing everything in a local process on a single machine. Given that most games struggle to support a few hundred people in the same simulation, I think it's fair to say that making a five order of magnitude compromise on your basic simulation performance is... well, stupid. After a game server exists, it makes sense to talk about persistence, which is storing subsets of the game world data in a way that allows for a few niceties: - Players can disconnect and reconnect and be in the same place they left off. - Players who are not connected cost zero resources. - Servers can be shut down for maintenance or upgrades without destroying the game. - And so on. MMO persistence is traditionally very minimalistic from a certain perspective. You need a few things to do it right, like schema migration and versioning capabilities, but any reasonable DB has that. (N.B. I am indeed implying that if your DB of choice can't handle a schema version upgrade then it's no good.) You don't need anything more than a BLOB column type or even sparse files per-player on disk. Databases just don't act as a bottleneck of most MMOs unless you design them very poorly. The one and only time I would suggest splitting out multiple persistence solutions is if you want to generate time-series data like event logs or other metrics. Then use an appropriate tool for metrics aggregation and retention in addition to the persistence DB for game data. But that's a 100,000 CCU problem. You have a ways to go before you should be thinking about that sort of stuff.
  12. I would love to hear an actual reason why using two different databases is a "technical necessity."
  13. I see no reason to doubt the credibility of deterministic evolution, though.
  14. Digging through the trash IS physical access. I don't know why you think of them as different. There are industrial data disposal services for a reason. Use one if it really is that big of a deal for you. Reading the swapfile is not possible over the internet unless you have a serious privilege escalation exploit abused on your machine. Again, you'd be better off protecting against real attack vectors instead of worrying about winning a losing battle. If someone can root your machine from the network, you've already lost, period. There's a reason why security competitions often only require you to pop up a calculator app to prove your ownership of a machine - because once you can execute arbitrary code, you win. Period. If you are genuinely concerned about securing assets, you'd be much better served learning from actual security practices instead of chasing boogeymen.
  15. There are many reasons why one might feel unmotivated. It actually takes a substantial amount of self-awareness and introspection to discover why we ourselves feel this way. Sometimes it feels obvious, but sometimes it doesn't. And being aware of the many existing reasons for demotivation is a vital first step towards changing our habits and inclinations. I find it important to reflect. I might have three straight days of low productivity due to motivation, but upon thinking about it carefully, there may be three totally different reasons for feeling unmotivated each day! This is probably my biggest suggestion for anyone dealing with motivation or focus challenges: try to understand yourself and your reasons for feeling this way. But don't get lost in the bad. It also helps to think about why you want to feel differently in the future. Understanding the root cause of a problem is key to solving it. Just throwing other people's strategies at it won't work for very long. You need to know yourself well enough to understand why you have up and down days, and be honest enough to admit when you don't feel as good as you'd like. Sometimes it just isn't an option to be unable to motivate or focus. So get to the core of what's going on in your head, and why, and you'll have the beginnings of a map to solving the situation.