chey-dev-blog

[chey-dev-blog]

Rock Paper Thomas: Week 14 - Dev Log

To be entirely honest since the last Dev-log check in, things have been a bit of a mess. Almost all of us have been out of communication with each other, haven't updated any of our task lists and have hardly touch the project due to other projects. We agreed it’d be okay if the project took a backseat for a little bit while we all work on other assignments and that we’d work on it on our own time when we have it available. What this resulted in was minimal communication and half-finished updates to our project that left it in an workable condition for others for about a solid week and a half. We’ve all been contributing here and there, and admittedly I’ve probably done the least work since, mostly due to not knowing particularly what to work on (we never distributed tasks beyond the attacks and movements), and not knowing how to work on the project without screwing with something that someone else was working on. For the most part I’ve only edited the maps that Thomas made to allow for character maneuverability (adjusting platform positions, gap distances, etc.), added background art, and tweaked certain values in the characters movements (speed, mass, jump height, etc.)  I don’t think anyone is to blame what so ever but the amount of coursework and stress we have is definitely a big reason why our organization has been lost.

We managed to implement UI, Michael made custom animations and redid artwork for all 3 states (Rock, Paper, Scissors). We created 2 additional maps for a total of 3, with artwork/aesthetic (albeit simple). We added cool downs to abilities and switching states. We had a functional title screen that worked like a lobby for the 4 players, and we tightened and tweaked player movement and attacks to balance out. All of this was done in about 3 days instead of over the 2 weeks we had.

We managed to get the main priority things done in the last few days before the deadline to submit the project, but it was very stressful and that stress really affect our synergy. We did manage to come together and start working but when conflicts arose, we were far more, impatient and aggressive about our opinions on how the game should turn out and what changes should be made. I personally flipped out at Dave about twice for making changes in the rock attack without discussing with me or the group, and we argued frequently about how things should be done. What he had changed was that the attack no longer added velocity to the character, and could only apply damage when the floor was collided with, resulting in the character losing all mobility and offense in the air. It could only travel in a short upward arch that restricted its area to about 2 character spaces in front of it.  Instead of discussing with him or others, I reverted the changes back to the original design in an aggressive and executive decision. We also had conflict about map design, aesthetic and effect, but this we managed to resolve with less fighting. We settled on a “Notebook sketches” theme that corresponded with the sketch-like aesthetic of our characters. I brought up an argument that a ferris wheel drawing was stupid because the ferris wheel wouldn't move and only the carriages would which would look ridiculous. Frankly this argument was trivial and no one cared but me so I just conceded and drew that damn ferris wheel. It doesn't even look half bad either, which I was absolutely salty about.

As far as the prototype ended up, I think it was a success albeit not impressive. We never got around to Implementing item pick ups but it doesn't feel like a loss at all. Dave and Richard made custom audio for the game which I don't think suited the game what so ever, but individually as tracks they do sound good. They’ve been the most experienced with audio software and have made good songs as a hobby before, but given more time I think it could have done much better. It really makes me appreciate good video game music more haha. The Combat in game worked well and offered the variance in play style like we intended. The varying movement abilities gave me more options than just switching my characters to evade or go in for attack, and ultimately i had to stay just as much on my toes while playing than when we made the proof of concept.

The only thing we could really improve on is audio, art and more interesting map designs, but outside of that our characters and their abilities work just as well as we’d ever intend them to.

 The positive thing I learned from this experience is that we are all really good friends and can handle confrontation. They don’t simply concede when presented with ideas and they don't dictate their own ideas either. As they say, Friction smooths the grain. We could argue in the classroom for a solid hour and hate each other's guts, but the second we left the room, any animosity between us disappeared. I find this quality really desirable in my future teammates and I would love to work with Dave, Thomas, Richard and Michael again.

[chey-dev-blog]

Rock Paper Thomas: Week 11 - Dev Log

