• Content count

  • Joined

  • Last visited

Community Reputation

17565 Excellent

About SeanMiddleditch

  • Rank

Personal Information

  1. No, it isn't. Purely for legal liability reasons, game companies do not take solicitations from third parties on game ideas. It opens them up to cases were you propose a game they're not interested in right now, then some years later long after forgetting about you someone else proposes something vaguely similar and they start it up, and then you sue them for stealing your idea. Tossing your idea directly into the shredder without even glancing at the title is _by far_ the smartest thing for them to do. Let's not also forget the company's employees' own creativity. Why would anyone want to sign up to work on _your_ idea instead of working on _their own_ idea? Same applies to a large company like Ubisoft; why would they work with an unproven and unknown outside party instead of greenlighting one of the countless game ideas their own employees are kicking around by the thousands? That said, it is entirely possible to be approached by such a company if you make a prototype that's widely known and received. It was common some years back for companies to approach students in competitions like IGF or IGC to hire the team to remake the game as a commercial project. The most famous example of that is Valve's Portal ("inspired" from the student game Narbacular Drop). The important bit is that the students didn't approach Value, but rather Valve approached the students, after they already put a solid year+ of very hard work into a competition-grade student game and demonstrated first-hand that their ideas were actually original and clever, that the core concept actually worked as a game, and that the students could actually do meaningful work coding and designing the game.
  2. Unity Devide a scene to increase fps.

    Someone else mentioned the word "culling" which is a key part of the equation here. This is related to those for loops. If 15,000 objects aren't on your screen, there's no need to loop over them when drawing. You already have a quad tree for physics so you've got the basics of the solution in place already: use a scene partitioning system to efficiently find the subset of objects that are actually visible. If 6 sprites are visible and 15,000 are not, your rendering code should only even try to draw those 6 sprites and entirely ignore the other 15,000. A good scene graph (or even just a quad-tree) helps here a massive amount. You can hypothetically reduce your O(N) rendering to O(log(N)) or less which is a huge win. One of your for loops then basically goes away. You never need to iterate over the static objects. Never. Both graphics and physics should be using an efficient graph of some kind to find relevant objects. (Note that physics and graphics might use _different_ graphs, because what makes the most sense for physics isn't necessarily true for graphics.) You can then also heavily reduce the load on your dynamic objects for loop. After all, collision detection is already using an efficient data structure and you'll be changing your graphics to also use a tree of some kind, so the only work for dynamic objects that remains is to apply velocity. Luckily, that work only needs to be done on objects that _have_ a non-zero velocity. You can thus split your dynamic objects into two sets: active and inactive objects. The active objects are the ones that are currently moving. After that split, you might notice that there's no longer any practical difference between static and dynamic objects, so you can perhaps remove that entire concept from the code. Objects with velocity (or some other forces) are put into the active set and are removed from the active set when they stop moving. The physics code need only loop over the active objects to apply velocity and forces. The collision system uses an efficient graph. Rendering uses an efficient graph. Unless you (foolishly) make all 15,000 objects active at the same time, you never need to loop over all your objects even once, much less twice. The next big step then is the batching improvements others have recommended. The third big step I'd recommend is to use an accelerator like PyPy or whatever's in vogue today. Remember that even the simplest operation like adding two small integers should just be a single ADD instruction on the CPU, but in plain ol' CPython that same operation can take hundreds of CPU instructions, branches, memory accesses, and so on. Python does not translate to CPU code very well and requires a sophisticated JIT engine to do even marginally well in terms of performance, and Python does not include such a JIT engine out of the box like JavaScript engines do, so you have to use an add-on/replacement like PyPy.
  3. SpeedTree 8 for Lumberyard Now Available

    SpeedTree. Lumberyard. Heh.
  4.   Jeebs. We've been complaining about a mere 20 minute full rebuild time and are getting ready to throw engineering resources at dropping it back closer to 5 minutes, and I'd still consider 5 minutes to be excessive. :)
  5. [Enet] Multiple Client connections

    I don't know ENet, but looking over the docs and your code quickly, I don't see an immediate problem, but I'm lacking some context. You _should_ be receiving a single CONNECT message per client connection, and each one should have a unique instance of ENetPeer which you can freely modify and store data upon as in your code. You should not be receiving a DISCONNECT message between the first and second client connection if you're expecting them both to be active; are you? Are the addresses of your peer pointers difference for each CONNECT message or is the same peer being recycled? Highly unrelated note:     // Bind the server to port 1234     address.port = 8484; this is a perfect example of why comments should not just repeat what the code is (supposedly) doing. :)
  6.   Valgrind is a poor fit for games, unfortunately. Its biggest problem is that it effectively runs as a full emulator and will make a game run 100x slower; if just hooking allocations is too slow, that's certainly not possible. Valgrind also isn't compatible with Windows which is a deal breaker for most game developers. There are toolkits that do similar things which manage to be both far faster and Windows-compatible, though perhaps without quite as much accuracy.   Highly recommended. One of our engineers just hooked this up to our (big AAA) game recently and we've been impressed. A custom tool like Hodgman recommended can still have a lot of benefits that you won't get with MTuner but a custom tool would probably be overkill for the OP. Someone needs to write one of these as open source. It's an easy enough problem to tackle for someone with the time and experience. :)
  7. If hooking allocation functions is causing the game to run that slowly, that's probably an indication that you're doing _waaaaay_ too much allocation during the game loop. Which in turn probably causes fragmentation. Also means you've got that much more room to mess up and leak (though with modern C++ programming, that should be rare). It also could mean that fragmentation is leading to allocation failure. An idealized game preallocates as much memory as it needs before entering a level or whatnot and never allocates again. Larger open world games can get by with good object pools and paging techniques, though this takes a lot of effort and discipline. If your third party libraries are the source of allocations, you have some mitigations. Most third-party libraries made for games allow hooking the library's allocation routines. You could use those hooks to pass the libraries straight to the fast allocator and then only override the allocator for your game code, and verify whether your own code is leaking. Alternatively, you can enable the leak detector individually for each library to track down the culprit. If it's just fragmentation, hooking the offending library to use its own small block pool allocator may be the solution.
  8. That isn't the real problem with them. The main problem is that they just don't work the way most people think they do, and it's fairly trivial to break them in larger build systems. And part of _that_ problem is that pragma once is not well-defined. Namely, how does the compiler decide that a header has already been included? Is it the file's inode? Relative path name? Absolute path name (including symlinks? multiple mount points? etc.) ? What about a file that is accessed through two separate paths that go through two separate virtual filesystems (like an NFS mount to the localhost and the direct local path? yes, there are systems setup like this, and can be relevant to games on Linux-based CI systems). This also comes up on some weirder systems (not relevant to games) that don't have directory structures similar to the POSIX/Win32 model. Basically, it's impossible to make pragma once work reliably the way people expect. There simple isn't a way to uniquely identify a file across all possible file systems, platforms, and weird things some platforms can do with reparse or mount points or network filesystems and so on. The compiler differences do come up. For instance, porting code between GCC and MSVC when using precompiled headers on both can be a little tricky specifically because of the different rules each have surrounding #pragma once. Those differing rules also make it impossible to standardize, since if it were then one or the other would be required to change behavior and break existing code.   #pragma once will never be standardized since it is inherently broken as described above. The #once proposal is basically just a syntactic shortcut to include guards: the #once syntax requires an additional token (just like an include guard) to identify the file which is intended to be unique (though it could be used to ensure that only one of a particular set of files is included by sharing the identifier between them). "#once foo" essentially just wraps the file contents in "#ifndef FOO #define FOO #endif". And even that's super unlikely, because Modules will kind of make traditional headers obsolete anyway.   ... all that said, I just use #pragma once myself. :p
  9. how to do a building timer?

    I wouldn't necessarily do a _timer_ at all. A timer implies some kind of eventual state change. It implies an eventual computation and an eventual event. If you start building, you must send an event to all players, and then upon completion, send a second. And know when the completion happens, efficiently. That's a lot of stuff. Instead, just store the building as state with its initial build time and its expected completion time. Send both to the clients in a single event. Now all clients know when the building will be completed and can update themselves accordingly with no further involvement from the server. For big Web-scale MMO things, you want to avoid every possible computation you can. Work in the minimal state changes possible. Create the building with all state it needs to know its current and eventual building state. If something changes the expected state (additional resources put into construction, for example) then update the state and expected completion and send that event to all clients (they'll need an event anyway to make the proper UI changes and the like). Minimal effort/data/events.
  10.   It's kind of a weird beast in terms of type system classification. If you very strongly prefer static typing as all just and goodly folk do, look at the compiler options that enforce all the extra rules. Out of the box, TS is geared for incrementally adding typing to existing JS codebases which isn't necessarily the best default for a brand new project that wants to be good about typing right out of the gate.
  11. There are a few questions to answer to guide you on the righ tpath here: (1) what languages do you know and are you comfortable with? what about the rest of your team? (2) what language and technology is your game written in? do you need to share code between the game and tools? (3) do you _need_ multi-platform capabilities? that vast, vast, VAST majority of game development is done on Windows, even for games that are released on other platforms. that's not only because of the game tools, but also tools like ZBrush, Maya, Photoshop, and a myriad of other game content creation tools that you need to actually make a game are either Windows-only or Windows/macOS-only. Linux is so far at the bottom of the barrel as to be irrelevant in terms of content development platforms, and making your tools run on Linux is only going to solve a teensy tiny fraction of the problems with using Linux for content development. Note that C# and C++ both have cross-platform GUIs that support macOS and Linux if you do want it. A lot of companies choose C# for everything that isn't the core engine. A lot of companies also stick to C++ and use Qt for tighter integration. Some even use Python for various things, particularly since modern Maya scripting and plugins use Python heavily. Some related points:     Use Typescript if you go this route. I'll go so far as to make that a blanket statement: programming in plain ol' JavaScript _ever again_ is for suckers. Don't be a sucker. :) A very related alternative to Electron, btw, would be to use Chromium Embedded Framework. Or whatever Qt's current favored incarnation of its HTML5 widget is. Write the core app/engine in C++ and then use HTML5/TypeScript for all the editor UI and editor logic.     You could always make them a separate free download, assuming this is a game. The vast majority of players will never use the tools, so even if the tools are small, your game itself will be "bloated" if you distribute them to everyone. :P     It absolutely supports macOS. :)
  12. Looking for game engine / game lib -- focused on 2D, but fully free, low-level library approach, widely used -- free 3D engine, comparable to what you should expect from a free engine -- basically Crytek, not technically "free" but you don't have to pay anything -- ... it's Unreal, not technically "free" but you don't have to pay anything   I don't comprehend your complaints about Unity's licensing. If that's really a problem scratch off the last two above as well. The only way those will be _actual_ licensing costs for you though is if you're one of the 0.0005% of indie game developers who actually make any significant money from your project (and if you magically are one of the Chosen Few that even manages to break even, the cost is very affordable and reasonable).
  13. Going to GDC?

    I think this is declining fairly rapidly (the odds of your card just getting a weird look while someone pulls out their phone to enter your info directly or trade via NFC are increasing) but it's definitely still good enough advice for now. I give it to 2020 before cards are a complete relic. :P I might be biased though because my company's cards are garbage solid-black affairs that you can't scribble notes on and I end up using maybe 1 or 2 every GDC. Which reminds me - anyone printing custom cards, always leave the back entirely/mostly plain white. The blank space is as valuable (if not more so) than everything else on it. :)
  14. As others have said. The things to watch out for that GL does differently than D3D are mostly just two things: - the GL NDC has a depth range of -1..+1 rather than 0..+1, so you have to construct your projection matrices accordingly to get full precision. This one is easy to ignore but you shouldn't. - GL has inverted texture coordinates from D3D, requiring textures to either be flipped when loaded or shaders to invert the access. This is the most obvious issue you run into when porting and the internet is filled with questions and answers about it. Hypothetically there may be extensions to correct these issues, though there weren't the last time I subjected myself to OpenGL.
  15. User subscription and protected passwords.

          There are some protocols to authenticate via a shared secret known to the server and client, allowing for secure login without TLS. Rough overview is that the client and server communicate some computed values from the password and they'll only match up if the password is known on both ends, but the computed secret itself tells you nothing. A nonce (one-time-value) is used to defeat replay attacks. Server takes secret and a random number, computes number, sends both to client. Client takes secret and provided number, computes same secret, verifies it, computes another number from inputs, sends that to server. Server verifies new number to authenticate the client.   There are two problems with this approach:   (a) you have to get the secret onto the server in the first place, which puts you right back to needing TLS. but if you only allow signup on a Web page or something, that might be easier for you. e.g., use TLS on the Web server for signup, then use raw data on subsequent game client connections.   (b) the secret aka password has to be shared, meaning known in full to both the server and client, so the server can't just store a hash of the secret. however, this is the exact case where having the client compute a (salted) hash to send to the server for storage works. hashing a password that's used as a secret into a more complex authentication protocol is just fine, so long as the original hash is cryptographically secure. Note that the initial signup still needs to be TLS protected because the hashed password is still a _secret_.   All that said, such approaches are silly wastes of time. If you have the Web site, just make a login endpoint that works with one-time session keys.   User opens client to login. Client sends username/password over TLS to a login HTTP service. Service authenticates the client and authorizes a new session, then generate the one-time session key, and sends that to the client. Client connects to game server and hands over the key. Game server sends the key to the session authentication service, which verifies that the key is valid and no more than ~30 seconds old or so, then marks the key as used, and returns the user's identity to the game server.   Note that this is what (good) games _do anyway_ even if they have TLS! You don't want to sling the user's password off to every server endpoint you have. Limit the password interaction to the client and login endpoint so you have fewer places where the password could be snooped (e.g., if someone hacks your maybe-easily-hacked native C game server and logs all incoming requests to a remote server, you don't want that to be usable to steal passwords). This is also incidentally the core idea behind authentication standards such as OAuth2. Number #2 rule of security - manage risks (have as few of them as possible)!   That _still_ leaves a problem, though: the client's established connection can be easily hijacked/snooped. If it's just a cooperative or unranked pvp game, no big (but then, why bother with logins in the first place?). If you have a ranked pvp game - or if you have any way of expending consumables or in-game currency via the game protocol - then this hijacking could spell trouble (I could cheat to hurt competitors, or make them drain their account's wallet of in-game gold, etc.).   What's the solution there?   You guessed it: use TLS/DTLS _for everything_. Every single packet. In and out of game. Encrypt all the things. :)   Games that need very high throughput or low-latency still work just fine with encryption today. Encrypt/decrypt network packets off the main game thread on the client side, and (if you are big enough to afford them) use a TLS endpoint on the server end (or at least just also keep the encryption work off the main server thread). The days of encryption being too expensive for real-time games is well behind us.