Scrap Pirates – GGC-results, kind of

So, GGC is over. No prize, but Scrap Pirates were nominated over half of the categorize we could be nominated for. Nominated meaning we were in the top five.

Even if we did not win anything we are still content with the conference and we think we will continue working on it again after the summer and a well needed vacation.

Have a good summer, everyone!

Scrap Pirates: In the middle of GGC

So, we are in the middle of GGC, Gotland Game Conference. Well, maybe not in the middle, more like the two thirds through, only one more day out of three. We are showing of Scrap Pirates and a lot of people seem to like it. Tomorrow is the last day, which means that the deadline for voting and the following award ceremony will be held. I would be really happy if we were to win some award for Scrap Pirates because we have all worked so hard to make it as good as we could during this limited time that we had. But even if we don’t I will not feel let down or anything, there is a lot of hard competition this year and a lot of games deserves awards. It is so hard to say which game will win what award and I am sure that it will be a close run in all categories in this year’s GGC.

I will give you all an update on how it went when it is all over 🙂

The two players and one of our enemies, the Caterpillar, in its defensive stance.

Week 7: Scrap Pirates, one week left before GGC!

Hello! Week 7 has just passed and Gotland Game Conference is in just one week. A couple of weeks back we decided to cut back on a couple of features like upgrade system, some enemies, multiple levels, among other things, and I feel like that was a good decision because otherwise we would be up to our necks in half-done things and nothing would probably feel finished for GGC.

As I mentioned the last time I had one bigger problem to try and solve, it was the parallaxing windows into other rooms. After a lot of testing with placeholder graphics and a lot of discussions we have decided to put those parallexes on hold until after GGC because of two reasons: first, the graphical artists are already up to their necks with stuff to get done before the conference, and secondly because it does not feel good with our placeholder graphics. I think that the programming part of the parallexes is done, only variable changes so they scroll the right speed, but it is hard to test without the right textures to test with. Anyway, as I said, we have put those windows on ice and will just keep us to scrolling space parallexes instead.

So, what do I have left to do this week? I will need to make a couple of different TriggerZones for different actions. One of them will be that when a player enters it, it will light the lamps in the room and remove the shadowsprite over time. Another zone will be that when both players have entered it, it will close the doors behind. I do not foresee any difficulty in making those two scripts. I will also implement a highscore list so that those that come and test our game at GGC can compete with each other trying to get as high as possible. I have not done a save system before, but I do not think it will be so hard, should be plenty of guides out there.

Other than that, I only think it is bug-fixes and polishing left for my part.

I hope I will see you guys at GGC this year! (Free entrance for the public on Monday and Tuesday!)

Third Artifact: Pathfinding and Grid building

This week I will talk a bit about our pathfinding. (Warning: Confusing)

There are a couple of different pathfinding algorithms out there, on the internet. There are Breath-first, Best-first, Dijkstra, A*(A-star), etc. Almost everyone, on different forums, suggest A* as pathfinding algorithm for most games. It is reasonable fast in most instances, even though some of the others were quicker in some scenarios.
A*, like most other algorithms, needs a tile based system to search through.
Each Tile, or Cell, is given three values: F, G and H.

• G is the cost to move from the starting Cell to this cell.
• H is the guessed cost to move from this Cell to the goal, as if there was no collision in between.
• F is the sum of G and H. (G + H), the approximated cost to move from start to finish through that cell.

Each cell also holds a pointer that points to its “parent”, which is the cell that put the active cell on the open list.

It uses three lists to store cells in: Open, Closed and Final.

• In Closed all the checked cells are stored, so we don’t check the same cell more than once.
• In Open all the cells still to check are stored.
• In Final we store the final path, when we have found our goal. We get the path by backtracking from the goal and go through all the “parent” cells until we are at the first cell.

Each iteration of the algorithm takes the cell with the lowest F-value in the Open list, and puts it on the Closed list. Then it checks all the surrounding cells that is not already on the Closed list and gives them values. It one of the cells is already on the Open list, it checks if the new F-value is smaller than the last. If it is, it changes the parent of that cell so it points to the new, cheaper, parent.

When the goal cell is finally found in the Open list, we backtrack from there. Going from parent to parent, storing each cell and when we are back at the start cell we have the shortest path.

The picture shows an example of A*. The Green tile is Start, Red is Goal, Gray are walls, Blue is on Closed list, Green on Open list and the yellow line shows the path we got at the end.

 

Unlike the other Escape-concept groups, we chose not to have tile based. The reason for this is that we felt that tiles are too limiting when it comes to placement of walls and furniture’s. We wished to have more freedom, to rotate and place assets “however” we wanted, to give each room a unique feel.

Because of this I had to simulate a grid to use A*, otherwise, each pixel had to represent the tiles, and that would be too many squares to search through. The grid is stored in:

• std::vector<std::vector<bool>>

Which is vectors in vector. The outer vector is the tiles Y-position and the inner its X-position.

Instead I divided the map into equal sized squares and checked each square for collision. If collision was detected I put its bool-value to false, otherwise true.

Then, to see if the grid worked I drew the grid on top of the level ingame, and each walkable tile was colored red and the unwalkable teal.

As the picture shows, it looks like it is working.

I hope I made myself clear, but I’m afraid that would be really wishful thinking…