Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Mar 2000
Offline Last Active Yesterday, 08:12 AM

#5301945 Should I Learn How To Use Wwise Fmod Etc?

Posted by Kylotan on Yesterday, 07:20 AM

The demand for composers is tiny relative to the supply. So if that's all you can offer, you need to be really good. The more you can bring to the table - whether that means being able to deliver music in different ways (eg. layers/dynamic/etc), being able to do additional audio work (sfx/foley/voiceover/trailers and promo/etc), or being able to help implement the audio directly (Wwise, FMOD, Unity, etc) - the more likely you are to get hired.

#5301746 Trusting The Client

Posted by Kylotan on 21 July 2016 - 07:40 AM

I've clicked the Quote button many times but this forum software is steadfastly refusing to do it, so here's to manual quoting...

Does it need to do something? It's perfectly acceptable if it shows "kaboom" when the next tick's server reply comes in (OP says 20 updates per second, so that's not long), is it not? Player will still be standing on the trap then.

Okay, I guess I misunderstood the initial point. I guess what I'm asking is, how would this differ from the standard method of:
(a) move the player locally (or perform other action)
(b) report to server
© server checks if new location (or action, state, whatever) is reasonable
(d) server requests correction if new location is slightly bad, or does something more punitive if it's excessively bad

I can see how the bloom filter can save a round trip in certain ways, but if the server requires that the client checks in with the server sufficiently often, this starts to depend a lot on the nature of the feature being checked, and probably is no better than just doing a server-side check anyway. But maybe I'm missing some nuance here?

#5301730 Trusting The Client

Posted by Kylotan on 21 July 2016 - 06:04 AM

The Bloom filter idea sounds great, but I'm unsure of how you'd implement it in practice. If you're treating it as a bunch of false positive collisions, what's the client supposed to do in the time while it waits for the server to report that it's not a real collision?

#5301714 Trusting The Client

Posted by Kylotan on 21 July 2016 - 04:16 AM

It's certainly possible to get a send-commands-only game working, because in theory it should be no different and any updates in between are redundant. In practice, having regular updates in between slices up your potential timing errors into smaller chunks so that there are fewer surprises, which in turn let you make stronger assumptions about position (and thereby your ability to verify it). The MMOs I've worked on, and some (most?) FPS games, worked this way.


Some game types, eg. many RTSes, require that all clients are synchronized, and this usually requires waiting for a positive response before moving. I think that is what HPlus was referring to (in another thread?) But it's not a universal solution to all games. Most action games allow the client to start moving locally, and send corrections later if necessary.


You say that the game gets unsynced by following this approach, but actually, all games are always unsynced. All you can do is attempt to minimize the amount, and the effect, of the desynchronisation. You can never get around the fact that some packet might take longer to reach one player than it did to reach another, and that's nothing to do with waiting for confirmations or not. In fact, the wait-for-confirmation method usually is the least likely to get out of sync because the server tries to notify everybody of a change at the same time. The approach where you start moving locally is more prone to problems because if the server has a 50ms hiccup then the other players get a 50ms extra delay between that player moving locally on their own machine and that player being seen to move on the other player machines. This is the tradeoff you make for responsiveness.


Whether you need 20 messages per second (don't call them packets, especially if you're using TCP, because the protocol decides what goes in a packet, not you) is down to your game type, bandwidth, etc. It also depends somewhat on how quickly players can change direction and velocity, and on how accurately you're able to extrapolate it on the server for the benefit of other players. For the type of games I write, i.e. not shooters, I would probably try 10Hz, or 5Hz.

#5301705 Trusting The Client

Posted by Kylotan on 21 July 2016 - 02:51 AM

What I'm trying to get at, is.. I am relying on the client for a lot of things. Say for example, since physics are not on the server, if a player shoots a fireball and when it reaches a target. this packet is sent to the server. I then check if that player is in range of that monster, and if the skill is NOT on cooldown, it goes through.  This would be enough to prevent speed hackers that attack at 1000 times a second, but not enough for pixel perfect collision (physics) on the server.

You don't need to run a full physics simulation to be able to perform a good enough approximation. If an object moves very quickly (eg. bullet speed), you can simulate it like a ray at the moment of firing. If an object moves less quickly (eg. a fireball) then you should probably simulate on the server to check position - but that's no harder than tracking where the players are.

What I am worried about is the 20 PPS the client is sending to the server (when they are moving). Is this even something that other games do? I mean, I know you're supposed to just send the "Player is moving right key" instead of having a TCP stream of data being send from the client..

I don't know where you heard that (and I hear it a lot on these forums lately), but I think it's wrong. Sending keypresses only is a sure way to get yourself into synchronization problems. Game networking has traditionally been using the "rapid position updates" method, and although it seems wasteful of bandwidth it helps ensure everybody is relatively up to date at all times. The majority of networking problems I see on these forums ultimately come down to the problem that the time between a user pressing and releasing a key does not equal the time between the server receiving the keydown message and the server receiving the keyup message. Send positions instead of change events and that problem stops existing.

Collision is done for you, no physics loop on the server, lag compensation is so easy to deal with, fixed timestep isn't needed (although, that's because my clientside game framework (Phaser) is weird...But, this all comes with the cost of the extra bandwidth and processing power for those extra messages.

The point of frequent updates is not to remove the need for performing collision or physics on the server, but to allow the client to have the first go at it in order to improve responsiveness, and to reduce the errors caused by accumulated network jitter, etc.

And that is why I am scared if nodejs is appropriate for this type of design.

Does Node allow you to have a simulation loop? If not, then it's not suitable. If it does, then it is.

So, I'm looking what are your thoughts on my train of thought here. Am I too paranoid?

No. As others pointed out, even tiny games will draw cheaters, and it only takes 1 cheater to upset all the other players.

#5301495 Copying An Existing Idea

Posted by Kylotan on 20 July 2016 - 04:17 AM

the law doesn't map my moral/ethics at all - and I hope that's true for you too

If the law doesn't map to your ethics at all, you might ask yourself 2 questions:
1) Why does society think so differently to me?
2) Am I misunderstanding why the laws are this way?

