#group formation

Today I was struck with the realisation that my idea can be attached to everyone’s ideas. I hadn’t thought that it was this inclusive, but of course interacting with a physical object to manipulate a virtual world is in essence just another way of saying that I want to make my project interactive.

I am surprised it took me this long to realise that.

However, today I also found out, that almost everyone’s ideas are like this. They are not fully formed concepts at the moment, but rather desires. They know what they want the project to include, but don’t know necessarily what the project itself is going to be.

I talked to Quentin on the train about it today. He is one of the outlier’s, as he likes to come up with a solid idea first before forming a group, as it gives purpose to the group from the get go.

I thought this was a good idea, but I knew that when forming a group, I don’t do it that way, instead I tend to form a group and then work out what we are doing together. Why do I prefer to do this though? It seems more logical to decide upon something beforehand so that everyone is on the same page, and knows that this is the right group for them.

Quentin talked about how other peoples ideas were a bit like clouds, not something solid that you can build on top of, but rather something fluid, and hard to grasp. 

Hearing the word clouds got me into thinking about how stars are created, and then I was struck with a thought. Maybe the way I work in groups could be described like how a star is formed.

Initially, the group is comprised of desires, these are represented by the gasses in the atmosphere. Slowly these desires are condensed, into something more palpable, just like how the gasses are condensed into disks. After many discussions, an idea is formed from everyone’s input, just like how a star is formed after billions of years.

Assignment 3 Progress - Group Formation and Game Development

Week 10 marked the start of Assignment 3. In the workshop this week we formed our groups in which we would be working with in order to complete the tasks.

Our group of 4 Quickly formed and we dubbed ourselves the name: Gravity Gigglers or Group 26 as our official group. With our group formed we then had to choose who's game we wanted to prototype, based off our groups previously completed Assessment 2's. We decided to go with Lachlan's Game: Entropic Collapse due to it's unique application of the physic's mechanic within GDevelop.

During the workshop we also allocated tasks amongst the group and created a detailed play testing timeline so that the assignment would be completed on time and the task load would be spread as evenly as possible.

Entropic Collapse's Sell Sheet:

Entropic Collapse: Game Development

My main role in the group was to design and create the assets and animate the relevant parts.

Background:

The background only needed to be altered slightly over the period of development. The main changes was the alteration of the "star" placement so it would tile neatly within GDevelop and the colours were altered so it would fit the established colour pallet, so the sprites that were used didn't look separate from they world they were being placed in.

Enemies:

Laser Enemy

The first enemy we decided on was a laser enemy. Unfortunately, we decided to remove it from the game due to problems with the code that would fire the laser and being unable to set up a proper system so all the laser enemies wouldn't fire simultaneously. This was an issue because, if they were spread out across the screen, the beams would become an inescapable web of lazers - meaning instant death for players.

Shield Enemy

The shied enemy was originally supposed to be blue when shield was activated. However, when play testing the players were occasionally confused by the colour, assuming that the blue meant it was a friendly vessel, only to learn that it was an enemy when they were destroyed. To fix this issue the shield colour was altered to red, due to red often being associated with enemies or bad units. The playtest held after this change showed that the colour change did solve this issue.

A fire animation was also added to make the unit feel more dynamic and "alive".

Bomber Enemy

The bomb enemy was added to give some diversity to the enemies to make the game feel more interesting. These ships were programmed to chase the player around and explode after a certain period of time, damaging the player if in collision with them. two different flashing speeds were animated to reflect how close the ship was to exploding and damaging the player. When paired with the beeping sound effect, it was an effective visual and audio clue to warn players about the tiny enemy units approach, giving them a hint to dodge before the explosion.

This enemy unit only went under one major change, which was it's size. Originally the bomber enemy was quite small, which made it difficult for players to see it, making it frustrating and not engaging when playing the game. To repair this the sprite was increased in size and the red flashing element was increased in brightness and saturation, which made it much easier to see against the duller planet coloured rubble.

For the same reason and the shield enemy, a fire animation was also added to make the unit feel more dynamic and "alive".

Planets:

The planets used these three sprites and were randomised to create some variety and visual interest. Only slight changes were made in regards to harmonising the colour palette, scaling (if they were too small or too large) and adjusting the shadows and highlights of the sprites.

Asteriod

Created a team last week, where we shared each group member's one page and one sheet. We discussed and agreed that out of the type of games (e.g. platform, asteroids and racing games), we choose to do a platform game. The reason is that asteroids and racing games were limiting whereas the platform type games had more freedom in creativity and interesting mechanics for creation. In the end, we decided that Shadowy Friend was the best choice. As it had distinctive mechanics and design that shown potential and deemed possible to construct for a group project. See below of team member's one sheet and one page:

Assignment 3 is going well! I've got a group that seems motivated, and have been assigned things that I'm good at working on. I'm working on Terran Defenders, Evie C's game. This week, I've been trying to a variation of attacks working, as well as a basic level up system.

So far, I've got a tri shot implemented, as well as a melee attack, and another member has a laser beam attack, and shockwave.

In order to balance some of these attacks, the amount of damage that they do has been reduced. For example, the tri shot beam has the damage per bullet reduced by 20%. With the laser attack, the cool down for the time it takes for enemies to take damage is reduced, so it feels more like a true laser rather than an occasional tick of damage.

I'm encountering a similar issue that I had with my asteroids prototype in regards to the leveling up system in which text boxes seem to not disappear after I've hidden them.

Group formation was not as smooth sailing as I would have hoped.

At the start I reached out to Gabe (click the name to go to their blogs) who said he had another person. We were then joined by Peter when asking around. For Assignment 2 both Gabe and Peter had made platformers their focus, so it was easy to do what everyone was passionate about.

This was to be the team for part A with Peter doing the level designs, Gabe and I doing the implementation of mechanics and the level creations respectively, and the other person Gabe had as the artist.

But there was immense difficulty contacting the other person Gabe had, so after a week before handing in part A, we moved on without them and replaced them with Christian who didn't have a group yet.

After forming our team in the workshop, we decided to go with my teammate's game idea instead of mine. Although it wasn't my concept, I am pleased with the decision, impressed by her work, and excited to enhance it together after brainstorming our ideas.

Our team initially discussed how to improve the chosen idea. Rather than just collecting logs scattered around the map, we decided to transform the game into a short story with an interesting plot.

Game Storyline:

Currently, the plan is to create a plot where Tigress, the main protagonist, receives news that her hometown, the forest, is under attack. She rushes back as quickly as possible, only to find her mentor, Master Kai, injured while attempting to evacuate the citizens. Master Kai briefs Tigress on the situation and reveals who he suspects is the mastermind behind the attack. Although Tigress is shocked by the revelation, she understands her duty and decides to pursue the mastermind while simultaneously saving the forest by reviving the scattered logs.

Group Formation:

Jorja [Leader]: Programmer, Sprite Artist and Level Designer Giveson: Storywriter, Programmer and Level Designer Willow: Sprite Artist and Level Designer Mila: Main Artist

Team Discussion:

After assigning responsibilities to each member, we used Trello to allocate tasks. Our current priority is to create the levels we've discussed: the tutorial, the tree reviving stage, and the final chasing stage. Following that, we'll focus on the aesthetics, including an animated main menu scene and an ending scene. Main Menu Prototype:

Drawn by Mila