• Content count

  • Joined

  • Last visited

  • Days Won


hplus0603 last won the day on June 20

hplus0603 had the most liked content!

Community Reputation

11362 Excellent


About hplus0603

  • Rank
    Moderator - Multiplayer and Network Programming

Personal Information

  • Interests


  • Twitter
  • Github
  1. Yes, a Raspberry Pi can be a "server" because a "server" is just a computing machine that responds to requests from other nodes on the internet according to some rules that you decide. A Raspberry Pi 1 is probably about the same compute power as the server computers that ran the game EverQuest, one of the first really big MMOs (back in 2000 or so.) That being said, a Raspberry Pi does not allow you to hook up very durable media -- the compact flash is not designed for constant reading/writing over long times. Perhaps a hard disk on USB could solve that? What's harder is to figure out how those other machines would find your server. If you have a typical home Internet service, you have a single IP address, and that address goes to your router. You'd then have to port forward from the router to your Raspberry Pi. You'd then have to register a domain name, and make it map to your IP address. And, when your ISP changes your home IP address (which happens automatically every so often without warning or notice,) you'd have to update the DNS to map to the new address, and wait for DNS caching to expire, so some users couldn't find your server for a while. This is why servers live in data centers. They can have a fixed IP address, and a squirrel chewing on your internet wire won't knock you offline, and a heatwave won't make your home computer suddenly overheat while you're not even there to do anything about it. Using a web host of some sort is much easier. Even better is something like a virtual private server -- be it Linode ($10/month,) interserver ($6/month,) or Amazon Lightsail ($5/month and up, plus networking fees.) Of course, as your server needs grow, you will need to pay more for the server hosting. So, your web hosting provider has a plan that lets you "host" somehow? It's hard to tell exactly what that means. It might be a small container / virtual machine. At that point, you could build your own service using whatever tech you want (C++, node.js, golang, python, erlang, C#, Java, Haskell, PHP, ...) and have your apps talk to your service. You still need to register a domain name, and make "api.yourgamename.com" or somesuch point to that server's IP. Or you can use Game Center on iOS and Google Play Services on Android. Sounds simpler :-)
  2. Most of the Xbox SDK is behind the Microsoft NDA, so obviously it can't be public Google hits. You might want to ask your Unity support contact about what they recommend (assuming you're using Unity Pro.) Again, the Xbox SDK is under NDA which means you can't talk about specifics in public forums.
  3. Separately, if you pay $65 for the module, and it turns out that "all" you get out of it is a lot of learning about how voice chat integration works, that seems like very cheap education and a good deal to me :-)
  4. On Xbox One, you're supposed to use the Xbox Live voice chat services. Do you have a contact at Microsoft already? Dev kit?
  5. What targets do you use in Unity? Something that supports all of the targets (desktop, mobile, web, consoles) would be quite hard to build and integrate (and the consoles have their own that you have to use, anyway.) Depending on your targets, you could integrate third party libraries that aren't Unity specific. There are a number, ranging from "codec plus UDP" all the way up to complete services with support for NAT punch-through, peer-to-peer, and even routing to the PSTN. However, exactly how strapped for cash are you when you consider $65/seat to be too pricey? If it just works, and have great ratings, why wouldn't you go with that?
  6. Lag Compensated Projectiles

    It sounds like what you want is: When receiving a new projectile from client. Figure out when it was fired. Rewind simulation to that point. Step simulation forward for projectile until the "current frame" in server, while putting all nearby colliders at whatever positions they had at each of those time steps. If the projectile hits something, apply that damage, which means you re-write history for the targeted entity (it will need a correction.) Once you've rolled the projectile forward to current frame, it will run the same as any other entity until it dies. The main optimization is "which entities need to be put temporarily back in time while the projectile simulates forward?" You can typically answer this question by keeping a maximum-velocity value per entity, and calculate the envelope of the projectile for the travel time you're rolling forward, and only actually testing the entities whose current position plus radius plus max-velocity-times-rollback-time intersects with the projectile trajectory envelope (bounds.) Or, alternatively, inflate the projectile envelope by the maximum velocity of any target object, and check that against the current bounds of possible targets (this may be cheaper, depending on your implementation specifics.)
  7. You cannot put things with constructors into unions, for the reason you state in the very top of your post: constructors/destructors become ambiguous. Which destructor, if any, should the compiler call when the union goes out of scope? The work-around involves inheritance and constructors: class Point2; struct Point2Base { float x; float y; Point2 &asPoint() { return *(Point2*)this; } }; class Point2 : public Point2Base { public: // WARNING: Not explicit! Point2(Point2Base const &c) : Point2Base(c) {} void myFunction(); }; union MyUnion { struct { float x, y, z; } a; struct { Point2Base p; } b; }; // OBSERVE: Value, not reference void function_taking_point2(Point2 p2) { } int main() { MyUnion u; function_taking_point2(u.b.p); return 0; } VERY IMPORTANT though: If you pass u.b.p by reference, a temporary will be created, and you'll see the reference to the temporary in the called function, which is not why you want. This is why single-argument constructors should generally be made "explicit." That will break the convenience of passing values to functions, and you'll have to use asPoint() instead. Here's a safer, slightly less convenient version: class Point2; struct Point2Base { float x; float y; Point2 &asPoint() { return *(Point2*)this; } }; class Point2 : public Point2Base { public: // GOOD: uses explicit constructor explicit Point2(Point2Base const &c) : Point2Base(c) {} void myFunction(); }; union MyUnion { struct { float x, y, z; } a; struct { Point2Base p; } b; }; // Uses reference void function_taking_point2(Point2 const &p2) { } int main() { MyUnion u; // Must use cast function function_taking_point2(u.b.p.asPoint()); return 0; } Finally, note that the member function "asPoint()" doesn't disqualify Point2Base from being considered POD. Constructors, destructors, and virtual member functions will disqualify a compound, but not plain member functions or static member functions.
  8. Is Sublime Text a valid option for C++ development?

    There are two schools of thought on this: - School A: The IDE should do everything (project management, code editing, debugging, etc) so you only stay in one GUI for the entire project lifecycle. Visual Studio (a great IDE) thinks like this. XCode (not as good an IDE) also thinks like this. Eclipse, Android Studio, and a bunch of others also follow this pattern. Sublime doesn't work very well in this world, not because of Sublime itself, but because the IDE isn't great at letting any outside tool in. - School B: Each tool should do what it's good at. gcc, or clang, or cl, compile code. make, or nmake, or msbuild, (or ninja/sbt/cabal/scons/whatever) calls compilers to run builds. Vim, or emacs, or whatever you want, edits text. In this world, Sublime is totally fine. Call this "command line development" for lack of a better term. There's also the question of how you generate your project files (for IDEs) or make/build files (for command line.) Tools like cmake, premake, automake, and so forth, take it upon themselves to scan through your source code and generate the necessary make/project files for whatever your target development environment is. When you need to develop for many environments, this may add value. When you're just doing a single environment, building a simple make file yourself is quite likely to be simpler.
  9. Image Processing Server

    No durable message queue is optimized for low latency. The original request was for setting up a system that spreads load across GPUs for real-time processing. Presumably it's better to lose a few frames, than to have to process through old and outdated frames, when the system hiccups. The original poster was not saying that multiple steps are spread across machines. The original requirement stated was that the results of the computer vision type analysis would be exported to some other machine.
  10. Image Processing Server

    Are all of the cameras and processing cards in the same local network (such as in a car or in a closet) and do you control all the traffic on the systems? If you control all the traffic, then TCP and TCP-based protocols (such as HTTP) could work fine, because packet loss will be very rare, and your "real time" requirements won't be impacted. If the system requires some kind of shared link -- internet uplink, shared switch with other application data, office LAN, or what have you -- then there is some risk that TCP-based protocols will end up sometimes "hiccup-ing" because of packet loss and re-send intervals. If you'd rather just have the next frame of data, than wait for the previous frame, when packet loss happens, then you need to use some protocol on top of UDP. When going over UDP, there are also encodings that allow you to send a few more packets per frame, but recover from some number of lost packets. (Look into self-correcting codes, self-healing protocols, and so forth.) The rest of your problem isn't really possible to given good advice about unless we have a lot more information about your specific system hardware and requirements.
  11. Database Structure for MMO's

    It's great that you point out the limit on number of columns of many databases (typically 255, but check your specific database!) I don't think SQL people will necessary beat anyone up for having lots of columns. After all, for a customer record, we don't create separate property tables for "name" and "email address" and "mailing address line 1." If you think this table is fine: CREATE TABLE customer( customer_id NOT NULL INTEGER, name VARCHAR(255), email VARCHAR(255), address1 VARCHAR(255), address2 VARCHAR(255), mailing_code VARCHAR(255), mailing_city VARCHAR(255), mailing_country VARCHAR(255), phone VARCHAR(255), PRIMARY KEY(customer_id)); Then why is this table bad? CREATE TABLE character( player_id NOT NULL INTEGER, character_id NOT NULL INTEGER, strength INTEGER, dexterity INTEGER, mana INTEGER, swords INTEGER, polearms INTEGER, shields INTEGER, dodge INTEGER, swimming INTEGER, PRIMARY KEY(player_id, character_id)); If you specifically use MySQL/InnoDB, you can even make your tables allow adding more columns without having to update table stores, by pre-creating 255 columns as nullable, named "future_01," "future_02" and so on. Nullable columns end up only taking a bit in the record when they don't have a value, and you wouldn't be referencing them. Then, when you introduce a new skill, ALTER TABLE RENAME some future_ column to the skill you need. That's a very fast data dictionary update! I also don't understand why serializing out of a single row would be any more or less work than serializing out of a self-join table or out of a BLOB/TEXT field. You still have to look up the string "strength" to some integer variable somewhere, and you very likely want to write that as some kind of IDL that generates code from schema, rather than manually doing it, no matter which of the options you choose. For most smaller games, the one-row-per-character option is actually surprisingly usable, and surprisingly easy to work with. You only need to bring out the bigger guns if your design and implementation actually exceed what you can do with that initial approach.
  12. Recreating graphics from example work.

    In general, what you're looking at is a question about whether a particular use counts as "fair use" under copyright in your jurisdiction. (The US?) Perhaps you're also wondering whether there is an implied contract from the original teamwork. (If there is, it's probably one that the original artist would expect an equal share of profits, so it's unlikely you'd want to rely on that, even if there was one, which there probably isn't.) In copyright, "fair use" is totally a thing, as is "transformative work." You might want to read up on those, and talk to a copyright lawyer in your jurisdiction how those terms have actually been applied in cases that matter. In brief, here is how I think about it, for my own cases: I can go to a museum, and be inspired by the art, and make my own thing that looks like the museum art. But, I cannot "clone" the art in a museum (unless the artist is dead for long enough that copyright has expired.) If I'm using the concept art as inspiration, but my own creation is reasonably clearly my own, then being inspired by the original concept art is totally fine. Artists get inspired by other artists all the time. If my in-game art is an almost pixel-perfect replica of the original art, except I re-drew it painstakingly in Photoshop because I didn't have the source files, then that's probably less fair use, and I'd probably be taking a real risk. (One possible defense might be "transformative use" where a live game is different from a static concept sketch -- no idea how that would fly if someone actually went to court. Again, ask a professional in your area!) To avoid that risk, get the guy's OK, or make sure that the actual art used in the game is somewhat obviously something you created, just inspired by the other art, rather than a clone of it.
  13. Note that inadmissible heuristics are totally fine, as long as you want "a" path rather than "the best" path. Sometimes, inadmissible heuristics will be just the ticket to make pathfinding run well. In this particular case, I'd first look at why PathQuery.LineOfSight() takes so much time. A simple greedy path simplification algorithm should basically run in linear time. Then, I'd look at whether there are calls to functions that don't need to be made. Then, I'd look at functions that are virtual, and see if they could be made non-virtual. Or maybe even inline. If all of that still doesn't work, then also look at whether you can re-use previous path finding from other entities, whether you can remember cached segments and re-use them, and whether you can implement a hierarchical finder. Split the 256 grid in 16x16 cells, and classify connectivity between edges as a pre-processing step. Run pathfinding through this coarse grid. Once that works, you can run a single refine step on the found path, and end up with a fine result. Or you can build passable segments by "inflating" interior geometry (boxes, or spheres) until they hit non-passable areas, and know which pieces connect to which other pieces, and just path-find between pieces rather than cells. Again, a final pass of smoothing will fix up the path.
  14. Database Structure for MMO's

    You're hitting the nail on the head: Untyped, dynamic systems are great for smaller systems and prototyping, where getting to "can this work" and trying out ideas quickly is more important than operational concerns and long-term maintenance. Typed, static systems typically require a bit more lifting to get started in, and the benefits don't pay off until the system grows, and you're starting to maintain it and having to live with data and decisions made months and years ago, and having to understand how dozens or hundreds of modules may interact. This is true for programming languages, for databases, for network protocols, and most other design areas in computer science. For a start-up with a limited amount of money, looking for product/market fit, the ability to try lots of things quickly is more important than the cost of maintenance, and the code is by definition small. For an established organization, that knows who the customers are, and know what the product is and will continue to grow into, the trade-off is different. (For companies that succeed, there's this hard, harrowing time in the middle, where the company has to transition from soft/dynamic to hard/static methods, which is another topic in and of it's own :-)
  15. Ah, so you actually have gameplay before the matchmaking happens. Thanks for clarifying!