It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of cheaters spoiling it for everyone is super slim. I wonder if it ever makes sense to think in those categories or am I just paranoid.
Why do you say "for the browser"? Unless you are working on a system with a ludicrous amount of effective DRM (which I hope we all hate for other reasons, and which means we are only really talking about consoles: the closest casual gaming platform you are going to get to "locked down system owned by the manufacturer" is an iPhone, and in practice they don't go quite far enough), players are always going to be able to modify your code: you can't prevent a user "cheating" (which I put in quotes, as I feel like you need to really question whether the environment you set up where that matters isn't somehow itself broken; maybe you are already doing that by "source-like networking", but I don't know the terminology context).
The only way to stop players from cheating in a multiplayer game is to make the server the authoritative source for any information you want to stop players from messing with.
Yeah, you need to have another (more invasive/fragile) solution for things that involve scripting input like auto-aim. Wallhacks can be prevented by not sending location data for units that players shouldn't be able to see though.
that does kinda feel like premature optimisation. First make a game. Second make a game that people want to play. Third make a game that people want to hack. Then maybe look at stopping them from doing that.
Knowing and designing around the unavoidable wave of cheaters is extremely important when building online games.
If you build a multiplayer game then come back to "deal with cheaters" only a few months before launch (or heaven forbid, after launch) you're probably going to end up taking the easy route by using invasion ~~spyware~~ DRM solutions, which don't stop cheaters once it's broken. To contrast, designing the game around cheaters means you might actually implement sane networking design, such as nearly everything being server-authoritative, aka. "never trust the client". If your client is broken in to, the best your cheaters can do is script the game (scripting cheats are currently the only ones available for Dota2 and probably League of Legends) or see a small amount of information that's otherwise unknown (for dota 2 you can see which enemy illusions are fake, for example).
Of course this approach can be taken too far, eg. in Call of Duty: Modern Warfare (the new one) sometimes your camera positioning can lag due to packet loss; this probably stops some aimbots but things like camera orientation probably shouldn't be handled server-side.
And, as with premature optimisation, mantras don't communicate any of the subtleties around the fact that many concerns can influence your code at the same time.
That's interesting - my girlfriend seems to very much fit the description. Would you say you have difficulty formulating full arguments in your head? Do you talk when you think by yourself? When "thinking" aloud by talking to someone you're bound to sometimes stray and perhaps need to take a different line of reasoning to make a coherent argument. Does it pose a challenge to not get attached (maybe defensive) to what you said for this process to be efficient? - especially before someone whose opinion matters to you; or in an argument.
I still use CoffeeScript for every game I make [1]. I know it's very passée but every time I rewrite something from javascript it turns out to be much shorter and more readable. It's true that there is now many improvements available compared to ES5 times but for me CoffeeScript still has a lot to offer. I admit, it's mostly ergonomics, but the cost of compilation is so minuscule that I find it worthwhile.
At least for the browser, current AR efforts all fail short of having low enough latency to allow the projections to "stick" to the marker area when the camera is moved. Another thing is the poor support for bigger, multi-marker areas.
I wanted to create a local multiplayer game with smartphones rendering stuff on the ground but the current technology just isn't there.
Very cool seeing PlayCanvas on HN! I've been using[1] their framework for a several years and I have to say it's the best out there. Only babylon.js comes close for 3d game engines for the browser but PlayCanvas has the Editor[2] which makes a world of a difference.
That's true but the editor for babylon.js is very simple. There's a big difference between the two. Apart from the much better UI the Editor for PlayCanvas is well featured with things like uploading and auto-conversion of 3D models and textures, cloud save, light mapping, sprite editor, comprehensive engine configuration, texture compression and much more.
I was just researching about babylon and playcanvas for a hobby project I've got in mind - any additional suggestions about why one should choose one instead of the other? For info, I'm a very experienced developer, but I've never really done 3D before.
Do you think it's been proven enough to be sure that plant based diet is better in terms of GHGE than meat based diet? There are also health concerns that come along with cutting meat entirely from ones diet. Would you say it's easy to hit all required protein's targets while eating only plant foods?
> Do you think it's been proven enough to be sure that plant based diet is better in terms of GHGE than meat based diet?
For me, yes.
> Would you say it's easy to hit all required protein's targets while eating only plant foods?
I find it relatively easy, although most days I also have a protein shake I take to top me up. It's not required but as a runner I prefer to have a little more protein than technically required.
This is actually quite straightforward after being referred as the vector method call (basically map) and the other stuff is just function/operator calls apart from maybe the :by{.chars} which I can assume what it's doing but only after seeing the implementation I can see that it's something like a named parameter with a lambda
Reading these articles by Damian I almost get jealous of how expressive Perl 6 is.
> This is actually quite straightforward after being referred as the vector method call (basically map) and the other stuff is just function/operator calls apart from maybe the :by{.chars} which I can assume what it's doing but only after seeing the implementation I can see that it's something like a named parameter with a lambda
This doesn't remotely explain what that line of code is doing.
Since no one mentioned it. Sonic Pi[0] is probably the easiest to learn and quite powerful[1]. You program in Ruby and both the IDE and the API are quite simple to start with.
It’s an easy to use and pretty wrapper around Supercollider. Which is neat because once you get deep you can graduate to more custom SC setups. I spent a lot of time with PureData. It sucks that it’s no longer maintained. Supercollider and Sonic Pi are very worthy successors.
Here’s one of my fave public PureData patches, even though it’s dated. Generative dubstep that builds towards a drop that is triggered when you hit the drop button.
Maybe you've been thinking about Pd extended - which is indeed unmaintained. There is a kind of successor called PurrData, but it's not 100% compatible with Pd Vanilla.
BTW, Pd 0.50 will probably be released in a couple of weeks (I'm a regular contributor)
