How to make a multi-player game – part 2

Hello and welcome back to my blog! This is part 2 in the series where I talk about making a multi-player game.
Last time we built a TCP socket server in node.js and we’re able to send and receive complex types. Read the first article if you’ve not already done so here.
Here is a live version of the game I’m describing in this series:

Clock synchronisation

It’s important that both the client and server’s clocks are synchronised because if there is any time based interpolation, you want both server and client to agree on what time it is and therefore at what position your interpolated object is.

Asteroids on an interpolation orbit

I use this technique in 2D Space MMO to ensure the orbiting asteroids are in the same position across all clients and on the server. The asteroids are actually interpolating on an orbit around a central location – there are no update messages getting sent to correct their positions, the only thing which keeps them synchronised is having the same time value across all clients and server.
Before we can try to synchronise clocks, we need to be sure we’re using the same concept of time on both server and client. We want to calculate the number of seconds since 1970/01/01, which is the same in both javascript and actionscript:
Read more: How to make a multi-player game – part 2

Quick Tip: The OOP Principle of Abstraction

This entry is part 5 of 5 in the series Beginner's Guide to OOP
We’re almost done with this series on object-oriented programming, and in this article we’ll discuss the OOP principle of abstraction – that is, generalising an object – and its use in game development.
Note: Although this tutorial is written using Java, you should be able to use the same techniques and concepts in almost any game development environment.

---

What is Abstraction?

Abstraction is the principle of generalization. This requires that we move from a specific instance to a more generalized concept by thinking about the most basic information and function of an object.
This may sound a bit strange, but we are already familiar with the concept of abstraction. For example, if I say the word “car”, what do you think of? Odds are we weren’t thinking about the same car. I was thinking about a black Mustang Boss 302, which is a specific instance of a car. Neither of us were wrong because the word car is a very general concept of a vehicle that we use for transportation (or recreation in my case).
The same goes for video games. Video games are categorized into groups such as RTS, RPG, Racing, etc.. These groups are all generalized concepts that describe the gameplay of a game. StarCraft II, Elder Scrolls V: Skyrim, and Need for Speed are all specific instances of these generalized concepts.
Thus, abstraction takes many specific instances of objects and extracts their common information and functions to create a single generalized concept that can be used to describe all the specific instances as one.

---

Why is it Helpful?

Abstraction is helpful because it strips everything down to its most basic principles. This can help when encapsulating functionality of an object because it can help identify the important information that should be made visible and the unimportant information which can be made hidden.
Abstraction also helps with the Don’t Repeat Yourself principle. By taking what a group of objects have in common and abstracting it, we can help prevent redundant code in each object which in turn creates more maintainable code.

---

How to Apply This Principle

As before, let’s use our three games to see some concrete examples of this principle in action.

Asteroids

[...]
Read more: Quick Tip: The OOP Principle of Abstraction

Quick Tip: The OOP Principle of Encapsulation

This entry is part 4 of 4 in the series Beginner's Guide to OOP
We’ve discussed object-oriented programming for game developers in general and the specific OOP principles of cohesion and coupling. Now let’s take a look at encapsulation and how it helps to keep code loosely coupled and more maintainable. Note: Although this Quick Tip is explained using Java, you should be able to use the same techniques and concepts in almost any game development environment.

---

What Is Encapsulation?

Encapsulation is the principle of information hiding. That is, the implementation (the internal workings) of an object is hidden from the rest of the program. A popular example you’ll hear for encapsulation is driving a car. Do you need to know exactly how every aspect of a car works (engine, carburettor, alternator, and so on)? No – you need to know how to use the steering wheel, brakes, accelerator, and so on. Another example is searching for a value in an array. In Java, you can do the following:

int myArray[] = {1, 2, 3, 5, 7, 9, 11, 13};
Arrays.asList(myArray).contains(11);

The above code will return true if the value 11 is in myArray, otherwise it will return false. How does the contains() method work? Which searching technique does it use? Does it pre-sort the array before searching? The answer is it doesn’t matter because the exact implementation of the method is hidden.

---

Why Is Encapsulation Helpful?

Encapsulation helps to create code that is loosely coupled. Because the details are hidden, it reduces the ability of other objects to directly modify an object’s state and behavior. It also greatly helps when you must change the data type of a variable. Lets say you decided to use a String to keep track of time in “hh:mm:ss” format. After awhile, you come to realize that an int representing seconds might be a better data type for time. Not only must you change the data type in the object, but also every time you referenced the object’s time in the entire program! Instead, you can use what are known as getter and setter functions. Getters and setters are usually small functions that return and set a variable respectively. A getter function to get the time would look as follows:

public String getTime() {
  return time;
}

