Poly Smash @tc452by2 - Tumblr Blog

Evaluation

Media and Techniques

I have learnt a lot during this project, the main area that I have improved on is my ability to collaborate with others. I have learnt how to communicate efficiently with my team to share ideas and share my progress in the project. I have also explored different websites like Miro which helped with generating ideas as well as improving my planning skills.

Another area that I have improved on is my understanding of user experience and user interface (UX/UI). Although I didn’t have time to focus on the user experience, we did however get time to create the user interface. I also started making use of physical tools like a notebook and posting notes throughout the whole project to sketch ideas for the Level, UI and just for general notes.

Purpose/Theme/Concepts

I found that working in a team is a lot better than working solo because it allows me to concentrate on my specialist areas whereas not having a team means I have to be more generalised. I found that our idea generation was better because we would discuss each idea we had which helped with deciding on which ideas were good and which were not good, whereas alone I wouldn’t discuss these ideas with anyone leading to some ideas being implemented and wasting time that could have been spent on ideas that were good.

I think working as a team was definitely the right choice since it allows for a second opinion and voice on everything. This made problem solving a lot easier since if one of us had an issue we could discuss it and a solution would arise quickly. This meant that we wouldn’t fall behind on our targets.

Outcome

At the start of the project I didn’t think that the outcome would be as good as it turned out to be due to the short time frame and it being the first time I worked collaboratively. I believe that the outcome meets the majority of the project proposal. The only thing that wasn’t met in the proposal was a points system and stun ability but everything else was met.

Conclusion

I think the state that the game is in after just four weeks is very impressive and I am really happy with how it has turned out. I believe that if we were to have an extra two weeks on the project then we could have gotten it into a completely playable game demo. One thing that I think I could have done that would have made the outcome much better would have been if I focused on the more core mechanics of the game, especially the score system as that is the only thing that is preventing the game from being played competitively. I found working with Tyler really fun and we worked really well together. I would be happy to work with him or others in future projects since it makes the process more enjoyable and also very productive.

The feedback we received from the game testers was mostly positive and all the negative feedback would really help improve the game if we were to continue it. The main thing that was mentioned was that people were very confused on what to do. Which could have been avoided if a points system was implemented as well as a quick explanation on what to do. Something that I will think about in future play tests is making the game automatically restart after the play test has finished. The testers said that they really liked the animations and the destruction of the environment. Some even mention that they found it satisfying to destroy the environment, which is great because that's what we wanted them to feel.

To end, I am really pleased with the progress we made in these four weeks and I am more comfortable with the idea of working collaboratively in the future. I have learnt a lot during this project and I will take everything I have learnt into my future projects.

Posting the Project on Itch

Packaging the game:

I tried to package the game while at home but it kept crashing so I waited till I was back in college where I asked Tyler to package it and upload it to itch.

So I started working on the Itch page getting it ready to post to the 2By2 game jam page.

Creating the Itch page:

Filling in the details:

Short Description:

The short description explains that the game is two player and that they will casually compete against each other in a low poly art style environment.

Description:

The description expands the short description by explaining how the players will be competing. While also evolving the art style's description by mentioning the colours hidden behind darkness.

Message to Play Tester:

I made a section to let anyone who played the game know the current state the game is in and any major things that are not working or are bugged.

I also added a link to the form for them to fill out when they have played it to provide us with feedback.

I also made note of the controls in a table so that people can look at it if they doesn't know how to do something.

Adding the games screenshots and cover image:

I had to create a smaller version of the cover image because the one I was working on was to large to upload here.

I also added the cover image to the screenshots because when you have screenshots the cover image is removed from the page.

Uploading the game:

Tyler uploaded the game onto Itch.

The Finished Itch Page:

I'm really happy with how the page looks

I have updated it so that the title is centred and I also added the story to the about tab.

Creating The Games Cover Art/Icon and Itch Assets

We needed a cover art piece to put onto our itch page. So I sketched down an idea where the astronaut will be facing forward and there would be colourful cracks in their visor. Representing the destructible objects in our game and that they break into these shards.

I took a screenshot of the character in engine that I then cropped out and used to create a rough example, which is why the astronaut is really low quality and very upscaled. I then added cracks using the line tool and gave them a slight glow.

I adjusted the colour a little bit and make it more vibrant because I felt that it wasn't prominent enough in the image.

I then thought about another idea where the astronaut head was broken up in pieces just like our games destruction.

So I watched a video about how to create voronoi designs in Photoshop since this is the same design used in creating the shards in chaos destruction.

To create this design I had to add noise at above 100%.

Then I needed to use crystalize (found within filter and pixelate) which then produces the same effect as a voronoi diagram.

While working on getting this right I asked Tyler to render a better image of the astronaut facing forward so it would be better quality.

After I had this design I used the magic wand tool and selected each section and then switched to the other helmet layer and copied and pasted so that I would get a copy of each section that I could then sperate.

I then added a drop shadow to each piece to give them some depth and make them look more like the chaos destruction from our game.

Tyler and I compared these two and decided that the old style with the crack just in the visor was visually clearer and less confusing. So I decided make a mix of the two by merging the shards with the original style.