For example, the reason the law does not protect ideas from copying is not because they don't value creativity, but because having an idea is such a nebulous concept that protecting them would basically mean everybody who made something would be continually getting sued by someone else who claimed to have thought of it first, or who did something vaguely similar once.

#5301333 Overall Strategy For Move-Semantics? [C++11]

Posted by Kylotan on 19 July 2016 - 04:33 AM

Here is the thing: C++11 is not the new kid on the block. It's half a decade old. If it were an actual kid it would be getting bored with kindergarten and preparing to move on the more interesting pastures. It's even older when you consider how long some of these core concepts have been there in the C++0x-era when everyone still believed in the '0' of 0x.

If you show so extremely little interest in your most basic of tools at your disposal that standard idioms like that elude after half a decade, then you really should not call yourself a C++ programmer. Or if you do, at least make sure someone who went to the trouble of actually investing skill points is close by.



I'm not going to debate this with you on every thread, but C++ has always had far more features than a typical competent programmer is going to know or be comfortable with, and this is doubly true of features introduced with recent compilers. Half a decade is new by large software project standards. It's one-and-a-half, maybe two shipped games, probably made with the same libraries that someone wrote for the company even further back. Nobody's going to be taking the time to go through that code and replace all their in-house ProprietaryPtr with std::unique_ptr because they're busy implementing features and because ProprietaryPtr already does the job. And even if they did, they'd also have to spend the time to educate the other members of their team, whose jobs are not to continually study C++ but to use what they already know to make games.


The company I was at up to 2010 did not use C++0x features. The company I contracted for back in 2013/2014 did not use C++11 (although we did, in our code). The company I work for now, again, doesn't use C++11 (but hey, we're replacing NULL with nullptr when we come across it). This is not new or strange. Go back 10 years and lots of gamedevs were still avoiding the standard library. Go back 15 years and plenty still viewed C++ with suspicion when C worked perfectly fine. Keeping on top of compiler changes and new language features is low priority relative to (a) successfully shipping games using tech that is already well understood, and (b) keeping up with new tech that can't be safely ignored, such as rendering tech, new input hardware, new consoles, etc. Discussions of new language features have to be made in that context.

#5301331 Python/pygame Code Review - Where To Next ?

Posted by Kylotan on 19 July 2016 - 04:06 AM

a) Add more comments. You should have comments explaining what every section of code does, as well as your existing comments about certain lines of code. Docstrings for functions are a good idea too.


b) Don't use comments to explain magic numbers - replace the numbers with named constants. eg. ObjType_Enemy = 11, ObjType_Shell = 12. This is especially essential if you don't want to use classes and just want to use parts of a list. I'm not going to spend time working out what item 7 or item 11 of an object are.


c) Importing '*' from anywhere is usually a bad idea. It makes it hard to see what is a global you've defined and what has been pulled in from some other module.


d) Put your main logic into a function, instead of having it at module level. This stops you from getting a ton of unnecessary global variables.


e) Don't create the screen object fresh every frame. (Any reason you can't just draw to the main surface?)


