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.

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

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.

Advanced Game Design Postmortem

My groups and my personal postmortem for the course in Advanced Game is now available on our group's wiki.
My individual postmortem
The group's postmortem

Board Game Progress Report (Advanced Game Design) - The End

Yesterday, we presented the final game that we came up with for the other groups and some staff at Campus Gotland. Below are some of the changes that was made to the final version of the game.

In addition to a slightly reworked board, there are also a few tiles on the board that only the monster can move on (marked green on the image below). The reason for adding those tiles is because we thought that the monster needed to get stronger in some way. We tried and solve this by having the monster rolling one or two D8 instead of D6 as the players. This made the monster to powerful however, so it was scrapped. What we instead came up with was a few shortcuts that only the monster could use, to improve it's movement somewhat. This also increases the risk for players searching the small rooms (marked 60 and 168 on the image below), as they can now "get attacked" from two sides. However, searching the small rooms gives the players two wand cards instead of one.







































Aside from the new board, the only thing that was added was the name of the game, which we decided to call ShadowPath. Now all that is left is to write a postmortem of the game and hand it in on Friday. Then this course is over and I start new courses in math and programming, my two favorite subjects!

Board Game Progress Report (Advanced Game Design) - 20131029

Today, we had our teacher for the course (Adam Mayes) play our game and give feedback on it in it's current state.

Initially, he was skeptical to as of how the monster's hidden movement was going to work in practice. However, after playing the game, he liked the game as it was. He got to play as the monster and the game was very tight overall to the very last. Although he thought that we could keep iterate on what we already had, if all of that failed, we could reverse to the game as it is now and hand that in.

One thing that we started testing before meeting Adam was a new, larger board and making it so that the players moves 2D6 rather than 1D6 each turn. The reason for testing this out is because we thought that the game would be easier to balance with 2 dice rather than 1, because now we can keep the average of 7 from 2D6 in mind when making the new board.

As before, Christian Roupé is the main person responsible for design the new board. Although we are going to make more changes to the new board, here is how the board looked earlier today.

As before, the monster starts in the middle and the other players starts in the corners. The red-marked rooms are search rooms, where the player has to search for the talisman and then escape the maze by getting to one of the corners.

Board Game Progress Report (Serious Games) - 20131027

We are now nearing the end of the final assignment in the Serious Games course; on monday we are going to handle the game in as well as the rules and a individual report.

This week, our group sat down and polished the numbers that we had in our game, as the game's mechanics were finished but the numbers for everything could use some polish. We also made it so that the player in the game can now discard two tool cards during a round in order to draw a new card. This was added so that the player wasn't completely screwed if he ended up getting tool cards that he would not have any use for. Other than that, we made the cards in the game look a bit more nicer, even though they doesn't have fancy graphics.

Other than that, we now have more concert explanations on the tool cards to as of why the tool cards works against diseases. The information for this was mostly gathered through Socialsyrelsen (Sweden's Social Board) and 1177.se (A site containing information about sicknesses, diseases, health and the such), as having trustworthy sources for a Serious Game is important.

But there isn't really all that much more to say about the game, it is now finished and we are going to hand it in tomorrow.

Board Game Progress Report (Advanced Game Design) - 2013027

(I haven't made a blog post about some of these things earlier because there has been things that has been coming in the way for me)

This week, the work has been more divided among the different members in the group. One person was looking into a new version of the board for our game, others were looking into wands (what we call items in the game that could be found by searching) and others looked into writing on the game design document.

As a mentioned earlier, we now have a new board in our game, that is better balanced and more fair for all players. We also have new wands (full list is available here) that the players can use to their advantage and the design document is hopefully more readable.

We had a play-testing session earlier this week, were we let other groups test our game and give us feedback. Overall, people seemed to like our game but thought that we needed to polish some things more in the game. That is fair feedback if you ask me, the groups that tested our game brought up some good points that we can take into consideration when we keep working on our game.

In addition to new wands and a new board, we've made some other changes to the rules of the game as well. Now the players have two health  points, and they are out of the game when they have lost both of them. The players also have the option to steal the talisman from a player carrying it. This was added so the game would get more interesting, as we had noticed that the game could become stale as soon as someone got the talisman. Now the monster moves with a D8 rather than a D6 as the players, as we felt that the monster needed to become faster somehow.

The biggest challenge for us this week was to find a place and time where we all could together. Three persons in the group have the course Serious Games, and trying to synchronize those groups with this group has been a big challenge for us this week. And in my case, I had to skip over one meeting that the others were going to because of that it was the only time where we could work together because one person was going to leave the island later that day.

But with that said, I still think working as a group went well when we could work together. When we worked together, we were able to get stuff done and sort things out. We also know what we need to work on during the next week.

Board game progress report (Advanced Game Design) - 20131023

Today, some big progress was made to the development of our board game. Thanks to the work of our group mate Christian Roupé, we now now have a new board that is (hopefully) more balanced than our previous board.

One problem we had with out previous board was that the distance to the search areas were different for each player. But now, the distance should be the same for everyone, meaning that no player has an advantage over each other. Now we just have to play-test the board.