Warbreaking Point Weekly Round-up - April 18-25th

After a deserved Easter break together with my family, I'm now back on track with new mental energy for the Big Game Project. First of all, I have decided on a proper title for my game, which is "Warbreaking Point". This was just something that I came up in my head while I was getting back from the Easter holiday.

Then, I'll talk about what has also happened since the last post. Since that time, I've been looking into the Unity Asset Store for assets and useful technology for my game. So far I've found 2 technologies and 1 asset  pack that I will use for this project:

• Tile Based Map and Nav is a scripting tool that allows the creation of tiled grids (both square- and hexagon-based tiles), and some useful functionality that comes along with it; like simple path-finding for moving from one square to another. After looking into the source code and a couple of examples that was included with the purchase, I think this is going to work out great for my game. I will need to make some adaptations to the code that was included with this pack, but I don't think that it is going to be too big of an issue, as it already has a good foundation of what I need going forward with my project.

• GoogleFu is an Unity editor extension that allows you to export data from Google Spreadsheets into Unity and access the data from there, with no need for internet connection once the spreadsheet is exported. This was the daily deal and the Unity Asset Store a few days back and I bought it because it could come in handy when I (hopefully) develop this game with a full team next year; as Google Spreadsheets are a good way of collaborating when several people are working on something together.