When comparing this to the first design with the second and third, Tyler and I agreed that the old design was better so I decided to go back and improve the previous design. Although I do really like the effect that this design has and has potential to be used in the future on a different project.

I moved the crack to make it look like the origin of it was where the sun reflection is and I also made the crack fade into darkness just like the helmet, helping it to blend together better. I also scaled it up and made the crack lines thicker as before they didn't match the scale of the helmet.

Instead of using this technique for the helmet I decided to use the voronoi technique to create the background to the itch page. All that I did differently was that I used monochromatic noise so there wasn't any colour.

The idea was to try create a low poly space with stars using this technique. However I was struggling to make it look like stars but I ended up with something I liked the look off.

Feedback

We all went around the room play testing each others games. Which means that we have received a good amount of feedback.

Most of the testers provided us with some good dislikes. The common theme between each of them is that they were confused and not sure what to do. We expected this to be the case because we haven't prioritised the user experience rather we have focused on making mechanics and artistic things. What we could do to make the game more understandable is implement a tutorial or a controls screen.

Most responses to this question talk about them liking the animations, and the visual style of the game. We put a lot of work into these things so we expected to see these responses.

Half of the testers didn't encounter any bugs but the other half mentioned that the camera was slow, movement felt weird, and their was a weird fading at the back of the map. The camera moves really slowly because we didn't adjust the speed of the camera when the player gets really far away. What's meant to happen is the further the character gets the fast the camera moves back. The weird fading at the map was in an area where the player shouldn't be able to get to in the future. To deal with this we can add some invisible walls or something that blocks the player from going that far.

Most of the testers found the camera movement to be very smooth and slow. To make it better we can just increase the speed. One of them mentioned that they couldn't see where they were behind the dome. We did have something but we accidentally disabled it when we built the game. We had a widget above each character that we planned to make always visible through walls so the player can always know where they are.

Half the players didn't fall of the map so they didn't experience the respawn system. The other half found it was either good or a little slow. What we can do is speed it up a little and also we could have a setting for those who want it to just teleport the camera back.

All the testers found the cubes destruction good and some found it satisfying. Although one felt that they broke too easily. We could make them heavier so that the broken shards don't fly as far.

Half of the testers found the swing mechanic somewhat responsive. To make it more responsive we could add some audio to help blend the animation and the hit together.

All the testers found the animations very good but some found them good but not very visible.

Most of the testers liked the style of the map. But almost all of them commented on how empty the map was. We expected this response because we had only planned the map and didn't grey-box it.

All the testers wanted the points system to be based on destroying the blocks. One suggested to have a collectable that the players have to hold onto but could steal from each other. This would make the game even more competitive and could be worked to have some sort of risk and reward.

Most of the testers mentioned some things we could add but some of these things we already planned for. One suggested that we could make it so the players could hit each other to launch them away.

Most of the testers found the game confusing.

This one was more of a joke and not a serious part of the game. But 87.5% of the testers saw Maxwell the cat.

This was some really good feedback from the play test. In future project it would be very beneficial if I got people to test each week or two.

Quit Button In Game

Quits game if button is pressed

Remove from parent will remove the widget from the game if button pressed again.

Working on the slam attack and a collision check

Code (node before do once is a custom event (Slam Attack) which is activated on right click)

I was in the process of working on the slam attack when we ran out of time on the project. So it never got to a working state. Although I still want to explain what I was doing.

For the slam attack I needed it to stun the other player as well as destroy any blocks in a close proximity of the slam.

I set up a cooldown for this ability by using the do once node and a delay that will reset the do once. I then created a custom event 'Player Collision Check' that I wanted to use to check if the collision box had collided with the other character.

It doesn't work because I ran out of time on the project and couldn't continue work it. This meant that the code was incomplete and wasn't usable.

However the code that I have got for this mechanic does work how it suppose to.

Starting Door

