Sign in to follow this  
  • entries
  • comments
  • views

About this blog

Experiences with game development

Entries in this blog


Hi! It has been a while. Here's an update on my networking library EvayrNet which is available for C++ users of Leadwerks:


While implementing it into the test project in Leadwerks, I saw that the use case had some flaws which made it really hard to debug what's going on. I figured that I should be spending some time on fixing some flaws. After a few weeks I came up with the following upgrades:

  1. Debugging class
  2. Simulation mode
  3. More debugging information available

Here's some detailed explanation:


Debugging class

I was using a lot of "printf" before which made it hard to:

  • Find out where it's being called
  • Disable whenever I don't need it anymore

This is when I decided to make a debugging class. I replaced the printf with a custom Print function which allows you to do the same as before - except you can disable any kind of printing whenever you want (like during release builds).


I also realized that capturing data is a pretty cool feature to have, which makes it easier to visualize the data you want to debug. For that I created a SaveText function which accepts a string and a filename as arguments so you can separate data like "Pings per interval", "Bytes sent per second", etc.


Here is an example what you can do with it:



Simulation mode

This is an interesting one that I just had to implement. A connection cannot always perfect, and it can be hard to always expect a good outcome (while you might not notice it because of your tests on localhost). This is why I introduced the manipulation of the following networking stats:

  1. Minimum latency (in ms)
  2. Random latency (in ms)
  3. Packet drop percentage
  4. Packet duplication percentage

It's also very easy to activate and deactivate. All you have to do is NetworkManager::StartSimulation(...) and StopSimulation(). Here is it in the command line when you activate it:



More debugging information available

At last I added more ways to debug the network statistics to really see what is going on. Are you not receiving data anymore? Are you flooding the network? The following information is now ready to be displayed:

  • Newest ping (either to the server or from a specific client)
  • Average ping (this as well^)
  • Incoming amount of packets per second
  • Outgoing amount of packets per second
  • Packets per second lost
  • Incoming data per second (in bytes)
  • Outgoing data per second (in bytes)
  • Current active connections (primarily for the server)

That's... quite a lot more than before! Previously you could only see if you're connected and if you're the server. I hope this information will make it easier for users to visualize traffic and debug any problems they might be having. And of course, you can mix this up with the debugging class to make cool graphs like above!


Final words

I'm still planning on making some extra information, like on specifics to see what kind of message is creating the amount of bytes send/received. This should help debugging even more. Other than that there are still some enhancements I'd like to put in such as encryption. These can be seen here.


I hope you liked this blog post! Next time I will probably be showing how to implement EvayrNet into your C++ Leadwerks project, so you can toy around with it. wink.png





An interesting new project of mine. I've always wanted to become a network programmer and made many multiplayer games (like Ravage Online and SIEGE) because it really excites me to see it all work. For those games I used existing networking libraries like RakNet and ENet. Although, I found it was time to make my own for once. Not to make a new wheel, but to see how it rolls. This will make the finding of an internship easier as well.


For every project you will need an end goal. I want my networking library to be fast and UDP only, as you can build the reliability layer yourself. So I started off in a blank project and made three projects: Client, Server and EvayrNet. EvayrNet is only producing a .lib file which both Client and Server are using to get their functionality from (and eventually your own project).


I kept my progress hidden for a while on a private repository on GitHub until it's ready for testing, which I feel is now (although it currently has some slight issues). You can check it out here.


The initial integration

I now want to make a simple game to see if my networking library actually does like it is intended to. I quickly wanted to make a simple game like

or something similar to a "
" so I started off by making loads of ball objects and see if I can make the server run some AI for stress-testing. This is the result so far:




Looking good so far. smile.png Works okay up to 64 players, but any more is killing the server right now due to too many physics calculations. I'll be looking into threading before next time.


For an extended video explaining the library, check it out below:


Polishing games



