First look at basic GDI graphics programming

One of the courses that I'm currently studying is called  Advanced C++ for Games II, where we are currently working with GDI for rendering of simple programs that will eventually develop into a racing game. GDI is a core component of the Windows operating system, where it handles simple rendering onto devices such as monitors.

So far we have only worked with various things related to the very basics of 3D-rendering, drawing triangles. And why is that? The reason is because a triangle is the minimal geometrical figure that is always certain to have a flat surface, and it's therefor why all 3D-models in the end is a collection of several triangles.

Below is a screenshot of what our program currently looks like. It's may not seem like it is very much, but now we have the basics of rendering a triangle implemented, which is a huge step in the right direction if making this a proper 3D-game.

An Introduction to Introductory Programming with Java

I'm currently studying a course called Introductory Programming with Java (Swe: Inlednande Programming med Java) at Campus Gotland.

In the course, we work with an Interactive Development Environment called Greenfoot. The environment comes with functionality that can be used to develop simple top-down games like 2D-shooters or simple puzzle games.

So far this course has been going pretty smoothly for me, as the course is meant for people who are completely new to programming. And compared to what I've been thought in my other programming courses at Gotland, the concept that we are being thought here are pretty simple. My reason for taking this course though was because of a combination of that there were no other interesting courses and I figured that a refresher course in Java couldn't have hurt (I studied Java in high-school for 2 years).

Although I don't have much impressive to show of right now, I'll show some of what I've been working on later.

Post GGC-thoughts

So GGC is now finally over. Despite technical issues and that the demo ghost was present for me during GGC, I was still able to show of what I made during this course.

Feedback on my game
I couple of people came over and tried my game at the Gotland Game Conference. One thing that many people said was that the game needed more polish and that the player should have gotten more feedback, but it is a good base to keep developing the game further with. And If I'm going to be honest, that's all fair feedback, these are certainly things that could improve with my game.

Beyond that, this GGC proved to me once again that you cannot satisfy everyone all the time, some people liked the game more then others. But overall, I get the feeling that the game is something that could be developed further.

Future plans
Because of what I got to hear about the game at GGC, I'm going to keep developing the game. I can't currently give an exact timeframe for all of this, but here are a couple of things that will happen with the game in the future.

• More feedback to the players. This was the thing that I got to hear the most of at GGC, and as a result this is something that will have high priority going forward with this project.
• Add the missing mechanics. The GGC prototype does not contain all mechanics that i want to have in my game and I will keep developing 
• More units to the game. As of right now, you only have one unit that deals randomized damage values. This will change in the future, more units will be added to the game as time goes on.
• Improvements to the back-end code. Towards the end of this project, more and more of the code was done in a way that only enabled it to work at GGC, while not providing the possibility to expand the game later on. With new code, I will hopefully be able to add...
• ...Network Support. It's not an RTS game if you can't play it against another human player. I will work on adding network support to the game in order to make this happen. I will write another blog post later about my plans on this front are.

Final sprint for GGC

Next weeks is GGC, and I'm now on the last sprint for the prototype that will be shown at the GGC show floor.

And how far have I come with the prototype? Well, I'm basically done with it. All the systems are now functional and almost everything graphics related is implemented. The thing that is left for me to work on a fog-of-war system, add some particle effects, fix a few bugs, change a few numbers in the code, and then I'm ready to go.

Improving feedback
One thing that I got feedback on during the beta testing, which we had earlier this week, was that I need to give the players more feedback to what's going on within the game. I've been adding sound effect when the various units are in combat with each other. I've also made it is so that the unit that you currently have selected is rendered using different materials than the other units

New fog-of-war system
During this week, my teacher gave me a fog-of-war system that I could use in my game. And for most of the part, it was basically drag-and-drop to implement that system properly. The system worked in the way that the main camera was essentially all black, and then you put fog-of-war revelers on your game objects to show parts of the map.The system had one issue though. There was a hair-thin line between revealing to much and to little of the map. As a result, I decided to ditch that system and instead start working on another system. I can show more once I get the system to function properly.

