Postie

Two months invested in something which is possibly going to be discontinued at some point in the future is hardly something to be concerned about. From two perspectives:

1) Two months in the grand scheme of things isn't very much time. After two months of intense study you're still barely scratching the surface.
2) In computer science every new thing is built on something old. Language syntax and API's may become obsolete, but the core concepts of programming and the skills associated with them don't. API knowledge isn't the mark of a good programmer, anyone can use google.

A related anecdote: 15 years ago the only programming languages I knew were C and QuickBASIC. I started a new job using visual basic. After 3 years I moved to a new job where the language of choice was Delphi. And then more recently I took up C#. I don't consider anything I learnt in any of the previous languages a wasted effort, even though arguably C, BASIC, Visual Basic and Delphi are "dead" - in terms of new project uptake. I'm a far better (and more adaptable) programmer now for having taken the journey through all those languages than if I've stuck with just one thing for 15 years.

Basically, each client just generates the area of the world immediately surrounding that player, while the server has to generate the area(s) surrounding each/all players.

...Also ensuring that the map generation process is deterministic.

Another option is to generate smaller maps and then stitch them together in some fashion. If your stitching is decent enough you can effectively generate an infinite world. Games like Minecraft break the world into chunks, which are streamed to and from the disk as required. If your terrain generator is creating these chunks for you at the start it makes their dynamic loading much easier.

A simple polygon you can make from a collection of points is a convex hull. The advantage of this is there is a unique solution for the set of input points, but it discards any points that are internal to the polygon. There are quite a few different algorithms for calculating a convex hull (of varying complexity and performance), so have a quick google and find an algorithm that is up to your level of expertise.



If you need to include all vertices, the polygon is going to be a concave hull, and you start to run into problems. Unless you know there are definite constraints on the way the vertices link up, like say a maximum distance or angle between vertices, you quickly discover there are many solutions for even a small number of vertices, doubly so if you allow self-intersection.

You need to use a technique called ray casting. From the position of the player's eye (centre of the viewport) and your camera's direction vector you create a ray and then test that against your geometry to determine where it intersects.

The difference between torrents and multiplayer games is that in the case of a torrent, the data doesn't change, so the seed data can be passed around as quick or slow as it likes. A multi-player game by definition is being affected by its players, so the game state is constantly changing. There's just no simple way for that game state to be passed around in a peer to peer fashion that is either timely or accurate.

Minecraft was inspired by another project called Infiniminer which was abandoned by it's creator about a month after release due to losing control of his own source code.

Quoted from RockPaperShotgun:
“I stopped working on Infiniminer when the source code was leaked. It was totally my fault, as that’s what I get for releasing an un-obfuscated .NET assembly, but it nevertheless enabled hackers to create hacked clients and players upset with my balancing decisions to fork and write their own clients and servers.”

So it's worth doing some really basic obfuscation and making sure you don't release debug builds. Also, listening to your community and getting them involved will eliminate the need for them to build their own stuff based off your work.

Essentially what you're asking is: How do you make a game act as though it doesn't use a physics engine.

Easy. Don't use a physics engine. Adjust the velocity/position of the objects directly, don't factor in acceleration or mass or friction or any of the other physics related parameters.

I realize that, but I really don't want to start handling collisions, so I am wondering if you can force Box2D to be less "physicy"

Fair enough, though it may be easier to write a simple sprite-based 2d collision detection system than trying to wrangle Box2D to work less like a proper physics engine.

First things first. Does it work? If not, get it working. Then think about refactoring.

A good metric for determining if refactoring is required is if the code makes sense to you at a glance a few weeks or months later. You can often overlook obvious design flaws when the code is fresh in your mind.

IMHO, it's better to code an imperfect solution and then improve it later (if you have time) than spending hours agonising over producing the perfect design first time. I know this because I'm guilty of it all the time.

Pressure can be seen as the sum total of all the particles colliding with the container's walls over a period of time. If you're looking to go the realistic route you could give all your particles an initial kinetic energy based on the temperature of the fluid you're simulating, and if you use elastic collisions you should find that as you decrease the volume there are more particle collisions per second.

If the speed of your bullet is very high compared to the movement of everything else in your world (for example a laser beam), you're better off using the vector approach, or more correctly, a Ray. A Ray has an origin and a direction, whereas a vector just has direction.

If the speed of your bullet is low enough that its reasonable that the player will be able to see it coming and dodge it, then you'll have to use collision detection. There are ways of preventing situations where collision detection misses a collision due to the speed of the projectile, you can simply test against an object that is extruded forwards in time by a certain amount, or use shorter timesteps to get a higher resolution.

The dds format can be uploaded in a compressed state and decompressed by the graphics hardware, whereas .png will need to be decompressed at the cpu/graphics driver end and uploaded as raw bitmap data, which consumes more bandwidth.

That said, I'm currently using .png, as it is easier to manipulate during development. When I'm closer to release I'll convert them all to .dds and see if it makes a difference to performance at all.

If the angle between adjacent faces is more than a certain threshold, you really need to switch to using face normals. If you want a hard edge, use face normals. If you want a smooth edge, use averaged vertex normals.

Also, don't forget to re-normalise the normals after summing them together.

Batching the updates together will make a definite improvement. Try something like 100 or 1000 and see how you go. Another thing to look at is how you're building the query string you're executing. If you're concatenating a lot of strings together it will severely impact your performance, as .net has to reallocate the string every time you modify it. The recommended way to build strings is with the StringBuilder class.

My favourite anti-piracy reaction of all time was from last year by Garry Newman of Garry's Mod fame. He pushed out an update via steam that detected if the game was hacked and threw up an error message when you'd try to run it. The error message included a long error code that was actually the user's steam ID. So when the pirates complained in support forums and posted the error code Garry knew exactly which forum and steam accounts to ban.

Using such a scheme is risky due to the chance of false positives. But it was terribly amusing to read about.

In my personal opinion, there's nothing you can do to make your game completely secure. DRM is good in theory, but when it goes wrong (and they ALWAYS seem to go wrong), you risk pissing off your legitimate customers while the pirates have already found a way around it so they aren't inconvenienced.