• Even when working alone, GoogleFu is also useful because it allows you to extract game variables (like a unit's health, speed, attack damage and so forth) into an external file rather than hard-coding it into the game. As a general rule, you should never hard-code numbers into a game's code, as you might want to use that number in several places in the code and if you had hard-coded it into the game, you'd had to change it in several places if you every decide to change it and you might very well miss one variables because of this. This also allows people to understand your code better, as the number 100 does not really tell what it is used for; while a variable named Unit_Infantry_Health is very informative, even for those how are not directly involved with your project.

• 300+ 2D Projectiles, Icons, and Items is a collection of various icons for usage in games. I bought this because it's made by an Indie Developer whom I am personally a big fan of, and it had some useful stuff that I could use for the GUI in my game.

Overall, it feels really good that I've now started looking into how to make my game. I feel that I can accomplish a vertical slice to show at Gotland Game Conference. It may not be a full game, but my teachers want to see what I can do of the concept

In the relatively near future, I'm planning on making my concept/design document publicly available for everyone to watch and submit feedback on. 

Project Clint Weekly Roundup - April 12-17

This weeks round-up post comes a bit early because it's Easter and all what that means.

Sitting with Unity
While not complementing previous courses, I've sat more and trying to learn myself the Unity game engine. I'm starting to get a hang of how the engine and the  scripting system and such is working, although this will probably be a constant process as the development goes along. I feel ready to start working for real next week.

Talking to teachers
I've been talking to my teacher about this project as well, and I've made some small changes to my plan based on what happened during those talks. No change were major though.

Next week - Grid and movement system
Next week I finally start working on this game for real, and then my main task will be to get the grid/movement system working, and the subsystems that are required for that to work properly (like A* for the movement system and the unit's path-finding). This task is being done first partly because of that this is a part of the core mechanic of my game, partly because of that the other tasks related to this one should be easier to implement once this system is on place

Big Game Project Weekly Roundup: April 7-11

My first, real week of the Big Game Project is now finished. From now on, I  will blog at least once a week, and do some weekly roundup on what happened during the week.

April 7-9: Talking to my teachers about what to do
I spent the first three days of this week talking to my teachers about what I should do during the course since I was the last man standing while every other Big Game Group was filled. In the end, we decided to let me work alone on a vertical slice of the game I pitched to them earlier in the course, and hopefully make the game in  full next year.

The reason why I didn't pitch this concept for the rest of the class was not because of the fact that it was a bad idea. In fact, my teachers really liked my idea and they really wanted me to keep working on it. The thing was that since this is a strategy game, you'll need lots of  Rock-Paper-Scissors triangles of units and such to keep it interesting (Håkan thought that 12 different units was the bare minimum required for the game to be interesting). It would simply be to much work for the Big Game Project, even if we were to work in a big group. That's why I'm only making a vertical slice now

April 10-11: Learning the basics of Unity
The past few days, I've been sitting and trying to learn myself the Unity game engine; which I only have limited experience since earlier on. I've been mostly sitting with a stealth game tutorial from Unity's official site. So far I have a hang of how things work with the engine and such

Next week: Keep learning Unity
As planned together with my teachers, I will keep sitting and learning myself Unity the next week. I will look into more tutorials, as well as reading a book on Unity that I got to borrow from my teacher that it very up-to-date.

Looking ahead: Assets
Since I'm not an artist, I'll most likely download/buy assets from the Unity asset store and work with them. My teacher also told me that there might be a person who can help me with the GUI of the game, but that comes later.

Announcing "Project Clint"

Since I was the last man among my class that was without a group after all groups were filled, I talked to my teachers about what to do. After listening to a few suggestions and having discussions about it, we arrived at the conclusion that I would work on a vertical slice/prototype about a certain part of the idea that I pitched to my teachers last week, and then make the full game once the third year starts.

So that's why I'm announcing my project, which until I've decided on a better title will have the working title "Project Clint" (After Clint Barton, aka Hawkeye from Marvel comics, whom I'm a big fan of). You can have a look at my first, rough concept document here. Because it is the first rough version of the concept document, things will most likely change as time goes on. I will talk more with my teachers later today (April 9th) about the project and help on deciding a project plan.

Preparing for year 3 already now.

Right now, the Big Game project course has started. Some groups are already well underway with their projects, others who lacks groups will pitch their game ideas tomorrow (Friday 4th April) and try and find the members they need.

I talked to two teachers at Campus Gotland, Håkan Mattsson and Adam Mayes, about the idea I had for big game project. And they really liked my idea. But the scope was to big for the time that is left on the Big Game course, in combination with some personal reasons affecting my life (It's nothing serious though,  you do not need to worry). But they encourage me to keep the idea alive and try to make during year three. Which I will do.

As much as my summer schedule will work, I will keep polishing the ideas that I had and try to code simple prototypes of the game. And we'll see what'll become of it.

(Part 2) Swedish Game Awards Conference 2014 Report - Talks

Another thing that also happens during SGA Conferences is talks from various people in the game industry. Below is a short summary of the talks that I could attend.

Romi Gråhed from DICE had a talk about development of games in general, what pitfalls a developer might run into and some general tips and tricks for better development of games.

Linnea Harrison from DICE has a talk about something that DICE calles Levolution. In short, it's how you can change a level in (for example) battlefield that isn't necessarily destruction. She also decided to talk about how they had applied that in a Battlefield 4 level called "Do the Dish", as well as some development tips in general. This talk made me get some inspiration for potential game design ideas as well.

Ida Häggström & Jenna Sourander from Fondia has a talk about legal matters in games. This was a really interesting talk, as you might not be aware of all the legal regulations that exists when you are making games. If you are going to develop games, make sure that you get help to sort out all legal matters.

Martin Lindell from DICE had a talk about the preservation of games and what challenges that it possess. This was a really interesting talk; as it highlighted what makes preserving games hard compared to preserving music for example; as well as some legal problems behind doing just that.

Lead by Angelica Norgren (P3 spel), there was a panel discussion on the Saturday with Josef Fares, Novi Flink and Roger Tónlist about gender issues in games. It brought up a couple of interesting points of discussions, especially from Josef Fares(despite that he contradicted himself a good couple of times)

Johan Pilstead from Arrowhead Studios had a talk about game development in general. He also brought up some general experiences from Arrowhead's own experiences. A really good talk that everyone should listen to if they can.

Daniel Ström of Guru Games had a talk about a concept called Agency. In short, Agency is about being able to make choices in your life and how that could be applied to video games. He also talked  about how agency was applied in their own project called Magnetic.

Timea Tabori from Rockstar North had a talk during the lunch on Sunday. She talked about how she went from being a university student to become a programmer at Rockstar, and also giving tips to other who want to do the same.

Daniel Thronström from Avalanche had a talk called "Why AAA is the new indie". The talk was primary focused on what AAA developers can learn from indie developers and the other way around. General game development tips was also brought up and how the market has changed the past few years. If you ever get a chance to hear this lecture somewhere else, I strongly recommend that you do so.

Bonus: Campus Gotland Group Photo

Image comes from Simon Wulf

Level Design Diary Part 1 (10-12 March)

I'm currently working together with Johan Wittrock on the final assignment in our Level Design course. The assignment is to analyse an level in a certain game, and try to arrive at conclusions to as of why it is the most popular map. Me and Johan choose to analyze Payload maps in Team Fortress 2.¨

So far, by looking at server statistics, we have come to the conclusion that Badwater Basin is the most popular Payload map, followed by Gold Rush. Now, our goal is to put of hypothesizes  to as of why Badwater is the most popular map, and try to see if those hypothesizes are correct 

(Part 1) Swedish Game Awards Conference 2014 Report

Last weekend, Swedish Game Awards Conference 2014 took place in Södertörns Högskola, Stockholm. Me and a couple of other students from Campus Gotland was attending the conference. In the next coming posts, I will give my impressions on the Conference.

I will talk about the talks that was given in the upcoming posts, because there is a lot that can be said about those. The reason to why there aren't many images in these posts is because my phone decided to live it's own life, causing me to lose most of the pictures that I took. And just because I tried and fix it before Day 2, it still didn't want to work on Day 2. Technology...

Student Showcases

One thing that SGAC did this year was to let students at universities in Sweden showcase games, prototypes or demos that they had been working on. I didn't get a chance to play all of the games here, but if those that I managed to play, there were some really good gems. One of the games was the platform game Grief, that I've talked about previously. I still think the games looks great, although I yet again did not manage to play it.

Another games that I saw potential in was a 3rd person action game called Root Force. It was a game where you are playing as a tree stump, and you try to bump out the other teams tree stumps from the map. You can also pick up power-ups, which can make that a lot easier. The game could need more polish, but it still shows potential in the concept.

There was also a 2D puzzle-game that I don't remember the name of, but the idea is that you are playing as a robot that gives instructions to other "dummy robots", and the goal of the game is to rescue a certain amounts of robots. The aesthetics of this game looked really nice, and I really liked the puzzles of this game, although some improvements on the technical side of things could be necessary.

Partner Showcases

Students was not the only ones who was showing stuff during the conference. Other companies was present at the conference as well. This is my impressions of the companies that I managed to get a chance to talk to/visit.

Arrowhead Studios (makers of Magicka) was showing up their new game Helldivers for the PS4. Although the game was fun to play of what I manged to play, I just don't like the PS4 controller. I can't even play 5 minutes without starting to feel weird pains in my hands.

Code Club is the developer of the sandbox game Wurm online. Although they did not show the game, they still talked about it and it looks like they are at least trying to make something new with the sandbox genre that has exploded in the recent years (with games like Minecraft, Terraria and Atarbound).

Fondia is a company that helps persons and companies with legal matters. In addition to having a booth on site, they also had a talk about legal matters in games. More about that in an upcoming posts

King was one of the sponsors of the conference, and they also had a booth at the conference. In addition to showing of their games, they had several employees present at the conference (at least 4 of them), and they were all really nice to talk to.

Although Rovio was present at the expo as well, I think I managed to get the worse timings to meet up with any person from Rovio, as their talks was going on at the same time as other talks that interested me more was going on at the same time, and I didn't managed to find any developer at their booth when I was there.

Analyzing: Counter-Strike: Global Offensive's Competitive mode. [UPDATED 20140213]

Earlier this week, we had our first real lecture in our Level Design course. In the lecture, our teacher (Ernest Adams) mentioned a couple of principles that you need to take into consideration when you are designing a game and design the levels inside the game. During the lecture, I started to thinking that I should do an analysis of Counter-Strike: Global Offensive's competitive mode after those principles.

But before I start talking about that, you will need to understand how CS:GOs money system works. This image below belongs to http://www.vakarm.net/ and it explains how the money system works on defusal maps. What isn't mentioned here is that each player begins the game with 800$ and a full list of what everything costs can be found here. Each competitive match is played over two 15-round halves (the player swaps teams after 15 rounds) and the first team to get to 16 rounds wins.

UPDATE 1: Another link explaining the money system, including the money system for hostage maps, can be found here

Now, lets get down to business and analyze one principle at a time. I'm only analyzing the points I find relevant for CS:GO.

When the player defeats a challenge, replace resources he consumed

In CS:GO, this is done in the form of giving the player and his team some cash when they manage to achieve something in the game like getting kills or planting the bomb. The cash can then be used to buy new grenades, armor or weapon later on in the game. It may not seem like much, but in competitive CS every little amount of money matters. And if the whole team wins a round by achieving a goal together (like planting and detonating the bomb, rescuing hostages or eliminating the opposing team), the whole teams gets a bit of money back as well.

At the start of a new round, every weapon the player has managed to save gets fully replenished with ammunition. Grenades and armor is however not reset at the end of rounds and have to be re-bought. It doesn't replace everything the player used, but it does restore some of the resources used.

·       Be clear about risks and consequences

This is one thing that is very clearly present in competitive CS:GO. If you don't think of what you are doing inside the game, you might very well lose the round, which in term is going to hurt you and your team's economy in the long run.

This is also present when you are constantly firing your weapon. Not only does this alert your enemies of where you are, the recoil and spread of the weapon can also make it so that you actually don't hit anything of what you are aiming towards.

If you die, you don't keep anything your carried during the last round; you start over with just a knife and the default pistol, meaning that you have to re-buy everything again. This makes it clear that you shouldn't take any unnecessary risks in the game.

Be fair to all the players

This is a little tricky to analyze in CS:GO for a couple of reasons. While the rules for getting money inside the match is the same for everyone, and players can freely choose if they want to replace their M4A4, P2000 and P250 with the M4A1-S, USP-S and CZ75-Auto respectively, there are still a couple of points that makes analyzing this point a bit tricks

1) As my friend Inge said to me while we were playing the game, the reason to why the Counter-Terrorists weapons and equipments cost a bit more than the Terrorists is because they usually have an strategical advantage on the maps inside the game on defusal maps. And on hostage maps, Counter-Terrorists can get lots of cash even if they don't win the round, because reaching hostages rewards quite a bit of money.

2) While it may be a Best-of-30 game, you still have to take into consideration that the teams first plays 15 rounds on one side, and then switches sides for the next 15 rounds. While this may seem like a good way to balance out the fact that all maps might not be entirely balanced, and therefor forcing players to play well on both sides; winning the first half of a match can still give a psychological advantage over the opponents.