Created a model using cubes to prototype the mechanics (so if we decide not to use this mechanics then time hasn't been spent on creating/designing the model)

I have added some text above to let the play testers know what to do.

Explaining the code:

All the code for this:

This code is designed so when two players touch their correct colour on the door then it will open. But if they touch the wrong one or don't touch it at the same time then it will not open and they will have to try again.

I have separated the code into 4 sections so that the nodes are readable.

1: This is the starting section where the event "ActorBeginOverlap" is. This connects to a sequence that breaks into three paths. The first path leads to the player one code and the second leads to the player two code and the third leads to a branch that only outputs true if the variable "Number of players at door" is set to two. If true then it will play a timeline "move" which is then connected to a set world location and also sets the alpha of a lerp (vector) that is also connected to this set world location. This lerp is set to A (Actor Location) and B (NewPos).

This means that when both players are at the door it will play the move timeline that will change the alpha of the lerp which will move the door from A to B. Once the timeline is complete it deletes the actor.

A: To check what player has overlapped the specified colision box I used a component overlap actors node which is being set to the player 2 colision box and then is filtered to the player two character then this goes into a branch which if set to true will add 1 to the number of players at the door. If false will check if it was the other player and do nothing.

B: To make it clear to the player that they have touched the correct one, the material gets set to green (says orange but suppose to have been green) it then adds 1 to the number of players at the door variable and starts a 4 second delay which then sets the number of players at the door to 0 so that if the player walks away then the other player can't open the door while they are far away. Once this is all finished there is another delay for 1 second that sets the material back to red.

C: When the wrong player has touched the door then it will change the material to orange to tell the player that its the wrong door. Then using the same code to work out when player 1 touched the door It checks if player 2 touched the door. If true then it will set the material to orange and delay for 1 second before changing back to red.

The code is then almost identical below apart from the player specific nodes being changed to the correct player.

Doors are coloured to correspond with each player's colour:

Door goes green when the correct player touches it:

Door goes orange if the wrong player touches it:

HUD Design Sketches:

Here we were exploring how we wanted the HUD to work. This was when the split screen was going to be horizontal but we later changed it to be vertical.

In page I sketches a very basic example of an idea for how the HUD would be positioned.

Tyler and I then worked on another idea which was based of the previous. In this we added ability cool downs and the points bar along the split screen line.

In this next page we explored a new idea for the points bar and also how we want to display the abilities.

We then created a new design which fit more to the style of our game. In this one we changed the sharp angled timer and points bar to a hanging clock and a pipe with a window revealing the point level.

We ended up settling on this design and Tyler went Illustrator to create this to put into the game.

Animation Idea Sketches:

Here I made explored a couple ideas for how the animations could look like.

Level Design Sketches

These post its have sketches exploring different ideas that I had for the map design. Some of them are unrelated.

On this page I explored an idea of the how the player vs player working with the maps. Where each player would have a dome that they would go around. We decided against that because we wanted the players to interact with each other trying to steal or sabotage from them. I also explored how the tiling of the dome would look like and we decided on hexagonal tiles since they fit together well.

In this page I am exploring how the maps layout within the dome. I also explored ideas for what A.R.K stands for.

In this page I am exploring the design of the sci-fi themed ark colony ship. I also made note of a acronym for the dome.

In this page I am exploring the top down layout of the map. The border that surrounds will be where the player is not able to traverse past. This will be disguised rather than an invisible wall.

I'm really happy with these sketches of the map. If we had more time on this project then it would have been added.

Timer Low Warning

Explain what I need.

first version:

For this version I brute forced a solution to this task. I individually selected each number at linked it to either A or B. Bad becasue it wasn't easily ajustable.

Second version:

This version was very similar since I again selected each number but this time I linked it to one of two lerps. The first set to 1.0 and the second set to 0.0. It then took the lerp and set the alpha between A and B. A = White, B = Red. This was bad because it still required me to select each number that I wanted to be represented by each colour and having it controlled by lerps didn't make anything easier.

The new way

This third way is much better since it is more flexable and allows me to change things much easilier.

If the minues are 0 and the seconds are les than or equal to the timer alert then it will continue, if not it will set the clock background to red

Modulo

Talk about the maths to find out if its even or odd

BG when Odd Number

BG when Even Number below 15 (the set timer warning)

Launch Ability

I have created the ability for the player to launch into the air causing the blocks around them to explode.

To do this I create a custom event that I can then call upon later. I used a launch character node and set the velocity to use the actors forward vector and multiply it. Doing this means that the player will get launched forward rather than just upwards.

Then using the add force event spawned in the destruction field around the players legs. This made it so that the cubes surrounding the player would get destroyed making the launch look more powerful.

I created a new input using the new input system and used a branch that will output false when the player isn't falling. I then used a do once so that I could add a cooldown to the ability using a delay. I then used the Launch Attack event to run the code above.

Now when the player presses Spacebar or A button they will launch into the air.

Coming up with the story for the game

Production:

For the game we wanted to come up with a story to explain why the players are destroying their environment.

The text highlighted in yellow is the story I ended up with:

Reflect:

I think this explains why the players need to destroy the environment and also why there is a timer. This story isn't in depth and will probably get expanded later so it explains things in more detail. But for now this will help use with designing the world.

Improving the Organization of Our Ideas

I have sorted each colour to be related to the each part of the development. I have also added a gold star for the most important ideas and a red circle for not wanted ideas.

Level Design Research

Research:

Colour Pallets

Model Ideas

Visual Montage

I have started researching the design of the first level. Tyler and I have decided on the first level being set on mars or a similarly design planet. So I have collected a group of images that are portray our ideas for the the level. I am going to use these to help with the design of the level.

Week 1 Reflection

This first week has been really successful we have created our games idea and I have got created the prototypes for the swing and slam mechanic. Tyler has create the camera lag and tilt shift effect aswell as planning the design of the hammer.

However, we didn't complete the character or the level design so these have been moved over to the next week on the agena and are high priority.

Small Tweaks

I made two small tweaks to the game. The first one is that I made the player's acceleration be quicker so there is less of a wait until the player is moving at max speed. This made the movement feel more fluent and made me feel like I had more control over the character.

The other tweak was that I shrunk the size of swing mechanics destruction field. I did this because I was able to destroy cubes that were too high up. This meant that towers could now actually fall instead of just completely breaking.

Trending Blogs

Recently Viewed Blogs

Poly Smash