Big Game Project – Game feature challenge focus

When creating features for a game, one should always consider the aesthetic goal of the game. However sometimes a features need to be deliberately designed so that they do not pose a challenge to the player. Some features just need to be easy to use.

Me and a group of six other people presented a game at the Gotland Game Conference 2015, Tamarrion, a hardcore action role playing game. During development of this game we designed features such as our player skill/spell system. This feature was more focused on giving the player full control of the player avatar than supporting the hardcore challenges of the game.

The challenge of the game was supposed to revolve around avoiding to take health damage from enemy attacks and to use player skills/spells in a certain order and by doing so gain specific special bonus abilities. Almost all other features were designed to help the player, like giving the player a freedom of movement and control.

One could argue that the player movement, player skill and enemy attack features need to be balanced together and the dynamic of these features create the challenge of the game. It is just a matter of perspective. What ever perspective one has when designing challenges, I think that it’s a good thing to keep in mind that some features should not challenge the player at all.

Big Game Project – Using game development engines vs coding from scratch

During our game project we used the Unity game development engine and it was a good choice of engine because of it having many built in features. If you are unfamiliar with Unity, it has an asset store where game developers can upload assets in order to help others by sharing features and sometimes make money from it, having the assets cost a fee. Another fact that made Unity a good choice for our development team is that the engine has existed since 2005. Because it has been around for nine years there are plenty of tutorials and help to be found on the internet when having trouble implementing features.

It helped us during development that the C# programming language can be used with Unity which is similar to the C++ programming language that we have learned through several previous courses in the University program.

We had some trouble using Unity as well. The engine crashed often caused by several different triggers, mainly when changing scenes. We had an issue with the engine crashing when trying to build an executable (if the engine crashed when trying to change scenes, it crashed when trying to build). We found no solution to this, it just seemed to work sometimes and sometimes wouldn’t but fortunately it did not hinder us to a degree that sabotaged the project as a whole.

A problem that I find using Unity and other game development engines (Side note: I have also been involved in a project using Unreal Engine) is that I don’t have full control over stability. Crashes often occur when using development engines and/or features within them that is out of my control. The payoff is that engines have such a great amount of features and using them saves development time. Also, the features are often better executed than if one would design them oneself. This is also true for using code libraries if developing a game from scratch using C++.

I think that the payoffs that come with using game development engines outweigh the problems of not being able to control everything, at least if in a small to medium sized development team with a limited amount of time and money. I see it as a risk though, since not being able to control the stability of the development engines could hinder development greatly.

Big Game Project – Learning game engine functionality (Unity 4.6 Graphical User Interface)

In the current game project that I’m involved with I am constructing menus and other Graphical User Interface (GUI) using Unity version 5.0.

In this post I will describe my initial process of learning the User Interface (UI). I will suggest adjustments to my process since I do not believe that it was efficient.

I started out by trying to find directions on how to create GUI-elements in code by searching the web. I found help and created healthbars.

When showing the healthbar code to my fellow programmer, Anthon Fredriksson, he pointed out that there is a new version of the Unity UI and that I used the old one. I had heard that Unity used a new version but I didn’t see the difference between the new one and the old since I barely have any previous experience using Unity.

I searched the web again for tutorials on the new UI. I watched video tutorials and remade the healthbar using the new UI. On a side note the new UI is extremely easy to use compared to the old one.

The process I went through was iterative and functional. Here is a summary of my process:

1. Searched for information (using the web)
2. Applied new knowledge
3. Got feedback from the team
4. Iterated (go to 1.)

I didn’t search enough before applying the knowledge. I would suggest more focus on the this. I usually want to start working very quickly but if I would increase focus on knowledge gathering I would probably do a more efficient job.

These reflections are personal but I hope that it got you thinking of your work process as well.

Weekly programming – Client positions in fast paced networked games (v50)

Me and my current studygroup have designed a networking skeleton over the past week for our multiplayer space shooter project. We had already decided on using a server-client network model. After discussing how to solve the networking without causing input lag and with a good structure we started working on it.

We chose to split the networking code into a “low end”-part that recieves and sends packets, a “message converter”-part that translates packets into our own message class, and a “message handler”-part that sorts and delivers messages to the game logic.

We listed the types of messages we wanted to send and I will only go into details on how we handled client positions and velocity. When discussing this, me and my group settled on clients  sending a current position and velocity to the server, and the server sending these positions and velocities to all clients. What we realized after todays lecture in game networking is that having the client send it’s current position and velocity is a bad idea. This gives too much authority to the clients as they can send positions that the server just has to accept and it potentially allows for easier cheating.

A better way to do this is the Quake 3 method. Clients should send the control input to the server. In a nutshell, clients send button presses and how long they have been pressed to the server. Both the server and the client processes this information but the server has authority. The position of the player is updated in regular intervals by rubber-banding the player to it’s actual position.

Having already built the code to work with clients sending positions and velocity means that we have to change this part of our current code and handle all issues that come along with it but it will be worth it since it is a better way of doing it.