The getter will return a String value: the variable time. Now when we want to change time to an int, instead of changing all calls to the getter we can just change the getter function to change the int data type into a String data type.
Read more: Quick Tip: The OOP Principle of Encapsulation

Quick Tip: The OOP Principle of Coupling

This entry is part 3 of 3 in the series Beginner's Guide to OOP So far in this series, we’ve discussed object-oriented programming in general, and the OOP principle of cohesion. In this article, we’ll look at the principle of coupling and how it helps in game development. Note: Although this tutorial is written using Java, you should be able to use the same techniques and concepts in almost any game development environment.

---

What Is Coupling?

Coupling is the principle of “separation of concerns”. This means that one object doesn’t directly change or modify the state or behavior of another object. Coupling looks at the relationship between objects and how closely connected they are. A Relations Diagram is a great way to visualise the connections between objects. In such a diagram, boxes represent objects and arrows represent a connection between two objects where one object can directly affect another object.

A relations diagram

A good example of coupling is HTML and CSS. Before CSS, HTML was used for both markup and presentation. This created bloated code that was hard to change and difficult to maintain. With the advent of CSS, HTML became used just for markup, and CSS took over for presentation. This made the code fairly clean and easily changeable. The concerns of presentation and markup were separated.

---

Why Is Coupling Helpful?

Objects that are independent from one another and do not directly modify the state of other objects are said to be loosely coupled. Loose coupling lets the code be more flexible, more changeable, and easier to work with.

A loosely coupled system

Objects that rely on other objects and can modify the states of other objects are said to be tightly coupled. Tight coupling creates situations where modifying the code of one object also requires changing the code of other objects (also known as a ripple effect). Tightly coupled code is also harder to reuse because it can’t be separated.

A tightly coupled system

A common phrase you’ll hear is “strive for low coupling and high cohesion“. This phrase is a helpful reminder that we should strive for code that separates tasks and doesn’t rely heavily on each other. Thus, low (or loose) coupling is generally good, while high (or tight) coupling is generally bad.

---

How to Apply It

Asteroids

First, lets look at the objects of Asteroids and how they are connected. Recall that the objects are a ship, an asteroid, a flying saucer, and a bullet. How are these objects related or connected to each other? In Asteroids, a ship can fire a bullet, a bullet can hit an asteroid and a flying saucer, and an asteroid and a flying saucer can hit the ship. Our relations diagram then looks as follows:

As you can see the objects are all pretty well interrelated. Because of this, we have to be careful of how we write the code, otherwise we will end up with a tightly coupled system. Lets take for example the ship firing a bullet. If the ship were to create a bullet object, keep track of its position, and then modify the asteroid when the bullet hits, our system would be very tightly coupled. Instead, the ship should create a bullet object, but not worry about it after that point. Another class would be responsible for keeping track of the bullet’s position as well as what happens when a bullet hits an asteroid. With an intermediary class in between our relationships, the diagram would look as follows:
Read more: Quick Tip: The OOP Principle of Coupling

Quick Tip: The OOP Principle of Cohesion

This entry is part 2 of 2 in the series Beginner's Guide to OOP
In the first post of this series, we discussed why object-oriented programming (OOP) was helpful for game development, and learned how to identify objects, their states, and their behaviors. In this article, we’ll look at the specific OOP principle of cohesion and how it applies to games.
Note: Although this tutorial is written using Java, you should be able to use the same techniques and concepts in almost any game development environment.

---

What Is Cohesion?

Cohesion is the principle of being or doing one thing well. In other words, cohesion means grouping together code that contributes to a single task.
A great non-programming example of this principle was covered in one of the first Gamedevtuts+ articles which talked about the Covert Action Rule:

Don’t try to do too many games in one package … Individually, those each could have been good games. Together, they fought with each other.

The same rule applies to object-oriented programming. Each object should only have one responsibility. Every behavior of that object should only do one task. Any more than that and you’ll have a much harder time making changes to the code.

---

Why Is It Helpful?

Code that is organized by functionality and does only one task is said to have high cohesion. Highly cohesive code is reusable, simple, and easy to understand. It also creates objects that are small and focused [...]
Read more: Quick Tip: The OOP Principle of Cohesion

10 steps to becoming a better programmer

Hi and welcome back to my blog!
I wanted to cover 10 of the things I’ve learned over the years being a professional programmer that really helped me improve the quality of my code and my overall productivity.

1. Never ever duplicate code

Avoid duplicating code at all costs. If you have a common code segment used in a few different places, refactor it out into its own function. Code duplication causes confusion among your colleagues reading your code, it causes bugs down the line when the duplicated segment is fixed in one location and not the others and it bloats the size of your code-base and executable. With modern languages its become possible to get really good at this, for example here is a pattern that used to be hard to solve before delegates and lambdas came along:

/// <summary>
/// Some function with partially duplicated code
/// </summary>
void OriginalA()
{
 DoThingsA();
 
 // unique code
 
 DoThingsB();
}
 
/// <summary>
/// Another function with partially duplicated code
/// </summary>
void OriginalB()
{
 DoThingsA();
 
 // unique code
 
 DoThingsB();
}

But now we can refactor the shared part of both functions and rewrite using a delegate:

/// <summary>
/// Encapsulate shared functionality
/// </summary>
/// <param name="action">User defined action</param>
void UniqueWrapper(Action action)
{
 DoThingsA();
 
 action();
 
 DoThingsB();
}
 
/// <summary>
/// New implmentation of A
/// </summary>
void NewA()
{
 UniqueWrapper(() =>
 {
  // unique code
 });
}
 
/// <summary>
/// New implementation of B
/// </summary>
void NewB()
{
 UniqueWrapper(() =>
 {
  // unique code
 });
}

2. Notice when you start distracting yourself

When you find yourself flicking to facebook or twitter instead of working on a problem its often a sign that you need to take a short break. Go grab a coffee away from your desk and talk to your colleagues for 5 minutes or so. Even though this seems counter intuitive, you will be more productive in the long run.

3. Don’t rush the solution out the door

When under pressure to produce a solution to a problem, or to fix a bug, its very easy to get carried away and find yourself rushing, or even missing out your usual crucial testing cycle completely. This can often result in more problems and will make you look less professional in the eyes of your boss and colleagues.

4. Test your finished code

You know what your code is supposed to do, and you’ve likely tested that it works, but you really need to prove it. Analyse all the potential edge cases and make a test which confirms that your code performs as expected under all possible conditions. If there are parameters, send values outside of the expected range. Send null values. If you can, show your code to a colleague and ask them to break it. Unit testing is a formalised approach to this.

5. Code review

[...]
Read more: 10 steps to becoming a better programmer

Quick Tip: Intro to Object-Oriented Programming for Game Development

This entry is part 1 of 1 in the series Beginner's Guide to OOP
Welcome to a new series of Quick Tips on Object-Oriented Programming! We’ll be going over the principles of OOP and how they can be used to create organized code. In this first part, we’ll talk about what OOP is and why it’s helpful, with a few examples of how it could be used in game development.

---

What Is Object-Oriented Programming?

Object-oriented programming (OOP), in its most basic sense, is a programming style used to organize code. Video games can run anywhere from a few thousand lines of code (Cut the Rope has 15,000) to millions of lines of code long (Crysis has over a million). You can see why it’s so important to write code that can be easily modified and maintained.
Programming styles, such as OOP, help to organize code in such a way that it becomes easier to maintain and modify. OOP helps organize code by organizing it into what are known as objects.
Objects hold information about state and behavior:
States are the characteristics of the object, or the words you would use to describe it, and usually take the form of is or has descriptors. A computer is either on or off, a chair has four legs, and you have a name.
Behaviors are the things the object can do, or the actions the object can perform, and are usually verbs that end in ing. You are sitting, using a computer, and reading this article.

---

Why Is It Helpful?

As stated earlier, OOP is helpful because it helps create maintainable code – code that is understandable, adaptable, and extendable.
It also helps create reusable code by following the DRY (Don’t Repeat Yourself) method: write the code once and then reuse it, rather than copying and pasting.
The OOP way of thinking also lends itself well to directly translating real-world objects and interactions into code.

---

How to Apply It

I’ll list three different examples of how to apply OOP to video games. In later articles, we’ll look at how to code these examples, but for now we’ll just stick to learning to identify objects and their states and behaviors.

Asteroids

First, let’s imagine that we wanted to make the classic game Asteroids. To identify what the objects are in Asteroids, try describing it.
Wikipedia describes Asteroids as follows:

The objective of Asteroids is to score as many points as possible by destroying asteroids and flying saucers. The player controls a triangular-shaped ship that can rotate left and right, fire shots straight forward, and thrust forward. As the ship moves, momentum is not conserved – the ship eventually comes to a stop again when not thrusting.

Think about what in this description could stand alone, or the things that are described that could have state and behavior. These become our objects.
The objects for Asteroids are: a ship, an asteroid, a flying saucer, and a bullet (can’t forget those!). The cool thing about objects is that we normally describe things in terms of objects in everyday talk, so they usually reveal themselves through a description.

The classic game of Asteroids

Now that we have identified our objects, let’s define the state and behavior for one of them: the player’s ship. Think about what attributes describe the ship; these are its states. Then think about what the ship can do; these are its behaviors.
A ship has states of:[...]
Read more: Quick Tip: Intro to Object-Oriented Programming for Game Development