In week 11 of Development of Rock Paper Thomas, We’re fairly on track with what we promised to have done. Currently our characters have different working move sets and attack abilities, but we’ve made some changes from what we originally planned. The Paper state is able to glide when in air and “shreds” particles underneath it like we originally planned. Currently the particles don't damage anyone but the effect looks nice at least. Scissors can double jump and instead of doing a slow moving projectile, we’ve decided to keep the dash attack ability but only for scissors. This is because our planning did not take into consideration how maneuverable we’ve made scissors, while rock (Scissors counter) is pretty much un-maneuverable. If the rock state can’t dispose of the scissors state then our game is kind of broken. I was responsible for doing rocks attack and movement this week. So far, attacking in the rock state launches the character forward and upon collision with the ground, wall or a character, particles instantiate. As with paper, currently these particles don't do anything, but it does look super neat!

 The way I currently have Rocks attack setup is that when the attack button is pressed, the movement script on the character, that allows input to move the character, is disabled. This is to stop the player from adding additional velocity to the character during the attack, and also because there are a few lines of code in the movement script that stop characters from travelling past certain speeds which stopped the attack from working (it had travel upwards fast and downwards faster). Michael rather I didn’t mess with his script too much, so I saw fit to just disable it while character was attacking. I set a Boolean (isAttacking)  to true when the attack was triggered, and set it to false when the character collided with something. The character is launched in an up and forward direction, depending on where they are facing, by adding to their current velocity so that if they are moving or jumping, this attack may go further or higher. While isAttacking is set to true, the script checks for a moment when the characters upward velocity is close to 0 (-1<y && y<1). When this condition is met, then (while isAttacking is still true) the gravity on the character will increase so that it plummets to the ground.

Once the object has made contact with something, I Play a particle effect that sends projectiles in a small radius around the character and set isAttacking is set to false, which re-enables the movement script on the character. This attack as of the moment can cover a pretty good distance (which is subject to change and most likely will be), so we’ve decided to scrap the rolling boulder ability that we planned, as it seems redundant and pointless. We debated quite a bit about the revisions/subtractions to rock and scissors movement and attacks. Scissors was almost a unanimous decision to revise but rocks revision was heated, but ultimately we agreed it made sense to scrap the boulder roll ability. I mean it's just kind of something a rock can do but not something that will relatively add to the game play anyway. We haven't even gotten our map designs started so getting to test and implement that movement ability without knowing what obstacles the ability would be used for would be kind of futile. Next on my to-do list is figuring out how to send collision messages with particles so that the projectiles can actually damage other players (specifically in the paper state). I’m a little pressed for time with other assignments so I might ask someone else to do that for me if I can't get around to it, but so far we’re keeping relatively on track with our schedule! I hope we can keep up the momentum. 

[chey-dev-blog]

Rock Paper Thomas : Week 9 - Dev Log

We’ve decided to build Rock Paper Thomas into a prototype! In Week 9 of development we laid out a lot ahead of us in terms of planning and development for Rock Paper Thomas’s Prototype. From our original proof of concept, which featured a simple dash attack for all characters regardless of state (Rock, Paper or Scissors), we’ve decided to move forward with custom attacks and movements for all 3 states. This would allow players to have variance in play style we hope. Honestly I think the beauty of our game at the moment comes from its simplicity and having the same movement and attack set for all characters is automatically balanced, fast paced and fun, but risks are worth venturing. Honestly I think I’m hesitant to change things that I know already work, so despite being uncomfortable with what we’re planning, I think this is good for my development as a game designer. In terms of Character state abilities these are the things we’ve decided to add:

Rock State:

Movement:  Heavy and sluggish movement, Higher mass.

An Ability to Roll forward as a boulder to speed up and traverse obstacles

Attack: A lob of the character itself, turning it into a projectile that damages Players on impact

Paper State:

Movement: Light and floaty movement with a Low mass and average speed. 

An ability to Glide like a paper airplane

Attack: A Paper shred attack that propels the character upward while emitting damaging paper particles underneath it

Scissors State:

Movement: Average Mass and slightly higher speed.

An ability to double jump and dash/dodge

Attack: Emission of a large slow moving Projectile that damages players that get caught in it.

