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

markr

Members
  • Content count

    2743
  • Joined

  • Last visited

Community Reputation

1692 Excellent

About markr

  • Rank
    Contributor
  1. The most efficient way is definitely to use an existing editor.   Use an existing level editor - or maybe even just a pixelmap editor or text editor - and then write whatever conversion utilities are needed to produce the data in the format you want.   Some editors already have some mechanism to make plugins - for example, using a high-level language that won't waste your time too much.   Also consider the amount of time it's going to take your content team to build maps.   A feature-rich third party editor with plugins, add-ons, and conversion utilities, is likely to provide a better user experience with less effort, than trying to roll one from scratch.
  2. The "flood fill" algorithm is essentially Dijkstra's. A* is an optimisation of it.   You can use these even if you don't have a regular grid on your ground, just *pretend* that you do have such a regular grid, and run the algorithm anyway. You only need to write a function "can I pass this point", which needs to be conservative enough that your moving units can actually pass that point to its adjacent points without encountering any new obstacles - so the "can I pass this point" function might need to take into account the distance of nearby objects, and return false even if the point itself appears passable.   Anyway, give it a go, and you'll easily get something that works.
  3. The overhead of checking your global flag isn't that great, provided you don't do it too often.   But don't make the mistake of doing other expensive processing, even if the debug flag is off. Don't format complicated debug strings, then pass them to a debug function to be ignored. Instead, do the check first, before the formatting.   ---   You might also want to consider enabling post-mortem debugging in your app. How to do this depends on the environment, but it's usually possible to collect some kind of crash dump, and ask the users to send this back, which lets you see what went wrong in a production environment that you can't necessarily replicate. A lot of (e.g. PC) games do this.
  4. Don't let the client connect directly to mysql at all, they need to go via a "middle tier" server.   If they connect directly, they'll be able to get the credentials (you can't stop them), then do various attacks (at least Denial of service) against your mysql server. You don't want that.
  5. I'm going to reply and reiterate a very old maxim - premature optimisation is the root of all evil.   Your goal *may* be to make the "open world RPG" with 2000 NPCs and a zillion zones, etc,   But you might be overestimating the amount of content that you can reasonably create. You might subsequently change the scope of the game to be a bit ... smaller.   So don't do anything. Make a few NPCs work in a small world, and once you're happy with that, then you can expand it as you have additional content.   After all, a game with 2000 NPCs and a zillion zones, is really BORING if you don't have varied, detailed content to go with it.
  6. Good, +1.   Perhaps it would also be helpful to have an article which explains (with examples) how we can profile a Javascript game in (e.g.) Firefox or Chrome. As far as I know, both browsers have some kind of profiler built-in, maybe there are alternatives which are more helpful.
  7. Did you play the 1996 Bullfrog game "Genewars" ?   http://en.wikipedia.org/wiki/Genewars   It had some similar ideas.   If it's still feasible, get a copy :)
  8. You're going to have to put some instrumentation in to find out the answer to these questions.   If you implement it incorrectly, A* becomes the same as Dijkstra's algorithm. This still always finds the shortest path, but in some cases takes a lot longer.   You need to produce some test-cases where A* should be considering only a small number of nodes, to check that it really is only considering the nodes it needs to (not going to the opposite side of the map, looking for a shorter route, because there can't be one (assuming no teleporters, time machines etc, in the map))
  9. There are a lot of other reasons games developers might not want to release source code:   * It's a dreadful mess - yes, really * It includes lots of incompatibly-licenced components, in source form, its own source tree, possibly with undocumented modifications * Nobody would *EVER* be able to compile it anyway. The build system is far too arcane and relies on countless other in-house build-time components from the studio, which would also have to be released, modified etc, to give any third party any chance to build the game from source. We don't have time to do all this extra work. * Therefore, nobody would actually be able to benefit from it * Cleaning up the code-base for release, preparing documentation and getting appropriate clearance from legal team etc, takes up time that we don't have when trying to make a game!   Basically, the source code of a real, commercial game is huge, messy and held together with string and duct-tape. Much of it isn't documented. A lot of it is from third parties. The build system is arcane.   Anyone who actually wanted to licence the source code to title X, would have to gain IP authorisation from all the dependency libraries (do-able, if it was another game dev house), buy licences for all the commercial tools required to build it, and get considerable support from the original dev team.   This is not going to happen for a A+ title. It might happen for a small mobile game or something, but it's fairly unlikely.
  10. You need to "notionally" do network access to get these data for images. But the images might come from the browser's cache if they're already available. You can encourage or enforce caching through a combination of web server headers and a cache-manifest file. Or you can just preload your images when your game starts so they're already available.   Once you have an Image object in memory, and you're holding a reference to it, it's not going to go away and you can use it without a problem. But when a player comes back to play the game again (in the same browser session or a different one), the assets need to come either from the server or the browser cache.
  11. Image elements don't work on that level. You can't ask the Image object for its binary data. You can in principle extract the pixel data from an image, which might be an idea for loading maps or other assets.   If you want to do file IO for arbitrary (non-image) files, use XMLHttpRequest.
  12. You should probably do the simplest thing which can possibly work and work on performance later.   Use a single socket. In practice it is generally easier to work with fewer sockets (i.e. just 1) rather than lots. You can easily multiplex many clients on a single socket by just processing packets as they arrive.   However, you should still consider using TCP as it solves a lot of problems for you and might be ok, depending on what kind of game you are making.
  13. I think fundamentally the problem is that you need to move the viewport, not the world.   You need to be thinking about everything internally in world-space coordinates, and only convert to screen-coordinates just before rendering. Doing anything else will cause you to lose your sanity.   You need to independently maintain the location of the viewport and the car, even if one is derived from the other.   http://marksverbiage.blogspot.co.uk/2012/04/move-viewport-not-world.html
  14. Really having a few globals hanging around is not so bad, especially if they are in their own namespace and there aren't *too many*.   So if you have a few "big objects" which you want global instances lying around, then use globals, it's not really a problem.   The problem really starts when:   * The maintenance programmer can't tell which variables are globals / members / locals etc, easily * There is so much unstructured global state that it becomes easy to get "stale data" bugs.
  15. It is extremely unlikely to be a problem.   You need to think about macro rather than micro. Use the simplest scheme that you think might work.   The key is to avoid anything which is greater than O(N) on a regular basis (e.g. each frame). Even the N^2 "every object against every other object" is not really so bad provided the number of objects doesn't get too big.   It's really possible to iterate a lot of vectors - really, lots - each frame, without problems.