3) And of course, lots of balance is not just about weapons and cash, it's also much about level design as well. Some maps are IMO much more balanced than others, which makes it hard to analyze it in general as well (especially as a relatively new CS:GO-player)

In the end, I still do think that CS:GO is fair  game for all the players, however if we also take the mental human factor into consideration as well, it's get a bit tricky to analyze all of this as well.

 Use big rewards and small punishments

In CS:GO, this principle is more used like big rewards, big punishments. If your team gets killed and loses the round, you only get a little amount of money initially, while the winning teams gets more money and the surviving players gets to keep their weapons. But the more rounds you loses in a row, the more money your team gets, meaning that it is not entire over only because you lost a round.

When it comes to kills, the kill amount for each weapon is there to balance out the risks with certain weapons. For example, the reason to why a kill with a knife awards so much money is because you have to be in your opponents face in order to be able to deal damage with the weapon. Shotguns also rewards the player with extra money because they are only good at close-combat.

The reason for why the AWP rewards the least amount of cash per kill is because of that the AWP is one of the best weapons in the game; it will 1-shot kill any opponent aside from hits in the legs, it is a very accurate weapon even at long distances while the player uses the scope and it can penetrate through most materials and even players inside the game. However, it also comes with a couple of disadvantages as well, meaning that it is a high-risk, high-reward weapon.

I think the reason to as of why CS:GO does it this way is because in order to keep the game interesting. I don't think competitive CS would be very interesting if the principle of big rewards/small risks was used in the competitive mode, because that would take away much of the challenges with the game.

Update 2: Small improvements

If it's worth doing, it's worth overdoing.

Hello again.
I know it has been quite for some time now, but in the middle of studies, studies, canceled ferries, more studies, Christmas, working with studies during the Christmas break and even more studies, I haven't had much chance to write here.

Anyway, lets write a blog post about programming and one of the assignments we have in that course.

Assignment 2 - Develop a game

One assignment was to develop a simple video game and write a report about it. I choose to develop a game of Snake.

However, the twist to all of this is that the code will receive points depending on what it implements, and a certain number of points is required to pass the assignment. A few examples of this is event-driven sounds and usage of an external library (outside of what you use for rendering and such).

But some of these things may be overkill in relation to how simple the game is. One of these things is having the game being component based. But should we learn it for such a simple game? In snake, such things is overkill.

The reason for that is because we learn the principle behind it. In a larger game/software project, I can certainly understand that component-based programming has its advantages in the long run. Sure, it's overkill for such a simple game as snake, but it has still thought me the principle behind it and I can see the advantages with it.