Other improvements
I will also look into adding particle effects to the units when they are in combat. I will also fix the last few bugs that exists in the game. But other than that, the prototype is looking in good shape.

Warbreaking Point Weekly Round-up - May 10th-17th

More and more progress is being done on this game right now.

State Machine Progress
The work on the finite state machine of the units is going forward; I have one more bug to fix on this front (and I've managed to narrow down the possible causes for this bug) and then this part of the units will be done. However so far there hasn't really been much of a game and that's another thing that I've been working on.

Resource System, Constructing Units and Goals of the Prototype
I managed to get some kind of resource system to function this week, so I can demonstrate a demo of the game next week. It's not exactly as I want the final game's resource system to function, but it is at least something.

Now I'm working on a system to create units manually in the game. Currently the state machine bug above is putting a stop for my progress on this front, but once I manages to find that bug I think things are going to go smooth from here on. How this system will work is that the player will press a button on the keyboard and if the player as sufficient resources, a unit will spawn near the player's base. I wanted  it to function a bit differently, but due to a bug that I (and a few friends that I ask) can't wrap my head around why it is happening, I went with this solution instead.

For GGC (The conference where all the students show of their games), the goal for the player will be to eliminate a certain amount of enemy units in order to win the game. This was chosen because it should be relatively easy to implement. Even though I want to have the player to destroy the opponent's building as the goal of the game, it would require more work in order to function properly, as well as a general overhaul of how the back-end code of the game works.

Warbreaking Point Weekly Round-up - May 3rd - 9th

This week has been a slow week for me and the development of the game. There are two main reasons for this. The first has been that I have been sick during parts of the week, and therefore haven't had as much energy to work on this as I've hoped. The second reasons is that things have been going slowly overall, solving issues has taken more time than I anticipated. But some progress has been done, and now it's time to talk about what.

The State Machine for the Unit
This week I have been working on the units Finite-State Machine (or just State Machine for short). And this has been proven to be harder than I anticipated. There are essentially two parts of the State Machine that the units will have in my game.

The first part is a State Machine that automatically changes the internal unit type of the unit as required. And why is this needed in my game? The reason is because of how the the system I use for the grid, tiles as well as movement is built up internally; you can only have one unit of each unit type at a single tile at any given time. However; units from different units type can be on the same tile at the same time, and the type can be changed while the game is in progress. I manged to get this code to work, I just have some occasional bug left to fix and then this is done.

The second part of it is a State Machine that changes a unit's state based on the events on the board. For example, if a unit from one player is on the same tile as a unit from another player, then the two units should go into combat with each other. And this part in particular has taken more time than I anticipated. I only managed to get the very basic parts of this to work this morning. I will need to spend time during the weekend and next week to implement it properly. But I believe that it is doable to get done relatively soon

Work-in-progress screenshot
Here are one work-in-progress screenshot of the game. All the graphics are placeholders for now and they will be replaced with new graphics later on.

Warbreaking Point Weekly Round-up - April 26th - May 2nd

Another week of development has passed and more work is being done on this project. Here's what I managed to achieve this week.

I got a logo for my game!
With help from one of the staff members at Campus Gotland, Lina Tonegran, I finally got myself a logo for this game. I gave some ideas of what I wanted, she gave my some sketches and eventually we landed on the final logo of the game.

Once again, thank you so much Lina.

Get the input, grid and movement system to work
After much sweat, I finally managed to implement the input, grid and movement systems inside the game. This was achieved by looking into the code for the scripting package Tile Based Map and Nav (Which is the base that I've been working from) and try to adopt the included code so that it could fit my game. It took some time to get right and it also took some time to debug it all, but I finally manged to make the core system of my game to work.

Some fixes still remains to be done on this front though, but most of it is now ready for further development.

Design decision: Max 3 units from one player can occupy a tile at any given time
I mainly based my decision on 2 big reasons. The first one is because of how Tile Based Map and Nav is working internally. Each tile in the game is assigned certain values for it's tile type. For example, it could be a land tile, an water tile or both at the same given time (For example, in an harbor). This makes it tricky (but not impossible) to make a general code that can handle a big amount of units on each tile at any given time.

The other reasons is that it would be to tricky to manage squares that has to many units on them at any given time. I noticed this when I was playing Europa Univeralis 4 a while back (that has a similar systems to those I want to have in my game), and I noticed it was hard to proper manage provinces that had multiple units on them at the same time. This is not a major problem in EU4, as you can pause and unpause the time in that game. However, my game is a real-time so unlimited unites per square isn't going to work all that well

Because of this, I decided that on each given tile, there can only be three units from each player at a single given time.

Implementing simple 3D-models
Even though I'm currently only using placeholder units from the grid system that I bought at the Unity Asset Store, I've managed to implement 3D-models into my game. It's just placeholder models for now, but it's enough for the development of the game for now. I'm not an artist, and my priority right now is to make the gameplay function properly.

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.

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.

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.

Programming, cotainers and games

Hello Again.
Sorry for the period of silence for me, but things has been getting in the way for me. Anyway, lets talk a bit about the programing course. In the course, we have two assignments that needs to be done before the end of the course

Assignment 1

The first assignment is to write three different container classes, classes that can store several other objects, and run tests on them. The first test is to see if the classes works properly, which our teacher has provided us code with. The second test is to read a couple of numbers from a file, insert them into the containers and then go through the container to see what numbers are missing, and insert them manually into the container. And we are going to clock how long time this takes for each container, and write a report about it.

The three types of containers that we should write are a linked list, a dynamic array and a binary search tree. I'm more or less finished with the former two, have some minor changes that needs to be done to them and then run them through our teacher's test. I have a bit left to do on the binary search tree, but it's nearing competition as well.

This assignment is good in the regard that it will show us that different containers are useful for different purposes.

Assignment 2

Our second assignment, that we got to know of today, is to write a simple game of our choice (in C++) and write a report of our choice. There is one twist to all of this however; in the code, we need to implement a couple of things. I'm not going to go through all of them, but it's various ways that you can design your code in.

I've written games before during my studies, so I'm not expecting any major challenges since we can write a simple, arcade game for this course. Currently, I'm leaning toward that I will do a Snake game. I haven't done it before, but I have ideas of how to solve things inside the game, so once I can get started, it should be that big of an issue.

My programming journey at Gotland.

Lets write a blog post about programming as a variation to all my writings about game design.

Before I started studying at Gotland University (which was merged into Uppsala University earlier this summer), I had programmed in high-school for two years in Java. Among the things I wrote there was an Asteroids game, a game of the Swedish card game Vändåtta with network code (although you had to know the IP for that, so no MMO game) and a game where you where moving a ball towards your mouse and the primary goal was to kill other balls with it.

However at Gotland University, we was going to work with C++. Even though I know that Java is based on C++, I was still unsure of how things were going to go for me programming in C++. And it went a lot better than I expected. Aside from dynamic memory allocation and pointers, both languages are essentially the same with a few syntax differences and different names for methods.

At the end of my first semester, I had not only managed to learn a new programming language (C++), a new Integrated Development Environment (Visual Studio) and a new multimedia library (SDL), I had also managed to use those things to re-create the ball game I wrote in high-school (although with less features, as I had more time to do the initial game in high-school). By the end of next semester, I had managed to program in another new multimedia library (SFML) and learned lots of new things on the way there (mostly things that only programmers can appriciate, but that's another discussion).

There is two important reasons to as of why I learned so much so quickly. The first one is my motivation, I want to learn to program. There is always something to learn and there are always a million and one ways to improve the code that you've already written. The Game Design and Programming program was the best programming program I could find in Sweden (although Game Design is very interesting as well).

The second factor is that I had two really awesome teachers at Gotland University; Rikard Jaksch and Ted Wikman. Both of them where really good and helpful to me when I had those as teachers. Long story short, I don't think I could've asked for any better teachers to have during my first year at University. Once again big thanks to both of you.

So the next time you question that think among the lines of "I will never be able to learn something that quickly" I want to say this for you. You can achieve a lot more in short time than you might think as long as you are motivated to learn it. And it doesn't apply to just programming either, it applies to art, game design, music creation, cooking or just about anything else in life.