Archive | February 2014

So much confusion

So this week I have been working on the UI. In detail it is the parent meter, parent circles, arrows and indicators. Now I will tell you what things do and how it works. So inside the parent meter you have circles in different colors, they represent parents that are on their way to pick up their children. To know whose child is whose we will have arrows pointing at the child with the same color as the circle, that way you know what child to clean in time. But our map is bigger than the screen which means we need some way to show what part of the map there are on. That is why we have the indicators. The indicator points where the child is and it also have same color as the arrow so you know which one to follow.

All this need to be connected so that you will have a win and lose condition. If the parents come before their children are cleaned you lose. Clean all of the children before the parents come and you will win.

Right now the code is a mess and not fun to look at, so I won’t show you that.

But here is a mockup of the what I am doing right now. the game does not look like this.

Image

We have also had a meeting today with the teacher about how things are going. They thought we were a lot behind and just hiding a lot of problems. That is not simply true, all tough we have had problems, but always have found ways to fix it. We have had some unlucky moments like the pre-alpha, when we had nothing to show because of many bugs. That we fixed until the alpha showing, which prove that a lot of things are fine I can be fixed.

After that meeting we had another meeting with our scrum master he showed us how much time we had left and how much time we are putting down on things until the beta and final game. Seeing this gave us a perspective on what we need to do and how much work we need to put down before the beta and final game. We got some things left, but we have the right structure of the group we can get it done in time. Some parts of the game we might need to cut. Like the upgrade system, hopefully we don’t so we can play around with other “weapons” to clean children with.

 

Anton L-A

Back to programming!

So last week I finished the Design document so this week I got start programming again. So on Monday we had our usual scrum meeting were I chose to do parts of the user interface. In more detail my assignment was doing the health bar, ammo bar and arrows.

Now I began doing the health bar because that was the most important U.I feature to get done before the alpha launch. We needed a health bar that was going to fill up each time you got hit, the health bars real name is dirt meter and it will show the player how dirty he is, when it is filled, you lose the game. But if you aren’t hit it will start regenerate, so there is no health packs needed, the player just need to avoid getting hit. To do this we are covering up the part of the health bar that isn’t used so it looks empty and each time you get hit we show a bit more of it using something called setTextureRect. Imagine an invisible rectangle laying over the texture. The texture rect is useful when you don’t want to display the whole texture, but rather a part of it. By default, the texture rect covers the entire texture. So by doing this we have a dirt meter.

We also needed an ammo meter, kind of. The player doesn’t really lose ammo, the sponge shooter sort of gets overheate. So we just use the same code for the health bar to the ammo bar, the only difference is that the ammo bar goes up when you shoot, if it reaches the top you have to wait for it to go down. So that is how we restrict the player from just keep spamming the shoot button.

I am now working on the arrow U.I. It works like this. The player needs to clean certain kids before their parents come. To show the player what kid he needs to clean we have arrows in different colors showing him where they are. So now that is what I am trying to fix before the alpha testing. It is an important feature and I hope it will go well. The rest of game is starting to shape up. We have now a background that the player can run around in. we still are missing sprites for the kids and animations for both kids and player. Everything is looking really ugly without any proper sprites. Hopefully it will get done soon.

Anton L-AImage

Soon I am done with the Document

This week I have been working on the design document. It is going well and I have put down all my time to it. It will soon be done and my fellow team mates can look at it and give me some response. I have been dealing with the games details. Things that make a game work. A design document is a little like a rulebook. If you follow the document every part of the game from coding to art will be easier to do. Everyone in the team will be on the same page.

This week I wrote about Player, N.P.C’s, player resources, game hazards, critical points, environment and starting with game flow today. Writing the design document I used document we got from Adam Mayes, It had some great guidelines to follow. Some sections of the document we got were a little confusing. I think some of points in document were almost the same. Like some of the play mechanics I also wrote same thing in player resources. It says that I should go into detail of the game interface and how it works. And our health bar and ammo bar is a part of that, but is also a resource that fills up by you having to wait for it to fill up. I guess I could go into more detail but it is not that complicated how it works. Most of what is in the guide template is great and I will probably use it again in other projects I will do.

I also used a design document from a game called Captain Claw. It is one of my favorite games. It has some great ways use a design document. For example how it shows each of its enemies and item. They make these tables, looking like this.

Image

I use these now because they make every enemy so easy to explain. It is also easy for the coders and artist to see what part they need to work on, the now how many frames each animation needs,  how much damage an enemy does, how much health and so on. And it looks nice too.

The Claw document has really helped me and inspired me to make a document.

Meeting, meeting, metting.

So it’s been a long time ago since wrote in this blog. So from Monday to Wednesday we have had four meetings. Monday we had a meeting with Finn Engström, we talked about how to better work in a group together. Not criticizes people based on no facts. Tell them what you think they are doing what you do not like. We should discuss in the group about how the dynamic is and what should change to make it better.

Tuesday we had our second meeting with Elias Lundgren he is our programming help. None of us needed any help, yet. So the meeting was short.

Wednesday we first had a meeting with Adam Mayes. We talked in more detail what we needed to focus on in the Design document. We also talked a little bit what our game was about. He seems to like it. After that we had a meeting with Felicia, she talked if there is something in the course or the project we needed.  We talked about programs we missed for our computers.

Later we worked until 20:00 am, I am starting to get the hang on it, tomorrow we I am going to get the NPC done.

 

A-L-A