We also plan to improve our map design and add an additional 2 maps (if we have the time) to explore different concepts. For example, we hope that having tightly closed spaces versus open spaces would encourage different play styles. Recently I’ve found Towerfall to be a really good example of how tightly enclosed spaces can force intense battles between players, so personally I'm hoping that is the direction our map design takes. Along the same train of thought, Item pick ups are something we think would be interesting to add to the game as well. Our system, where if you take damage then you're instantly out of the round, is kind of hard to design items around without going to the predictably safe decisions, like shields that make you impervious to damage, or projectile weapons that kill any character regardless of state. In this, I'm kind of hesitant of going with doing something obvious, but at the same time they should work effectively for decent pick ups. It can be iffy rejecting something workable for something simply unique instead, but honestly this should be something our team should decide together.

Currently we have a schedule laid out in front of us for the updates to Rock Paper Thomas:

In 1 week: we should have character movements functional and have the player controls tuned.

In 2 weeks: we should have player attacks and abilities implemented and balanced out.

In 3 weeks: we should implement 1-3 new maps with items in play

In 4 weeks: we should create new art assets and animations for our characters

In 5 weeks: we should take the time review our current build, add juice, sound effects and update UI  

The schedule seems pretty doable in its current state and I hope we can stay on top of it the best we can , but with other assignments taking up time, and 3 of our members having a part-time job, I’m guessing we’re gonna cut some things.

[chey-dev-blog]

Don’t Drunk n Drive- Log and Analysis

LOG: 

Don’t Drunk n Drive is a concept racing gaming taking place in a futuristic city. Up to 4 players can pilot hover bikes while “intoxicated”, causing adverse effects while driving like blurred vision, spins and shakes.  As players race through the track, they can pick up beer bottles that increase their speed greatly, but also make driving/steering  more difficult, as the adverse effects happen more frequently . 

For this project Michael, Thomas, Dave, Richard and I all split up and delegated tasks. Given a week it turned out AMAZING. Richard and I were responsible for implementing effects on the player. We worked on creating a spins effect which rotated the camera upward off the road and returned it.  We made a screen shake on impact and we implemented the increase speed and random variance in control sensitivity on collision with a beer bottle. Michael was responsible for implementing our effects in game and incrementing how drunk a player got (increasing the effects). Dave made the movement script which moved the bike like a proper motorcycle and kept it grounded and Thomas made the whole level layout which had cool twists and pipes and a cool floating city aesthetic.

We had a few issues with parenting and camera position/rotation throughout the development. Itween has this terrible habit of not updating the camera position/rotation during its tweens, and this is where most of our effects came from. The camera shake, and spins had to be rewritten a few times as they messed with repositioning the camera, making it impossible to steer.  We mostly fixed these by creating time functions which increased a value over a few seconds to get the desired effect.

Analysis:

I find this game far more successful than our previous game, Gravithomas. Our organization was better as we were using Slack and Trello to update ourselves on our tasks and current workable project folders.  There were a lot of things that just didn’t work that usually took a second pair of eyes to fix and doing things in pairs would probably make our next project more efficient. Our game itself still could use much work. The premise seems fun and workable but we would definitely need to tweak our metrics for our playable level and tweak our movement to be a little bit more intuitive. At times steering was too stiff and others way too sensitive. And crashing into walls happened way too often for what the controls offered us. These are minor tweaks but theyre tweakable. Mostly I’d like to see more effects caused by specific or randomized pick up items, instead of random effects happening with increased frequency when an item is picked up. Additionally, our level being as interesting as it was (thanks Thomas!), I’d like to see wider and more interesting environment choices. Going inside a building, going off ramps, having secret paths and so on could make our racing game so much better, but that’s definitely a time sensitive thing and given a week I think our prototype did well.

[chey-dev-blog]

GraviThomas – Log and Analysis

LOG: GraviThomas is a 2D platformer that Thomas Tobin, Michael Guattery, Dave Brown, Richard Baldock and I worked on over the course of a single week. The main Mechanics of the game involved platforming across stationary and vertical moving platforms. The moving platforms are controlled by the player when they decide to use their gravity powers, and will either go up or down, from their normal position, based on their density. We decided as a group that traversing the game world should feel like a solving a puzzle, so we’ve also added some basic lock and key mechanics, button and door mechanics and  coin collecting mechanics to help add some challenge and guidance to the game.