f) Don't do "for i in range(len(whatever))". This is a bad habit that people pick up when they try to make Python act like C++ or Basic, because they are used to having a loop index, but then they typically convert that right back to the object they would have got from a normal iteration. In this case, "for i in range(len(wave)-1,-1,-1)" is followed by a ton of "wave[i]" references - so why not just have "for current_wave in reversed(wave)"? By making this change to your two loops, you can get rid of most of that ugly array indexing.


g) Don't have if-state​ments and loops 9 levels deep. Factor some of that out into functions


h) Why reverse and sor​t a list of keys if all you're doing is deleting each one from the wave list? They're all getting deleted, so the order doesn't matter.

#5301218 Overall Strategy For Move-Semantics? [C++11]

Posted by Kylotan on 18 July 2016 - 09:39 AM

Assume you have a member function like this:

void MyClass::SetText(std::string text)
     this->text = std::move(text);
The requirement is, the class needs its own variable that it can modify without affecting external variables (i.e. a reference/pointer/handle to an externally owned variable is for some reason unacceptable in this circumstance - we'll assume the class' requirements have actually been designed well).
Since a copy is going to be made anyway, caller behavior is thus:
99.9% of the time, the caller doesn't need to think.


I think I'd expect it to go more like this:

  • They want to call MyClass::SetText
  • They see that the interface takes a copy instead of a const reference
  • They then have to dig into the implementation to see whether this is going to create unnecessary copies or not, because they're used to passing const references to functions like this
  • If they find the implementation then they realise it's not a problem.
  • If the implementation is hidden then they have to ask around and find out more, or just hope it's not an issue.

Whereas with option 2, the process is:

  • ​They want to call MyClass::SetText
  • They see the interface has an overload with && in it
  • They either:
    • a) recognize that it's an r-value reference that will do the right thing, so they're happy
    • b) wonder what the hell this double ampersand business is about, read up on it, and then they're happy

This is from my experience where gamedev teams typically contain a majority of both legacy code and (legacy) coders that predate C++11 and do not use typically it, but do use older idioms designed to improve performance (eg. never passing complex objects by value).


For my own personal stuff this seems like a situation that doesn't arise often - I rarely create temporaries that then get copied into something else. Again this is probably just an old habit where, in a world where all we had was auto_ptr and we were told to avoid it anyway, we were very careful about what created an object, how they got passed on, and about not copying them unnecessarily.

#5301198 Copying An Existing Idea

Posted by Kylotan on 18 July 2016 - 07:10 AM

Cloning an idea happens regularly. How ethical it is depends on a lot of things - your own personal idea of what is ethical, how unique the idea is, how significant those 'tweaks' were, whether the clone is likely to harm or inconvenience the person that originated the idea, etc.

#5300878 Overall Strategy For Move-Semantics? [C++11]

Posted by Kylotan on 15 July 2016 - 05:42 AM

Option 4 looks a bit messy since it implies the caller has to think about this problem. I'd probably prefer to use option 2, migrating there from option 1 as and when profiles are showing the copies to be expensive. But it depends a lot on whether you're writing new code or maintaining old code, and whether you can assume everyone using the code will understand all the performance implications.

#5300743 Newbie Question About Std:vector

Posted by Kylotan on 14 July 2016 - 10:07 AM

If you have a reasonably modern compiler (that is, not half a decade old or more) then you do not need full copy semantics (these can be fairly difficult to get right because they mess with strong ownership semantics).

Can you explain your thinking here? I'm guessing that you're referring to modern compilers using move semantics within vector resize operations instead of copying, but I thought the move constructor would require that the copied object gets its pointers nulled-out (to avoid the subsequent destructor call freeing the relinquished memory), and the default move constructor wouldn't do that, right?

(Do point out if I'm missing something - I'm not too familiar with C++11.)

#5300730 Copyright

Posted by Kylotan on 14 July 2016 - 09:15 AM

The short version of trademark law is: don't use any names or titles or logos or distinctive marks of anything that is already used, unless it's a generic term or you're using it in a completely different industry.

#5300546 Copyright

Posted by Kylotan on 13 July 2016 - 08:58 AM

You are likely to have a lot of problems with trademark law, even if you avoid copyright problems by changing all the text, images, etc. You might not care about that, but it's just as much of a legal problem and just as likely to get you a cease and desist letter. And Games Workshop send out a lot of those.

#5300531 Copyright

Posted by Kylotan on 13 July 2016 - 07:56 AM

To make this movie in the setting you are talking about you'd need to secure the rights from Games Workshop. Unless you have several million dollars and relevant movie-making contacts then this is basically not going to happen, sorry.