markr

Members
  • Content count

    2743
  • Joined

  • Last visited

Community Reputation

1692 Excellent

About markr

  • Rank
    Contributor
  1. Creating a map editor

    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. pathfinding on a 2d map

    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. What to do for debugging

    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. A diffrent type of rts.

    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. A* on large Map

    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. You Don't Need to Hide Your Source Code

    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. Map Clipping

    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. Using global variables - really so bad?

    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.