One of our goals for version 0.4.0 of co.llide was to provide a small but fairly balanced set of building blocks, called modules, for all players to use in constructing ships. However, variety is the spice of life, and we plan to eventually release a large number of unlockable modules for players to add to their personal collections. In this post, I’ll be discussing some ideas for these future modules. I’ll also be talking about a potential problem that we face as designers, and one particular source of inspiration that we believe offers the solution.
Today we say goodbye to Eric Li, who has been with Gradient for the past three years.
Eric’s abilities as a software engineer have made him a key member of the Gradient team. Using his expertise in graphics programming, Eric single-handedly built (and rebuilt) our graphics pipeline to meet the ever-changing needs of our projects. In experimenting with the look and feel of co.llide, we wanted to incorporate dynamic lighting effects. Eric took on the challenge of implementing these effects in Canvas2D, and found a way to make them work without sacrificing performance. He has also been involved in many other aspects of development, including networking, physics, and gameplay.
The team is grateful for Eric’s hard work and contributions. Though he will be sorely missed, we wish him luck, and share in the excitement at his future endeavors.
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?
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.