Firestryke31

Members
  • Content count

    110
  • Joined

  • Last visited

Community Reputation

350 Neutral

About Firestryke31

  • Rank
    Member

Personal Information

  1. Is anyone else having doubts about the Raspberry Pi?

      You could always just poke a few holes in the box it came in and use that as a case. I'm considering doing that with mine for until I can get around to getting the bits I need to make the things I want to make.
  2. Web game design - high level questions

    I think HTML5+JS should be plenty fine for replacing most Flash games. You get audio, the ability to draw to a portion of the screen, and user input, and that's all you really need. I'm in the process of creating my own HTML5+JS game as a learning project, and I managed to get stuff on the screen pretty darn quickly. If you're already at least somewhat used to working in JS, you'd probably be better off using it initially, at very least for prototyping. Plus it's completely free, available on most modern mobile devices, and some think not being tied to Adobe is a plus.
  3. You might also consider getting a certificate with which you can sign the executable if you're planning on ever selling anything. IIRC you can use it for signing as much as you want, but be sure to keep it safe so others can't sign stuff as you. Don't ask me about details though, I've never gotten far enough to be worth getting one.
  4. Help with String Hashing

    For when to use hashing, you should use it when you'd need to otherwise do lots of string comparisons. What you do is when you get a string (say an object name) you hash it and store it with the object (in addition to the name, usually). Then, when you need to look up an object by a string name, you can instead hash what you're searching for, then compare the hashes with a single integer comparison. You'll probably get collisions, so once you find a matching hash [i]then[/i] you do a string comparison to make sure you have the right one. In the case where you have 10,000 objects with an average name length of lets say 9 characters, and the worst case scenario of the object you're after being the last one, you could do either an average of 100,000 char-comparisons (including null-terminators at the end of the string) or you could do 10,000 int-comparisons and maybe 1000 char comparisons. ~11,000 < ~100,000, so I know what I'd choose. The hashing function I've been considering using is the [url="http://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function"]Fowler–Noll–Vo[/url] 1a variant, though you can look at some others to see what might best fit your needs. [CODE] uint32_t getHash(const char *str) { // Implementation of the Fowler–Noll–Vo-1a hash function uint32_t hash = 0x811C9DC5; // Actually I use a defined constant here, but this is the seed for a 32-bit hash for(size_t i = 0; str[i]; ++i) { // The FNV-1a variation hash ^= str[i]; hash *= 0x01000193; // Same for this, this is the 32-bit prime number } // Wow that was hard. return hash; } [/CODE] (excuse the lack of indentation, HTML eats "extraneous" whitespace). I treat it basically like a one-function library, I don't try to understand how it works as long as it does what it says it should. There's a lot of math behind the structure and numbers used and I write games, not hashing functions.
  5. 2D Tile Transitions (Efficiency)

    I haven't done this before, but given that I'm going to someday (I'm slowly working on a hex-based TBS) my first suggestion would be to just try the alpha blending and only count it out if you're 100% sure that it's going to be a problem. If you decide to draw with textured quads rendered by OpenGL or DirectX then it's basically free. I think the trick for newbies is to get it working first, then get it working well. On my to do list is to try it out.
  6. Buying existing code to lower costs?

    I think COHO, Starcraft 2 and W40k Dawn of War 2 all use the same underlying engine in their games (if not then color me surprised) but as far as not prebuilt engines I think the best you're going to do is the more framework kind of things like enet and boost::asio that merely make it easier for you to do your own system. Really, there's two different levels for the networking code: The part that shovels data around and the part that takes that data and turns it into game play. That second part is the killer, and depends entirely on the game itself since it's poking around directly in the game state (or, better yet, sending it's translated data directly to the input system).
  7. Games like WoW usually split their players among several physical servers for each realm (i.e. Emerald Dream might have 4 physical servers) and each server then handles it's own subset of the players connected. The original Planetside had a limit of around 200 players per faction (for a total of 600ish) on an in-game continent (each of which was probably it's own server) and that was a fast-action FPS from back in the mid 2000s. The AI might cause some concern, but if you implement it intelligently you should be fine. I don't know how TF2 is typically hosted, but if it's either a pick-a-client-and-they're-host or a downloadable server thing then it has to be able to handle a wide variety of hardware capabilities. If you're controlling the servers yourself, 40 players and 20+ AI should be plenty doable as long as you design it intelligently.
  8. Titlescreen Art ( want opinions )

    I think it looks very decent. A couple of major games off the top of my head that have similar title styles are Skyrim and Guild Wars 2, and I can see it fitting right in with them.
  9. Sorry, I forgot to mention that my sample was just pseudocode (and apparently I completely forgot to decrement the accumulated time in the loop). One thing you might possibly consider is, in a separate "game state," stepping one step into the future, and passing the post-looping [font=courier new,courier,monospace]total_time / UPDATE_STEP[/font] to the renderer to interpolate between the current step and the "future" step, giving smoother animations.
  10. I second reading that link, it's pretty helpful for this situation. The gist of it is [source]totalTime = 0; while(notDeadYet) { startUpdate = timestamp(); while(totalTime >= UPDATE_STEP) { Update(); // Simulates exactly UPDATE_STEP amount of time each call } Render(); // Renders the latest tick totalTime += timestamp() - startUpdate; }[/source] This way at 200 FPS you only update the simulation every X frames, but at 20 FPS you update multiple times a frame as needed. Animations are smoother as you're taking snapshots of a guaranteed smooth stepping, and it's easier to ensure physics are accurate as they're no longer framerate-dependant.
  11. Massively Multiplayer Server Design

    Perhaps send the "current" server tick as part of the heartbeat?
  12. Massively Multiplayer Server Design

    [quote name='Spr33' timestamp='1344474816' post='4967598'] Did you read the side-notes? I pretty much covered the health regeneration part down there, saying that it would only need to be updated by the server when necessary (when damaged to check for death, or upon skill usage to check for sufficient MP)... In fact; the main reason I brought up having health solely updated via packet from the server is because he seems to be stressing on security, for this specific game. In case you've mistaken what I said in the side-note; when I say that HP/MP/Etc. "should be synchronized with the client," I mean that the client and server should increment the player's HP at the same rate, I didn't mean to imply that it was a good idea for the server to constantly send the player's HP value, as that would be ridiculously unnecessary (the whole purpose of the side-note was to make a statement going against what #1 said!). [/quote] There were side notes? Why are there side notes? Why do they directly conflict with what you said? If you want to say something, don't confuse people by saying something and then later on going "oh by the way that one thing yeah I meant the exact opposite." [quote name='Spr33' timestamp='1344474816' post='4967598'] That's a given, I was just picking out the flaws in his system based on exactly what he has said, so I had to bring that up [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img] [/quote] So you're being a pedantic dickweed? [quote name='Spr33' timestamp='1344474816' post='4967598'] I am perfectly aware of the applications of AI in online games, though I think you should read over exactly what he said, perhaps then you might see why I'm picking on this little detail (again, I am taking what he said literally). [/quote] More pedantic dickweedery. All that's needed to be said is "don't forget to treat the AI as a somebody." [quote name='Spr33' timestamp='1344474816' post='4967598'] That's exactly what I was getting at. Too bad it won't entirely work with his server, as it doesn't seem to have a scheduler D: [/quote] Why does it need a scheduler? And even then, why are you assuming he doesn't have one? Just store that the user started the cooldown for ability X at time T, and that it will last for Y seconds. When the user tries to use ability X again, the server checks the player's cooldowns for ability X, and if the current time is >= T+Y let the user do it. If not, send that the user still has Z cooldown remaining for that ability. Ideally it would remove expired cooldowns every now and then as well to cut down on the data to search through. [quote name='Spr33' timestamp='1344474816' post='4967598'] You really haven't told me anything new here. Honestly, a client with an intelligently designed path-finding system would only require x, y(, z) coordinates to be sent, the generated path should obviously match the one generated by the server, but this shouldn't be an issue since the sources would be the same. Of course, just sending the coordinates would be solely for the purpose of cutting back on packet-size, the server would still have to generate the NPCs path (storing the sort-of movement-history, which should match what the client will generate, in an array). [/quote] Of course. This is what I was trying to say. I was thinking non-lockstep for sending the whole path, but since the client state and server state should be the same just sending the final destination should be enough. I think you could have been much more clear with your communication by leaving out all of the little jabs and just getting to the point. Humor is okay but must be used to supplant the point being made, not obscure it. I will say that this thread is good for me because it's making me think how to implement my own multiplayer system, albeit not MMO (While there will only be 4 players in a match in the current iteration of the game, I want to stuff as many matches as possible onto a server and possibly allow people to watch a match, so I need to keep in mind some of the same optimization techniques).
  13. Massively Multiplayer Server Design

    Packets should only be sent when something happens that both sides need to know about. There is only one exception I can think of that, for 2). 1) Health regen does not need to be sent every update, as the client and server are both capable of figuring out what it should be based on what they know. The server should only sync this periodically when something happens to cause it to be different (i.e. getting attacked or healed). 2) The heartbeat should be the only packet transmitted without any event requirements. This solves the sudden logout problem, as if the server sends a heartbeat and doesn't get a response in say 15 seconds it considers the client DCed. 3) The server will transmit AI events to the players that it would be reasonable to (i.e. don't send it to player F that's 100 game-miles away). The AI is considered a "someone" for the purposes of packet transmission. Anyone who has done any kind of online game work (and even intelligent people who haven't) should know this. 4) For cooldowns, option 3 is probably the best, and I'll give you this one on not being obvious. For a MMO, there's no reason to send everyone the entire game state every frame. There's not even a reason to send them their own entire state every frame. The client should only be notified of changes to the game state that it can't figure out on it's own. Don't send the AI's position every frame. Send a path that the AI will take, and let the client figure out where on the path the AI is. If the client hacks the game so that the AI is "rooted" in a specific place on their client, it doesn't matter because the server says the AI's here, not there. At worst, the server just has to sync the occasional object every now and then.
  14. Isometric Hex Picking

    I don't see how it's all that different from regular isometric: Hex: (Ignore the "Stop deleting my spaces HTML" dots) [source lang="plain"] .__ .. __ / A\__/ B\ \__/ C\__/ / D\__/ E\ \__/ F\__/ [/source] Iso: [source lang="plain"] /A\ /B\ \ /C\ / /D\ /E\ \ /F\ /[/source] The only difference I see drawing/picking logic wise is the tiles are a little wider and slightly differently shaped.
  15. NPC dialogues : file or script?

    What about a little of both? XML stores the actual strings and gives them names (i.e. <string id="hello">Hello, <var ref="playerName" />!</string>) and a scripting language allows you to conditionally display the strings by ID and change player state based on the selected responses and other conditions.