We love feedback, it is very helpful and essential for future development of the game. If you’ve played our newest prototype, please feel free to leave us some feedback and tell us about any bugs you’ve encountered!
Hopefully some of you will playtest our game and let us stay in touch with you!
If you are not familiar with Scrap Pirates you can watch the trailer here:
We are going to release a MVP (Minimum Viable Product) at scrappirates.com within this month, so if you don’t want to miss it I suggest you keep an eye on our website or follow us on our social media pages!
I am back for my third year of studying game design & programming!
I have plans on becoming more active with writing posts here, not only for assignments but also other posts regarding games, as for example my work on Scrap Pirates.
The blog has been updated together with my return, so that it is more efficient and nice-looking. And you can now find pretty much all of my social media accounts in the side bar to the left. Huzzah!
With this post is a silly picture of the team I am currently part of. I drew the original sketch on paper, and Jenny made the beautiful final version in Illustrator!
This week was the last week before Gotland Game Conference, and therefore the last week of working on the game for the BGP course.
Most work was focused on fixing bugs and finishing the enemies for the GGC level. A results screen was created, with text constructed from an image and achievements popping up if you have reached certain amounts of stats. The enemies also blink in red when hit, since there was no feedback on this matter before.
A lot of work has been put on polishing and practicing on the presentation that will be held by me for the GGC jury.
This week I worked on another AI, very similar to how the Caterpillar works.
This was however an AI for the enemy called “Incinerator”. It will have a set ground where it can move back and forth, and when a player is close, it will start chasing the player with its furnace hatch open.
Some problems with this AI was that it looked weird when it stopped chasing the player as soon as the player left the incinerator’s set ground, This can be fixed by placing the incinerator on a platform and having the set ground as big as the platform, a better solution might occur later but for now this solution will do.
I have also worked on creating and remembering a presentation for Gotland Game Conference, where our game will be shown.
The second game testing session was held on Friday. Most of the feedback was very positive and people seemed to enjoy the game, the only significant flaw that some playetesters pointed out was that they did not like having enemies in a puzzle game. To solve this, the game might have a setting where you can turn off enemies in the game, but hopefully the enemies will be part of the puzzles/obstacles of the game and so this will not be necessary.
Before the gametesting, I created an AI for a caterpillar enemy that will be part of the game. The artwork/animation is not yet finished, and the placeholder art will not really help in understanding how the AI works, so I will not be posting any pictures of the caterpillar in this post.
The caterpillar will be moving back and forth, and when a player is close it will stop moving and use defense mechanism which is to pop out spikes from its back.
From how it is coded now, the caterpillar will always be moving when not in defense mode, and random float numbers will determine when the caterpillar will change its direction. When players collide with a 2D circle collider, the caterpillar will stop moving and a collider appears on its back. This new collider will give the player damage if they touch. If the player leaves the 2D circle collider, a countdown will happen before it goes back to moving, so that the player does not re-enter the 2D circle collider and the caterpillar suddenly starts moving again. Right now, the caterpillar casts raycasts to its right and left side so that it does not bump into walls, however the caterpillar might later be changed so that it can climb on walls and ceilings as well as the floor.
Otherwise I have just been searching for suitable sound effects for the game.
This week for me has mostly been about creating moving platforms.
Most problems occurring whilst creating the moving platforms were simple mistakes with easy fixes, such as forgetting to create platforms that can go down/left, and not just right/up and able to go back their starting point.
When a moving platform is placed in the game scene, both speed and what distance to move can be set. Then, the script of moving platforms will check if the distance is horizontal/vertical and if the ending position is bigger/smaller than the position the platform is starting from. Whilst the current position is not the ending position, the platform will move towards that position according to the set speed. If the “go both ways”-bool is checked, the platform will start moving back towards its starting position once it has reached the end position.
The biggest problem that occurred whilst creating the moving platforms was that the players slide off horizontal moving platforms. My first attempt to solve this was by detecting the platforms’ change in position when the player was colliding with them, this failed however. How I solved this instead, was by making the platforms the players’ parent in the scene’s game object hierarchy when they are colliding, making the players follow the platforms wherever they move. When they leave the platform, they are no longer children objects of the platform.
During the Alpha game testing a lot of helpful feedback was received. Right now, the biggest problem is with the magnetism not being controllable enough. I am not yet sure of how to solve this problem, but hopefully a solution will be found next week.
One change t that has been made to make the magnetism more controllable is that the player can now adjust the size of the magnetic field. This depends on how much the left or right trigger is pressed, as these buttons return a value between 0.0 and 1.0. The size of the field does not affect the power of the repel-/pullforce at this moment, but it should not be difficult to implement if the team decides on having it that way.
Here, player one is using a red magnetic field to pull/lift an inactive blue box. By being able to decide on what size the field should be, it should be easier to interact with multiple boxes around you, so that the player can choose to only interact with certain boxes.
I will now give a brief explanation on how the magnetism works. When two magnetic objects (for example the player’s magnetic field and the inactive box) collide/meet, their polarity and object type are checked and the correct action is then done (is it repel(same polarity) or pull(different polarities) and what object should repel/pull the other object). The distance and angle between the two objects are then calculated, and if there is a repel interaciton, one of the objects are sent in the opposite direction with the distance multiplied by a set repel force. If there is a pull interaction, one of the objects are sent towards the other object.
Big Game Project is a course for the second year game design students’ at Uppsala University – Campus Gotland. There are three requirements for to get a passing grade in the course; weekly blog posts, a game project and a post mortem report in the end of the course. The game project will be designed and developed in teams of various sizes. In the weekly blog posts I will share some of the work I have been doing for the game project, why I have done things the way I did and how the progress went. I will bring up problems that occurred whilst I was working, and how the problems were solved. Some parts might be difficult to understand if the reader is not familiar with the game engine Unity, programming or games overall, but I will do my best explaining the parts that I find important to know.
I am part of a team called Sprocket. The size of this group is seven people; producer and level designer Jenny Grip, lead designer and level designer Rebecka, system programmer Andrée Henriksson, lead artist Christoffer Svensson, animator and artist Jonna Jarlsson, environmental artist Ida Lahti and me, gameplay and lead programmer, Nicolina Åkerfelt. We have eight weeks to design and develop a vertical slice of a big game. When creating the concept for a big game, we had to show understanding of the complexity of the project with a production plan among other things. All decisions on design must be well thought-through, and the game together with the post mortem should demonstrate what we have learned during our two years of studying game design.
We are creating a game called Scrap Pirates (link to the vertical slice pdf file), a 2D Metroidvania game with 2 player co-op. The playable characters of the game are scrap pirates, looting scrap and other valuable metals to keep their ship afloat. They come across an abandoned terraforming vessel, and by using their magnetic abilities to solve puzzles they can explore this vessel, encountering a lot of scrap and dysfunctional robots on their way.
The game is being developed with the game engine Unity, and USB Xbox 360 controllers will be used for playing the game. It is a local multiplayer, with a shared screen.
Individual tasks – Magnetism
My tasks have so far primarily been focused on creating the magnetism feature, as it is one of the main features of the game. There are two polarities; red and blue, and by combining these force fields different actions can be performed. If two fields of different color touch, the objects who own these fields (for example the players) will be pulled towards each other. When fields of the same color collide, the objects will be pushed away from each other. These two actions, pulling and pushing, can be used for other actions such as jump/move boosts (using push to repel from another object) and hold (using pull to hold onto objects or the other player).
Examples of puzzles using these actions can be found in the vertical slice pdf earlier linked to in this blog post.
There are two different magnet types, inactive objects and active objects. Active objects have their own magnetic field, and these can affect other magnetic objects in their surroundings, whilst the inactive objects can only be manipulated by magnetic fields and not affect any other magnetic objects. The active objects will be static, their main function is to be jump/move boosts and other non-movable objects on the level. The inactive objects on the other hand will be movable, they are mainly used for solving puzzles.
The players are able to switch between polarities and are of the active magnet type, they affect all magnetic objects that their fields collide with. This is done by giving all magnetic game objects a magnetic field trigger collider as their child in the Unity hierarchy. The magnetic fields have their own collision layer, and so when two fields are colliding a trigger message is sent and the magnetism function is called. If all polarities and magnet types are correct (these can both be neutral), the two colliding objects’ polarities are checked and the corresponding action is done (either push or pull).
I might write more about how the magnetisms’ code is working in later posts, but this introduction will do for now.
This week I finished my linked list. I used templates for the data given to the nodes, and so all functions for the list are written in the header file. All methods have been completed and tested, now all that’s left for the linked list to be fully completed is some kind of unit testing.
In class we have been creating a UDP Chat, which also helped us to get ready for our second assignment, which is about writing a web server using bsd sockets API and TCP. The chat might not be completely done yet, but it works, and there could always be things added of course.
The last part of the first assignment (apart from the unit testing) is the binary search tree which I will start working on this weekend. I’ll do my best finishing it as soon as I can, since I’m going to Dreamhack Winter next week, and I also want to start working on the second assignment.