Category Archives: DEV BLOG

Hello people! Binarin here.

It seems Joxe is changing a lot in the network code (since we can’t play multiplayer right now). Joxe has also been sick for two days now. But I don’t wanna mess with his code so I’ve been working on the planets, as mentioned in my last post :3.

Joxe’s spot hasn’t been empty tho. Our sound guy, Johan, has been here. He’s making some sweet sounds for us. However, the sounds won’t be perfect until we get Unity Pro because Johan want to add low pass filters. Low pass filters will make the sounds sound good at a long distant, so you can hear it’s far away and not just decreased volume.

Speaking about Unity Pro, we need it for several features:

• Low pass filter, as I just said.
• Shader refractions. Crylar says he can make some really cool effects if he has those. Try search for “shader refractions” to see just how awesome it looks.
• IK animations. So the mechs can aim their weapon when firing, and rest their feets on the planets as they stand or run.
• Support for dll librarys. We need this to have weapons written in Lua so the players can make their own weapons :D. Right now we’re using a C# library that is very buggy, and many weapons are written directly in C# instead.
• Importing assets in run time. This is something we most probably need to let players make assets for their weapons.

We’re currently looking into buying it, Mowhammer is on the job!

Like I said, I’ve been working on the non-round planets and they seem to be working now. The shape is made out of an array of Vector2, which can be edited from the inspector or can be imported from a mesh which was much easier to make than I thought. These planets also have a array of floats that states how long each position has to the first position in distance along the edges. This makes it much easier to quickly find where the player lands when it collides with the planet.

Oh, and by the way. Can you see that the trails after the mech goes too low when it lands? That it looks very uneven? This is because Unity calls my OnTriggerEnter function one frame too late. If I look at it frame by frame I can see how it moves into the planet without getting a call and on the frame afterwards it is pushed up to stand on the surface. When I Google for it I find that this was a bug that was reported in February 2012. I guess they’re not planing to fix it for a while. Crylar has been complaining at me over this because it is more visible on these planets. If you have good eyes you can actually notice that something jerks as you land. Hmm, the work around to fix this might be tiresome…

Thanks for reading and stay hyped!
@CyberBinarin

Working with Unity has been a learning experience for the entire team, for every time I’ve been cursing it for something weird (like the LineRenderer) we’ve also been praising Unity for being awesome (the Particle System comes to mind). Personally this is the first time I’ve been working with a single game engine for this long and my prior knowledge is more towards the back-end side of things as I’ve mostly been working with XNA and SDL which aren’t game engines by their own right but libraries to create them.

Being more of a back-end programmer I wound up (voluntarily) with the goal to create the network part of Orbital Gear. Unity does have some great features with their NetworkView class, you can easily sync all the information inside a Transform, which takes care of the position, rotation and scale so it’s the same on all connected clients. The Transform syncing also has some settings on how to handle network lag and you can quite easily set up a game that has basic online play. So far so good, the NetworkView do have some design decisions, though, for Orbital Gear this has been how to set the member variables in all the clients while trying to take into account the possibility of massive lag and cheaters.

The obvious way to think is to use the NetworkView.OnSerializeNetworkView() that’s already in the NetworkView class, but it has some problems that we need to solve, namely that “It is automatically determined if the variables being serialized should be sent or received, see example below for a better description.” This fact present the problem that if the client decides what its member variables should be assigned to the possibility of cheating us only a step away for a programmer that knows his/her stuff as you can just change the value in the RAM via an external program or via DLL-injection and the other clients would just abide to that mindlessly. This has lead to our current solution which is to put most of the game logic on the server and update the clients accordingly, this resembles how popular games like League of Legends and Dota 2 does things, all your input is sent to the server, the server calculates and sends back the result.

1:  [RPC]  
2:  public void setHealth(float a_health) {  
3:    if (Network.isServer) {  
4:      networkView.RPC("setHealth", RPCMode.Others, a_health);  
5:    }  
6:    m_health = a_health;  
7:  }  

The game logic for setting health in Orbital Gear

 This code is designed to prevent setting health on a client and have it update on the other clients and the server, you can actually set the health on the client but no logic that reacts on your health is placed on the client so that would just bug out the health bar until the next time you get a health update from the server. The server will also have logic to prevent the remote procedure call from being called by the clients, in short, a lot of anti-cheat will be done server side in an attempt to ensure that games are being played in a fair way.

Unfortunately there is little hope to go entirely cheat-free in games, as long as they are run on a local machine there will be ways to cheat and modify it, part of the learning process will be to know how to handle cheaters.  Hopefully our approach will reduce the cheaters and the bandwidth need as this is not an evil scheme to impose some online-only DRM, joining a LAN server works just as fine as playing online and some single player game modes is in the plans, but that will wait until later 😉

– Joakim “Joxe” Clysén
Twitter: @Joxedin

Hello people! Binarin here.

This is the first development post from Night Node. They will be written by the programmers and they cover more technical things, like what we’re working with now and what problems we have.

While Joxe is making cool stuff in the backend, that I don’t dare touch, I can look at adding new things to the game. That is, as long as Crylar won’t bug me about adding his particles.

So I’m currently looking into how we can make our “planets” more unique. I’m using the functionality I added a while ago, that let’s planets override things like how the player moves and the normals of the surface. The aim is to have planets that can have any shape! Or at least planets that are not completely round, coz’ that would be boring. To try this out I’ve made a planet out of a cube.

After a bit of fiddling I got it to work. However, it looks silly as the player moves around a corner because there is no transition of any kind. I will probably make the player airborne as he walks over corners.

I’ve also tried making a planet that takes it’s shape out of it’s mesh. This turned out to be tricky, even if I managed to make a algorithm for making a 2D shape out of the mesh, I would have to save it somewhere. I could probably put the code in a custom unity editor to make sure it was only generated in edit mode, and store it in the planets serialization. But instead I think I’ll just take a array of Vector2s from the editor, that way we can customize the shape more freely without worrying about the mesh, and I don’t have to that 2D shape convertion… Like, where would I start? find the face to the left and follow it clockwise and save every edge? … No.

Joxe will probably write his own post from home some time this week. But he has done some nice work with Unity’s network library. We can almost play multiplayer without crashes again ~woohoo.

If you have any questions or just wanna talk, you can contact me on anton@nightnode.se. Have fun and keep hyping!

@CyberBinarin