As the title of this blogpost says, this method is recommended for fast paced games, like FPS’s and not necessarily the best choice to use for other types of games.

The things I talked about here was taught by our teacher Tommi Lipponen as well as from a lecture in the GDC-vault presentation on Halo: Reach’s networking: Link

Weekly programming – The “client” concept (v49)

I’d like to describe a concept connected to code structure this week. I was introduced to this concept in a book I’m currently reading called “More Effective C++: 35 ways to improve your programs and designs” by Scott Meyers. It’s an optional book for our current course in programming.

The concept in a nutshell is making classes with it’s “clients” in mind. Clients are the programmers (perhaps yourself included) and other classes or parts of the code that will use the said class. You might stand at a crossroads where making the class more flexible will take more time right now but can save time for the client later on, so making it more flexible is an investment. You might be the client yourself, so this might save yourself time in the future. Making the “more flexible”-choice is probably the best one.

Programming games often puts a programmer in a team with other people and making the class easy to use and understand for other fellow programmers is, I would argue, always a good thing.

Whenever creating a class keep in mind what it will be used for and how generic you want the class to be. All programmers do this at some level but I believe that this is a somewhat invisible concept and thinking about it can improve a programmers overall skill. I generally make classes for the entire project to work and it usually results in working code but the flexibility of it suffers. I’m currently trying to focus on this concept and improve in this way as a programmer.

One big part of this is planning before actually coding. To plan an overall structure of an entire project at the beginning of it is a good thing but it isn’t enough. Classes need to be flexible, especially when making games. Even though game pipelines often have a feature freeze deadline, things often need to change in the code and making it “client oriented” helps when this occurs. Having a broad understanding of what a purpose of a class is and how it connects to other parts of the code is paramount before beginning to code it. Our teacher, Tommi Lipponen, strongly recommended me and my group to plan more last year. So planning and discussing a class with the programming team before creating it is recommended at all stages of development. As a side note I’d say that it is extra important in the early stages of a project.

This being said, when working towards a deadline sometimes this concept needs to be neglected. If there isn’t enough time, I personally support patching things together and making it WORK is the most important thing. This is a slippery slope however, making things “just work” might bite you in the ass so choose the moments for it carefully. Tommi mentioned this aswell, to the gist of “almost all games are a big pile of rubbish patched together to work”.

This week I had no practical example of code but there is more to coding than that. If this helped anyone I’f love that and I strongly recommend the book I mentioned.

Weekly programming – sending images with a C++ web server (v48)

I’ve completed our second assignment of the course, the C++ web server.

After having completed the required tasks for the assignment I challenged myself by trying to send images with the server as well. It seems easy, you need to load the image into memory and send it as usual with a HTTP-header. Well, it wasn’t as easy as that for me, I needed to make some major changes to my previous code.

The first step, loading the image into memory. I had never loaded an image using std::fstream before but I started by trying to read it like any other file. Previously, I had only used streaming from a file with regular streaming “<<” and “getline()”. Neither of these worked because images are often filled with characters equals to “\ 0” and when that sign occurs when streaming (“<<“) or getline-ing operations are stopped. It’s the standard character for the end of the file when using std::string and std::fstream.

I tried to find a solution and finally I did. When opening the file I set the ios mode to binary and used the fstream function read(). When sending the message to clients I need to supply the size of it, for that I used the fstream function gcount(), it correctly returns the size of the file.

The reason for using a pointer to the heap for the buffer is to support sending bigger images. If trying to allocate memory in the stack when there is no space for it, programs crash and the total size of the stack memory is very limited.

The next step was sending the image with a header. My method for sending messages was using a std::stringstream at the time and converting the buffer to a std::string or streamstream is harder than it seems. When encountering the first “\ 0”-character it would stop the conversion. I actually made a work-around to get this to work. I made a new buffer in the send-method and for-looped in the header, then the message.

It’s not pretty but it works like a charm! This was the result:

To explain my send-method: It takes a target socket, a message, a message length and header information. Another method (the asString_Header()) takes care of converting the header information into a std::string. Thereafter the header is inserted into the buffer, and then the message is inserted after it. This method works for both text and images.

I’d also like to adress the fact that I allocate buffers in the heap of over 10 megabytes (the current value of the #define MAX_SEND) each time I send a message regardless of their size. The information sent to remote sockets are only the exact size of the messages/images themselves though. Anyways, the point I want to make is that this way of doing it is probably not optimal.

I’ve learned a lot by doing this and that was the point of doing it, so mission successful! :)

Weekly programming – Templated Linked List (v46)

This weekend I created a linked list class using tutorials from “Paul Programming” on Youtube (link). This linked list was locked to integer variables.

This tuesday we had a lecture on template programming and I set out to modify my linked list into a templated one.

Before I got it working I had problems with these things;

I started by changing all functions IN the class by adding template<class T> to them. THEN I added the template<class T> to the entire LinkedList class. I got errors that I didn’t understand and the compiler showed errors at places that weren’t relevant. The problem was me adding template<class T> to the functions IN the class, I removed them and it seemed to work.
TL;DR picture:

It seemed to work until I tried to compile. My next problem was defining functions (even the constructor and destructor of the class) in the .cpp-file. I found information on this from stackoverflow (link). Templates are compiled at “compile-time”, not “link-time”. Apparently the header and .cpp-files does not know of each other in “compile-time” and the functions needs to be defined in the header-file when creating a templated class. So I placed all definitions in the header-file and everything works like a charm.
TL;DR picture:

My templated linked list can be found on BitBucket using this link.

Update: It is possible to separate the definition and declaration in different files by adding an include to a second file at the end of the header file. The file ending of the second file should be something other than .cpp. Suggested file endings are: .tpp or .inl. I tried this but VS intellisense didn’t make the connection between the files so I didn’t like this method.

However, I did make one change. It’s a small one. I separated the definitions and declarations in the class while still having them both in the header file. When doing this I encountered another problem when having a method returning a Node (a struct within the template class). When defining the method you need to add “typename” before the return type.
Picture:

I have created a Binary Search Tree as well, check it out in the BitBucket link!

Mystery project is “Desert Raiders” – Game explained – Post #3

I have decided on a production name of my mystery project, it’s now called “Desert Raiders”.

The game is a competative multiplayer arena style game for 2-4 players. The goal of an arena match is to defeat all opponents and be the only player left standing. The core mechanics are simple, players place explosives in order to destroy destructible objects and damage other players.

Descructible objects can drop upgrades that improve players explosives during a match. Players can also have unique special abilities, such as “dash”, “remote explosive” or “teleport”. These abilities are equipped before matches.

Items can be equipped to each player before a match, most change the player avatar’s looks but others enable special abilities.

Items drop randomly and are sold in a shop. The currency for buing items is “supply”, which is gathered by completing quests and playing matches.

As of yet there is only local multiplayer. I aspire to implement networked multiplayer in the future.

Right now I’m working on creating a demo. When it’s done I will upload it here on the blog. I really wan’t to know what you think about it and for you to suggest improvements when I do! Note: It will probably not be done for quite some time. We have an upcoming course in programming that will require my full attention so during that course I will take a break from working on Desert Raiders.

Mystery project – Post #2

The project is coming along nicely and I’m ironing out how I will implement some features as I go along.

I have two major problem areas where I’m not sure how I should proceed.

The first one being character animations. This one I do have a plan for now after speaking and discussing my problem with a fellow student, Georgios Chatzoglakis.

To describe this first problem I will explain my inventory and equipment system briefly. A character in the game may have vanity items equipped that change the appearence of their character. Each item is separate, so a character can be customized in many different ways to let the players express themselves in how their character looks. My problem was that I might need so much animation for every item. Not only do some items need an animation for running, there are some events in which I want the character to be able to do other things, like performing a kick. This would result in a LARGE ammount of time needing to be put into each new item.

The following was Georgios idea. Instead of drawing animations for each item, I could move and rotate the sprites in the game and getting them to “animate” in that way. This will be a challenge since I want the running animation to look realistic and making that happen by rotating and moving sprites will probably be hard for me.

The second problem I have is my business model. Not the model in itself actually, which is Free-To-Play with microtransactions, it’s how the players will pay with real money and linking the purchase to a player account. I want the players to be able to buy items from inside the game and I probably need to link ingame accounts to a database and connect them to a payment system. All this is a grey zone for me and my knowledge of how to link these things together. I need to do some research on this.

I have created most of the core features of the game. I need to polish some of the features and make the game more presentable, that is the next step of development.

I have imlemented Box2d and it’s fully functional and I have playtested the game with friends. The core mechanic seems to hold up but it needs some balancing as it stands now. I am about to implement another system to add depth and a reason for microtransactions to happen which will affect the balance of the entire game. I will create this completely before attempting to balance any further.

I’m aware that I am pretty cryptic in describing the game. The reason for this is that I need to define how to present the game and I actually want it to be a bit secret (;D), until I have something to present at least.

Until next update, stay awesome folks ;)

Mystery project – Post #1

I have started to create a 2d game using C++, SFML and Box2D. It has been in the works for about a week now and I have grand plans for it.

Before starting on this project I have been trying to figure out what type of game I would like to create on the side, while studying. I have created several game concepts and now I’ve finally found one that I believe in.

I will not be able to work this project continously since some of our courses will simply take up too much of my time, especially our future programming course which will probably to be extremely tough and time consuming.

Anyways, I have chosen a familiar core mechanic for this project and have written a document containing my current goals and all systems needed to make the project successful.

I will begin making the game with only shapes, no sprites, as I try to familiarize myself to Box2D which I have chosen as my collision engine. I have consulted friends from my class and I have researched Box2D to some extent on the internet and it seems to be a good choice to use for this project.

The next step will be to continue programming for now, make the game playable a.s.a.p. and to write a more structured document for myself to keep track of my progress. Through our previous courses at the university I have learned that some form of document or progress tracker is vital to a projects success.

More info on this in the future!