The core concept behind co.llide is for players to be able to build and then pilot their own customized, physically simulated spaceships. This means that when a player stitches together a bunch of pieces into a ship, the game needs to figure out how that ship should move depending on player input. Ours is certainly not the first game to ever address this problem, but we thought an explanation of our specific solution would make an interesting post. But why just tell when I can show?
Shadows are a great way to relay information in a 3D rendering. They can help demonstrate distances between two objects such as a bouncing ball and the ground. They also relay further information to the structure of an object as they give a second silhouette from the perspective of the light casting the shadow. In this article, I will demonstrate a very small but important improvement for THREEjs’s shadow rendering, a one line change to the shader code.
Douglas Crockford wrote RFC 4627, describing the specifications for JSON, a “text format for serialization of structured data.” As a language-agnostic, human-readable open format that has native support for encoding/decoding in browsers, JSON has become the de facto standard for data serialization on the web. There are drawbacks to using JSON, which became evident when we started to write a networked game using WebSockets. (Check out our pre-alpha teaser if you didn’t get a chance to see us at PAX!)
In developing a networked game, sometimes one needs to be able to test features running over specific network conditions. How does the game hold up under high latency and/or packet loss? What about in cases of varying network jitter, where the latency is ever-changing? Answering these questions is crucial to testing network code and making sure that it will perform well against whatever chaos the Internet might throw at you.