Game polishing is one of the most important factors to grab someone's attention. It also makes the gameplay feel smoother and generally makes the game look more done. But how do we do it? Here are 5 ways to add polishing into your game:

  1. Lerping
    Lerping is a term to make transitions smoother. This is commonly used in animations, where you linearly interpolate one frame into another. Animations and transitions will stop looking 'choppy' and will actually blend into the smooth gameplay.
    I quickly made an example with Ravage Online:
    Notice how the M4A1 zooms in smoother than the AK47. It adds a bit to the game feel and immersion.
    Lerping can be used with animations, loading screens/bars, replay systems, particles and many more.
  2. Adding ambiances
    Ambiances are sometimes forgotten in games. They add a bit to the game feel and add meaning/immersion into the world the player is playing in.
    Examples of ambiances can be some torches, clouds, wind effects, sound and fog. The key to proper ambiance is to make sure there's always something moving or happening on the screen. In FPS games you usually see piece of papers flying around, or some smoke/fog through in the level.
    This screenshot is a great example of it. Grass, trees and plants keep moving, the sky is animated, people are walking around, you can hear ambiance sound and the light of day is changing. There's always something happening on the screen. It's not really hard to implement it either - just a lot of little things that greatly increase the immersion and feel.
  3. Balancing games
    Balancing is actually a bigger topic to talk about, but it's mainly tweaking values until it feel right. In competitive multiplayer this is a different story, but for singleplayer you want to try to make items and mechanics unique in their own way. In Ravage Online I wanted to make the M4A1 and AK47 feel way different from eachother, but still fall into the category 'Assault Rifle'.
    Sometimes it's easy to look at their own unique characteristics such as the AK47 having a lot of damage and recoil, while the M4A1 is usually known as being accurate and have a lot of stability. In conclusion of this I made the M4A1 4-shot kill in the chest and the AK47 3-shot kill. Because the AK47 has a lot more damage now but is known for its high recoil, I added a lot of kickback in the animation. This makes the AK47 less efficient on medium to high range combat, making the M4A1 more favorable in those situations.
    I can talk a lot more about these kind of changes, but the key points is just changing values and have them tested by others to make your final changes.
  4. Particles
    Particles are an extremely easy way to add polishing to the game. They give instantaneous feedback and add a lot more to the game feel. Because particles are easy to make, tweak and render, you can pretty much use it for anything: Footsteps, gun smoke, fire, impacts, water splashes and a lot more.
    This does add a bit more to the ambiance and immersion but the extra feedback makes it nice as well.
    In this screenshot you can see the muzzle flash, indicating the player that the gun has fired (sound also helps). The tracers help players to see where the bullet came from and where it landed. The shooter gets feedback on how accurate the weapon at that range is and the victim is aware of where it came from.
    The blood also is an indication for both the shooter and the victim that the victim has been hit. I'm still planning on a hitmarker so that the shooter has an easier time indicating the the victim has been hit.
  5. Game pacing
    Sometimes a player can be bored by the game because of the lack of game round/match speed. In 4-player games where players can die (like Super Smash Bros and Towerfall Ascension) players have to sit idly by watching the game go over. If you create quick and fun games, the player will only have to sit and realize what they did wrong instead of waiting for the round to end. This also has to do with the scope of your game. Quick games that only take 5-10 minutes (per round) have proven to (usually) be very fun because it's so polished (like Mario Kart 8 and many indie games).
    Another way to use game pacing is by spawning more objects. An example of this is where a gun is supposed to deal 50 damage with one shot, but only shoots one bullet. A way to use pacing is to make the rifle fire 5 times as fast, but let the bullets do 10 damage each. It kinda affects the balancing but the gun might feel better now.

I want to end this topic with the very useful video by Jan Willem Nijman from the company Vlambeer with their video "The art of screenshake". The video contains a lot more info about what I did and didn't talk about. It's worth watching the whole thing:



Thanks again for reading!


- Ivar / Evayr


Felt like writing another blog... So here we go!




Goals, motivators and progression are crucial in order to keep your player playing for a decent amount of time. Goals are usually represented with objectives or progression, engaging the player into the game and let them have a reason to keep playing.