Overall, with the exception of Michael who was diligently fine tuning the gravity mechanic, most of us worked pretty evenly on the game. Each of us picked up and completed whatever needed to be done next rather than being assigned roles which I found really efficient. I was responsible for a few of the smaller parts of the game. I created the lock and key mechanic, the coin collecting mechanic, the respawn on death, set up the UI, and helped design a decent portion of the total level.

I focused most on the intro of the level, assuring the player understood and absorbed the main concepts of the level right off the bat. The player is shown a green key in another section of the level and a green lock to their left. This assured the player knew they would have to collect the key, and that the level will circle back to the start. How to jump is pretty standard with the layout of the coins arching over a pit of spikes, indicating a hazard. And lastly the moving platforms and button/ door mechanic is introduced immediately after. The player would walk over the button opening the door, but immediately after stepping off, the door would close again. If the player held down click, the platform above them would come down with gravity and so long as it was in contact with the button, the door would open back up. Most of our issues came with the actual designing of the level and implementing the gravity mechanic efficiently. Sometimes we’d gate an area of the level too difficult, or downright impossible, to pass and it took a lot of tweaking and tuning to make the level progress smoothly. Analysis:

I think the game was a strong learning experience for us in group dynamics and taught us how to work well and efficiently with each other. Our group has a sense of creativity and most of us came up with some really strong ideas when pitching games ideas to the rest of the group. The game itself has an interesting idea with a simple premise but I think it definitely wasn’t executed well enough to be carried on to something marketable. At least not yet. My biggest issues with the game is its lack of tuning in movement. Our character movement came attached to an animated 2D character that we downloaded from the Unity asset store, and we decided to work around its movement rather than edit it (we really liked the movement animation is why we kept it). However this, I feel at least, screwed over our game a little. The game is meant to be faster paced and make you think on your feet, however our characters premade movement was slow and clunky feeling. Our platform gravity was also an issue for me, as they accelerated quickly and applied way too much force on each other which often made the platforms bug out for a bit before returning to their normal positions. I think steady-velocity translations would be more efficient for timing and movement than the current gravity we have, but apparently this was too difficult to work around given unity’s built-in physics and its issues with colliders. Given a week though, I think we did REALLY solid! We made a full level of a platformer in a week, introduced our mechanics well, challenged the player as they progressed through and we had fun doing it. I think if we can apply Nintendo’s teach, test, challenge and flip philosophy to brand new mechanics and further levels, then this game could be really workable.

[chey-dev-blog]

Post Mortem: Synesthesia

For our mini-game assignment 2, we made a game called Synesthesia. Rodrigo, Ian, Marcy and I came up with the idea of creating a game that focuses on exploration and emersion. We needed a primary mechanic and settled on Collection as the action that would drive our game. We dabbled with the idea of creating a physics based game with gravity and black holes, focusing on collected stars and avoiding certain obstacles but we didn’t like this idea too much as coding gravitational forces was a headache just to think about. We kept with the space theme a bit and made the player of our game a star. We really wanted ambience in our game and so we decided to include and play around with sound. 

The result was the game synesthesia, where you, as a large white sun, go around collecting smaller colored stars that produce different sounds and travel in different patterns. We were tasked with different jobs in creating the game. Ian would create the different stars, I would create their movement patterns, Rod would code the capture and inclusion of the stars and Marcy would find sounds.

