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

Kylotan

Moderators
  • Content count

    13791
  • Joined

  • Last visited

  • Days Won

    15

Kylotan last won the day on July 24

Kylotan had the most liked content!

Community Reputation

9744 Excellent

1 Follower

About Kylotan

  • Rank
    Moderator - Scripting Languages and Game Mods

Personal Information

  1. Just seems like a bad idea. The game object doesn't need to know about everything in the Application so why pass the whole Application in?
  2. Yes. There's no reason to clear the whole data structure. If I was writing bank software I wouldn't build a whole new database every time someone made a transaction.
  3. "250ms later when I do a second spatial partitioning by inserting all the entities again into the hash" - don't do that. There is no reason to keep recreating the whole structure. "I am inserting it and removing it 4 times already" - why are you worried about moving a single object a few times in a second, when your computer is capable of calculating and showing showing you something like 100 million new pixels every second?
  4. You don't need to perform any changes to the data structure "for every player". You should be able to query the hash based on any arbitrary position you give it. These structures are literally just a way to efficiently implement the following query: List<Entity> FindEntitiesNear(Position x, float max_distance) The data structure needs updating as objects move; whether you do that via deleting and re-adding, or via some internal method that can make the adjustment, is an implementation detail. How often you check for updating a client/player's area of interest is a completely separate issue and has nothing to do with the spatial partitioning. That's a choice you make based on your game's needs. Start with once per second perhaps, and adjust if you need to.
  5. It sounds like you're mixing up the concept of a spatial partitioning method - which is just an efficient data structure for storing and finding things with positions - with the concept of interest management - which is a system for knowing which entities are of interest to which players/clients/whatever. The server should have precisely 1 spatial hash / quadtree / whatever, containing all the relevant entity positions. You can use that to quickly determine which entities are of interest. But that data structure should not be attempting to represent any individual player's area of interest, nor changing based on what a player can see. Most spatial partitioning methods will let you remove an entity and re-add it very efficiently. A simple hash or a grid falls into this category. Some spatial partitioning methods are not quite as effective with that, e.g. kd-trees, and some are in the middle, e.g. octrees. This is the simplest approach, to simply adjust the position in the structure where needed, so start with that, and see if it's performant enough. If it's not, you might find that you get better results by recreating the whole structure, but that seems unlikely except in some extreme cases.
  6. Service locators are to singletons as singletons are to globals; one step improved, but still pretty bad. I mean, I've used service locators before when hacking something together quickly, but they have almost all the same problems that a singleton does: global access to an object leading to high coupling global instances of an object meaning more shared state poorly-defined object lifetimes (usually) superfluous code enforcing that you only ever have 1 object, when there may be times you can make use of multiples Basically, I try to take a step back when thinking about code like this. If I find myself thinking "lots of bits of the code need access to object X", I know that is not really true, and so I try to find one of several strategies for resolving that. e.g. if object X is basically a resource provider (e.g. TextureManager), can we just extract what we need at initialisation time, and pass those objects in directly, instead of querying for them later? if object X is basically an event sink (e.g. SoundPlayer), or an event source (e.g. InputManager) can I just connect to it via generic events/signals/delegates/std::functions/whatever, performing the connections once and then never needing to refer to the object again? if object X is some sort of helper object which doesn't maintain any state, can I make the methods into free functions that can be composed arbitrarily (C, C++, Python, Javascript)? Or can I change the object into a static class (e.g. in C#) for similar effect? if object X is a combination of the above things, or is just accessed everywhere because it performs a lot of different roles, can I split it into separate objects X, Y, Z, each of which might be easier to handle?
  7. If an object needs a reference to the TextureManager to do its job, then give the object a reference to the texture manager. You can pass it in when the object is created. Better still, have the object grab these textures ahead of time, so that when the collision happens, it already has them ready for the change, without needing access to the TextureManager.
  8. Sure, why not? The worst case is that the path becomes invalidated and then you have to redo the pathfinding - just like you would have had to anyway.
  9. Khan Academy is by far the best. Sorry you don't like it! Set the speed to 1.25x if you find it drags a bit too much. Also, the practice sessions between videos are essential. Coursera and the like are basically just university professors who've dumped their undergrad courses online - you get minimal support, few useful exercises, and little attempt to really explain the concepts from base principles.
  10. The same way you'd build scalable units with any other hosting. You consider that your system is going to need to scale in some way, so you design it to share the load across an arbitrary number of processes. Containers are a technology designed to make it easy for you to run an arbitrary number of identical processes. So these 2 concepts work well together. These processes don't care if they are web servers or MMO servers or neural nets analysing cat pictures. The key is that you can start up a lot of them, easily. Containers have nothing to do with state synchronisation - that's what the SpatialOS part does.
  11. You're kind of on the wrong forum for neural network questions. This is for game AI, not for general purpose AI algorithms. Also, few people are going to want to dig through that much of someone else's code, especially given that there are barely any comments in there and a lot of code that is probably irrelevant (e.g. the file loader). What have you done so far to try and solve the problem? Does the error rate ever decrease at all? What does NNet.BackPropagate return? Why not try on just 1 image to begin with? Where is the actual classification taking place?
  12. You'll probably want to read some recent threads on a similar theme: https://www.gamedev.net/forums/topic/690843-top-challenges-of-writing-for-multiplayer-games/ https://www.gamedev.net/forums/topic/690725-first-try/ The main thing you need to be aware of is that games companies, in general, do not hire writers based on reading a story (or part of a story), just like they don't hire artists based on seeing their paintings. Employers usually want to see examples of work as it would be directly used in the game. This might mean things like: sample dialogue between characters the shooting script for a cut-scene race/class descriptions for RPG character creation screens a summary or short treatment for the overall narrative progression through a game On a more sober note, most games companies do not hire writers at all. The majority of writing is either outsourced to contractors - usually veteran writers with a wide range of experience - or delegated to designers, some of whom are likely to have a literary background. You may wish to consider whether one of those routes is better suited to you.
  13. Have you tried just using the binaries from the SDL2 site and the standard instructions? If you encounter a specific problem, you can post it here and I'm sure it can be overcome.
  14. Print 2 copies of each document, and do it both ways. You'll never struggle to find something then.
  15. Units are completely arbitrary.