Like I talked about in the previous blog post, progression matters a lot when it comes to engagement. It gives the player a sense of achievement which keeps the player motivated to play. Rewards for progression give the player a good vibe and will most likely continue.


Rewards can be anything: A chest full of gold, the newest weaponry, but also a small little sound that plays whenever you pick something up (like coins!). I noticed with the recent playerbase playing mobile games: people want to be rewarded as many times as possible. (A sound or a bit of score could be enough already.)


Now I doubt anybody here is making mobile games, but you can process this concept in PC, Mac, Linux and console games - any type of game really.



Let's take a look at the following game: Super Mario 64 (N64)



The game is constantly rewarding you for progression. Here we see:


1: Breadcrumbs (Motivator)

Coins are leading to a path towards the end of the level. Coins reward you by adding score, restoring health and giving a star and life at 100 coins. The coin rotates, giving the player some feedback that it can be interacted with. It also plays a little sound when picking up, this gives the player some extra positive feedback. Because coins actually help you, the player is motivated to pick them up - which is exactly what the developers of the level want you to do.


2: Exploration (Goal)

The player is now familiar with the coins, but this one is red! Woah! When the player picks the coin up it gives a different sound which gets higher pitched if you collect more of them. The coin also is worth two yellow coins (restoring two health as well), giving the player another reason to pick them up.


But because a number pops up indicating how many red coins you've picked up, the player will be eager to find more because there might be a reward for collecting them all. This adds up to the exploration of the level so the playtime of the game gets extended without having to add extra features or mechanics - while it is still fun!


3: Camera angle (Progression)

This game isn't the best example of it, but sometimes games try to aim you towards the end by having the camera point at them. As soon as you get closer and closer you can feel the reward coming to you. "I'm so close, let's just finish it!"


A good example of this is Journey, where in the intro you see this giant mountain. The game helps you towards your goal while the player doesn't necessarily notices it.


Game flow

The game can be simplified into this triangle:



The player gets a goal (obtain a 3rNzQj8.jpg), gets challenged by obstacles and eventually gets rewarded with a fancy, shiny 3rNzQj8.jpg. *insert progression sound here*


So how do you keep a player challenged?

There are ways by introducing new mechanics, but that will increase the scope of your project. However, the mechanics don't have to be unique or difficult. Portal has a good example of that:


First they introduce a player to a fail-proof area. The player can't die here, nor is there an ability to fail the level in any way. As soon as the player knows how the certain mechanic or obstacle works, (s)he can progress to the next level.


In the second level the player won't have a safety net: It's time to put it to the test. The player gets challenged with his new knowledge and has to try to succeed using the knowledge he just gained. Usually it's somewhat the same puzzle but a little bit more difficult. If you try to change the way the newly learned mechanic is used in the second level, the player might get confused and punished too much by dying all the time - resulting in the player quitting the game. So don't.


In the third level the player knows the mechanic and has proven that (s)he can use it effectively. Usually you add a new way of using the mechanic by getting a bit creative where you also hint the player using signposting. An example could be breadcrumbs, arrows or particles popping up like "Hey, maybe you can use this!" (or just an NPC helper saying it). A safety net is not required, but helpful. You don't want the player to be punished for trying to learn - but that depends on the challenge as well.


You can see this coming back in this video:




So coming back to the question, you keep a player challenged by either introducing new obstacles or new mechanics. Rewards can help the progression of the player. In RPGs if you level up your combat stats so you can eventually get new weapons and armor. With this new gear you can kill new monsters, get new unlocks and adventure. It's actually an infinite loop of goal, challenge and reward if you think about it.



So to summarize this all up:

- Have clear goals (and have the player know his goal at all time)

- Give the player a sense of progression (feedback on coins collected, etc)

- Give the player an appropriate reward so he can advance in the game (sometimes a sound, sometimes a chest of gold)

- Have a clear game-flow (goal -> challenge -> reward -> goal)


Thanks for reading! My next blog post will be about juicing up the game.


Oh, and here's your reward:



Developing games

Haven't written a blog before, but things have always come into my mind about certain subjects.. Figured I should finally start writing a blog.


