Categories

Sunday 14 December 2014

Bomberman Begins

Too be honest, I have really been slacking this week (and a big part of my classmates have too). Maybe it is because it is soon Christmas. Maybe it is tiredness from the game-jam we had, combined with the hobbit movie marathon and a lot of alumni guest lectures that took up our time. We have at least done something this week. We put together functionality for images other than Bitmap files for our games projects, which really just was to include another library called SDL_image that goes well with the rest of the SDL library, it was pretty much included the same way as SDL was. Also we learned how to output text onto the screen in our game windows which we did with, you've guessed it, yet another library not included in the original SDL. This was a bit more interesting though since we had to transform letters from a font into a picture to draw on the screen.

We have at least started on our final work for the course, which will be to create a clone of  a classical game, in which I chose Bomberman. Joakim Ädel joined my project, so hopefully we will get more done than we could individually. I have started working on automatic random map generation and put the pieces of our old projects together into a base to create the Bomberman clone from. I've also looked slightly into git, which really seems like a lovely software that I wished I had learned and used way earlier. Git is basically a program which you use to keep track of different version of a project. The power of git though compared to like Dropbox or any other version controlled storage is that you can have a "branch" for every new feature to implement in the code. This allows you to work on multiple features at the same time. For instance I might have a branch for trying to fix a specific bug and a branch for adding a new feature. Both of those two branches are connected to the latest official version of the project, When I get done with a branch, that is to say when I have succeeded to implement the bug fix or a new feature, I can make the finished branch into the "master", which basically means making the branch the official latest version of the project. When I get done with the other bug or feature branch I can then merge this new branch with the master. And it is here the magical witchcraft is going on, because here the bug fix and the new feature becomes one. The smart thing about git is that it only saves the changes of the content of files so it is possible for a file to be edited in two or more branches simultaneously, the only times there will be a conflict (if I have understood it right) is if the same parts in a file is being changed in both branches differently. Then that part must be manually merged, which in code means making that piece of code work for both branches. This also allows for many people to work on individual branches with individual problems. People can even work on the same problem but different parts of it (a branching in a branch). Or just compete for having the best solution to a problem. It is also easy to go back to an older version, and since every new version is described by the changes that was made to it,  it is easy to know what happened and when.

I am very excited to make my own game in C++ out of the things I know and the ideas I have. It is actually what I came here for, to be able to create games, to be able to create great interactive experiences for other people. So it shouldn't be hard for me to keep motivated. From now on I'll program and learn as much as I possibly can, because in the end, the amount of effort I put in now will determine how good the chances are for me to follow my dreams. And honestly, what I am doing right now is actually a part of that dream, and probably it is also a part of the dream that a lot of people in my class have. So there is really no reason for us to not give it all we can.


Saturday 6 December 2014

Weak four (on my part)

This week has been purely about how to use the SDL library and about dividing things into appropriate classes as a foundation of games. That means we have one class for starting everything, one class for drawing everything on the screen, one class for handling states, etc... We learned to handle input from mouse and keyboard, we learned how to make a core loop of clearing screen drawing screen and presenting screen and lastly we larned about states, which was pretty confusing. We (a bunch of students) have planned to go through the code we have got on the lectures and try to explain it line by line for each others until we get it.

I like this week because it has been the first to introduce me to mostly, for me, new material.

This week has been extra slow because of some complementary work in other courses and because of the preparations for the game jam on the weekend.

I could probably have done better somehow.

Next week I'll try to analyse my time better so that I know how to improve.

Now GAME JAM!