The week was stupidly busy with prior assignments so by the time Thursday hit, Ian, Marcy and I had just started to work on our assignments when rod came in with a practically finished product. We were really glad that he actually had it done despite most of us feeling like shit for not contributing, but I rather count my blessings than complain.  The game he produced didn’t have stars anymore but small nodes (lights) that would be randomly generated on screen and captured by the original white sun. There were 4 colored lights (red blue green and white), that would produce different percussive sounds and a pause. Collecting the lights would basically produce a beat that grew over time into a cool sounding rhythm.

 Rodrigo didn’t feel like it was enough of a game though as the project didn’t have a clear goal, so I attempted to add another mechanic by adding an enemy that would wipe out any lights you’ve collected that it came in contact with. This didn’t work too well though as I didn’t know how to work around Rod’s code to regenerate lights into empty positions once new ones were collected, and instead the game broke and produced an error that made it unplayable. We scrapped this idea, though honestly with enough time to work together, we could successfully implement it. Rod did add the task of finding 2 Gold lights on the map that had very neat sounding piano riffs that added some dynamics to the game.  This was really successful at wowing our peers during presentation and we could continue to develop this if we had more time, by adding more gold lights with induvial riffs that would liven up the beat into a proper melody.

 At the end of our presentation we realized the potential of our game came from the joy of making a song rather than the exploration or challenge of evading an enemy. So if we were to develop it further we would have a much simpler goal ahead of us with a lot to build on.  I do wish I could have played a more important role in the creation of the game but once again I count my blessings that we had group member with so much responsibility and initiative.

[chey-dev-blog]

Post Mortem

HEYO, this is Chey! Welcome to my very first blog post and post-mortem for a couple of very simple games I and my teammate, Melinne Hay, made for our Game Mechanics class.  We decided that we should settle on a singular Primary mechanic for both of our games and then split up and develop our own games with different secondary mechanics, helping each other along the way with playtesting and feedback. Coming up with an idea was kind of challenging, honestly I don’t think either of us are any good at COMING UP with a decent idea, but Melinne was gold at providing constructive criticism and BUILDING on ideas.  We settled on Racing as our primary mechanic and built 2 multi-player competitive path building games. GAME No.1: Highway Hustle (I just made this name up on the spot, we didn’t name the games)

This game was a 2 player path building game with a pretty simple goal of joining 2 points on the outside of a grid with a “high way”, before the opponent.  Players would draw from a hat a city (point) on the outside of the grid (a letter or number) from the TOP or LEFT side to start from. In a separate hat they would draw a city from the BOTTOM or Right side. This was done to hopefully encourage the 2 player’s paths to cross while still giving the game some randomness so it wouldn’t be stale

After points were chosen, players would draw 3 sections of highway (tiles) to start building their paths. The player would always have to keep 3 tiles in their hand, playing and drawing 1 per turn.

There were 5 types of highway (tiles) to draw.

A Straight

A Right

A left

A Bridge (to hop over an opponent’s path)

A Conjunction (lets you go left, right or straight)

After play testing in class, we found that sometimes opponents wouldn’t really need to cross paths if they got points that focused on one side of the board (top half or bottom half). This killed much of the competitive and strategic aspect of our game and it just became about who got lucky enough to draw the right tiles. Another flaw was that a player instantly had a clear advantage when their connecting cities were drawn. The element of randomness didn’t take that in account and one player always felt cheated, even though the random draw was intentional.  A play tester suggested to pick 2 points at opposing ends for permanent start and end points for each player, but found that boring and restricting. Honestly the game was pretty lame and anticlimactic. The second game we made was a little more interesting. Game No.2:  4 Player Line Connector Galore (also made up on spot, I’m really bad with names)

 This game was a spin-off of the first, and instead of drawing tiles, players could freely draw where they wished to go on a larger grid. The movements were restricted to forward left and right, with the option to bridge over an opponent if a turn was sacrificed. Instead of going from a start to a finish, we placed multiple cities, worth different points, on a 40 by 40 gird.   The goal was to hit as many cities as you could before your opponents. Players rolled die to see how many moves they could make in a turn. This game worked out much better than the last as there were more options to travel around and more players to cross paths with. The layout was more interesting too and the general feedback was that we could do more with this game than the last. We could add power ups and obstacles to make the game more interesting. Melinne did most of the work on this game though and did play testing on her own a few times. The general reviews we got were that the maps needed symmetry to add fairness for all players, and different maps would be interesting too.

Conclusion:

Honestly this assignment didn’t really have too much emotion or heart put into it so I feel like the end results were great but only on a functional level. My game wasn’t all to fun and Melinnes was better but neither were really too creative. I think this is because we both approach game design too similarly and so we didn’t have too much variance in ideas. In addition the time restriction made it feel rushed and like we just had to get it done instead of get it fun.