This blog is mainly about my personal experience and advice on making games in general. Even though I've made some games like Ravage Online (RO) and the potential Grievous Grounds (GG); the games aren't really done and I'll be elaborating how this has happened.







The scope of both of these games are pretty big. For Grievous Grounds it was a little big too big. But why?

I basically wanted to do something challenging, something I could work on for months and have a super shiny professional result, bursting out of my portfolio website.


The problem here is: I don't have the time.

I got accepted on the NHTV (best school in the Netherlands) and have to prove myself worthy by getting all the ECTs. We have to do a lot of cool stuff like making games, studying history and managing projects (and teams). The scope of RO and GG are way too big where I can show little progression after every session of programming.


I DO like Leadwerks and I definitely want to become a video game programmer in the future, but school has the priority right now.


The solution:

If you want to make games, keep the scope very small. Something that can already have a prototype in a week. You won't be able to make an advanced game like Minecraft in a week. In fact, even Notch started his project small. All you could do is place and remove blocks in the world of 3D Pixels. After that you have all the time to add in extra functionality and increase the scope little by little.


Just look at Minecraft now: Crafting, story mode, mobs wandering around... If you wanted to do all of this from the start, Notch probably wouldn't have finished the alpha in the first place: It's too much work.


Example of a small scope

For GameLab at school (project based learning) we have to make a game where we got two random themes: Chain and Flat. We came up with the idea of a very simple game where you have to blow stuff up (by using chain reactions).


After day one we already got a working prototype with the core mechanics: Place bombs, blow stuff up.

This gives a relieve because you know you can achieve it because you just proved it. The scope it small, it's easy to prototype (to see whether it's fun or not) and you can easily add features to it (like in our case a replay system).


Define a finish line

If you don't define what the finish line is, you'll be running a marathon with no end. You'll get exhausted and bored of your project and disregard it. Make sure you know what has to be in the game in order to be complete. This is primarily the reason why RO and GG haven't been finished.


Working on a project

Progress takes time and has to be rewarded. You nowadays constantly see games rewarding the player for every move he makes. Example:




It might sound really weird, but rewarding yourself for every progress motivates you. Progress in general motivates you - all you have to do is make it visible to yourself that you made progress: Now how do you do this?


(Tip: Reward the player in games! Give them a reason to progress and keep progressing. If you don't the player might feel lost because of the lack of (positive) feedback.


Examples of rewarding: +5XP's all over the screen, unlocks, achievements, progression bars, etc.)



This technique is used to show what to do, what's in progress, what needs to be tested and what's already done. We use this technique during the development of our explosion game (in GameLab). SCRUM allows yourself to show a lot of progress and displays what others are doing as well.


We use Trello for our SCRUM. As you can see on the screenshot everything is clear, organized and displays progress at any time:



There are other ways to display progress, like a Google Docs document where you mark everything green of what's done - that works as well. As long as you can display progress to yourself (and your team).


Finishing a game

This is the hardest part. Finishing a game takes so much time because you have to do all kinds of stuff like polishing, reviewing and bug fixing. The only way to prevent a lot of polishing and reviewing, I'd suggest to playtest your game as soon and as many times as possible. This shows your game's strengths, weaknesses and bugs you wouldn't find out on your own.


Don't be afraid to show it to your friends! They might be harsh on some parts, but if you take the most important feedback out of it you'll improve your game's experience by at least 50%.


Polishing also takes a LOT of time, this might eventually take about 15% of the actual development time. You want to deliver an enjoyable experience towards the player, not a buggy one where it can break once every 3 times. This can make the player frustrated and put down the game. Polishing is really important and do take your time for it.


At last, I'd recommend working on the game at least once every week. This prevents confusion of what you've written before and how your game's pipeline works.

Example: "How do I modify the AI's thinking again?"





Keep your scope small.

Define a finish line.

Display progression (like using SCRUM) and motivate yourself with it.

Playtest as much and many times as possible.

..And finish your game!


Thanks for reading!

Sign in to follow this