twincop

[twincop]

Dev Update 8

Kartik: Greenlight, Roadmap Complete, Improved Environment Visuals, Final Flow Started

We had a solid 5-hour company meeting where we hashed out the entirety of the rest of the game, which is described intentionally vaguely below. We also decided to go ahead and post our Greenlight even though we are only in pre-alpha. This has been a very anxiety inducing experience for me personally, putting my work in the public space is hard enough especially when I know we’re not even close to making this look as great as we can.

Greenlight

Here is the link to the Greenlight campaign. This is how we’re going to get on Steam, so if you like what you see (or believe that we’re going to continue working on this and actually finish it) please give us a vote here.

Also, get in touch with us via that page! Tell us what you think and what you want to see in the game, I look forward to responding to some of you!

Roadmap Complete

Pre-Alpha to Alpha: Ok, here is the basics of the roadmap and what we’re looking to do with the gameplay. We are currently in Pre-Alpha because our core gameplay isn’t quite complete, we are missing one core function: player abilities. Once all player abilities are complete and working we are going to be in Alpha. Here is a taste of some abilities I’m currently prototyping: Grappling Hook, Power Punch, Super Taser... etc. We have them all planned out, just a matter of prototyping and figuring out what is fun and what works.

Beta: Once we have reached our Alpha milestone, we will start working towards our Beta milestone that will be a matter of completing all the content. Our planned content (subject to change) includes three chapters that take place in unique environments, with unique boss fight(s), and a story arc that ends with an epic final boss fight. We will also have an “Arcade” mode that unlocks various stages as you progress through the story. The ‘Arcade’ mode levels take place in small arenas where you face an endless horde of enemies and compete for the best high score. Once all of the content exists in a playable format we will officially be in Beta. At this point we may or may not decide to do some public testing, but that is TBD.

Gold and Reach Goals: Once the Beta is complete, we will continue to polish and do as much quality assurance as possible before hitting a launch date sometime Q4 2017. Some reach goals we will try to accomplish around this time include: Online Cooperative, Online Arcade Leaderboards, and whatever other fun ideas we’ll come up with as development progresses.

Thats our roadmap as of right now, the entire thing is subject to change, but I am going to do everything in my power to hit our (internal) deadline dates to ensure we reach a reasonable release date.

Improved Environment Assets

Ok, on to talking about actual development! I’ve spent this past week polishing environmental art a LOT. Our unique camera angle presents a range of problems with how we chose to do our environment. In the screenshot below, I pulled the camera to an angle you don’t normally see to give a better view of the environment I’ve been building for the game. All the art is done as sprites and placed in 3D space, which in hindsight wasn’t the best way to do things but that is where we are now.

I also spent a lot of time sweetening the lighting and adding ambient occlusion decals wherever geometry intersection stood out too much. Although this is a lot of work to do by hand, I’m very pleased with the results and the fine control I have over each aspect of the visuals is exciting to me.

Final Flow Started

Here you can see the main menu has some new options on it, namely: Story and Arcade. Everything else is about the same, but will probably be slightly reworked as the flow is finalized.

Eric spent some time getting the loading and scene transitions to work with knowing what mode we’re in, and which scene to go to as we reuse modular UI elements. Eric also re-worked the training scene since up until recently it had been a very weird/disconnected scene from the rest of the game. It now has a similar flow to the core gameplay and less prone to breaking.

This concludes this weeks update, I look forward to seeing how our Greenlight is received and what kind of community engagement we receive. This is the first time I’ve put a game in front of such a wide audience, and this is a fairly scary process for me. Go easy on my heart, world.

[twincop]

Dev Update 7

Kartik: Recent Accolade, Updated Main Menu, Player Abilities, Fine Details

First of all, we won an award!!

We won the Best Student Game award at IndieBits 2017. We are super proud and very excited about this achievement and hope to continue to take this game to other local shows to gain more recognition.

This update might be a bit short due to how busy this week is (and last few weeks have been), in spite of the significant progress that has been made.

Update Main Menu

One immediate change you’ll notice about the game is the update main menu. The previous main menu had been feeling very “dead” to me, nothing about it felt alive and the design didn’t match the energy and excitement of the game. Take a look at the new main menu:

The design is by no means final, but it is far more in line with the aesthetic of the game and feels much more alive. In the video attached at the bottom you can see how the elements are animated and breathe life into the previously dead menu.

I have plans to make the text a bit more readable and to improve on the visual of the icons along the side for more clarity but those are on the back burner until other work is completed.

Player Abilities

One major critique we received from one of our recent playtests was that there is no compelling reason to choose specific characters from the main menu. Our solution: player abilities. Each character is going to have a unique ability that adds significant flavor to the gameplay. The two abilities we have completed thus far are Power Punch and Grappling Hook (names subject to change)

These abilities are activated by the left trigger (giving symmetrical controls on the controller) and have a set number of “Charges”. See the UI below:

Each time one player uses their ability, the other player’s charges are refilled by one. That, and Twinsanity, are the only ways to refill your charges for your ability. This goes hand in hand with the cooperative gameplay that is already well established in the game, and we hope it works for players as well as it works for us.

These abilities are going to be used mostly for crowd control and strategic maneuvers, though balancing their usefulness is certainly going to be a huge challenge. None of these abilities are going to do a whole lot of a damage, their primary usage will be to move/stun/relocate enemies around the map to make them easier to kill.

We can control the maximum number of charges an ability might hold and plan on using that as a balancing tool and a gameplay tool to encourage various play styles. We hope that the other ability ideas we come up with will be equally fun and engaging to use, and that each one will have an interesting play style with another.

Fine Details

As usual, a slew of smaller changes were made (bug fixes, tweaks, other miscellanea) that don’t deserve their own category so here they are in a concise list:

Bringing attention to the wave instructions: A lot of people seemed to miss the small bit of UI on the top left corner of the screen that showed you how many enemies you have to kill, or what the special instructions for a wave were. Now, a small animation pops the UI close to the center of the screen and brings attention to itself before it pops back into its position

Wave end communication: Some players were confused about whether or not they’d defeated all the enemies since the only communication that a wave was finished was the UI that indicated the beginning of the next wave. Now there is a flashy animation that indicates that you have successfully cleared a wave, not only rewarding the player more but also better communicating their success.

Sleep frames: This is something that we have been struggling for a while with. We wanted to be able to momentarily freeze the game on important moments like hooking an enemy or landing a huge hit (a lesson learned from Jan Willem Nijman’s excellent “Art of the Screenshake”) and we finally managed to get it to work mostly bug free.

Improved loading logic: Previously, the game would have a variety of issues related to loading and these have mostly been dealt with

Balance: regular shooting enemies move a bit faster and are a bit more squishy, rocket dudes are more tanky.

Polish: Cans now explode into a puddle of soda, layering of enemies and bullets and environment has been improved, Twinsanity auto-disables at important moments to prevent awkward slow-motion.

That concludes this Development Update, thanks for reading. Stay tuned for more fun announcements and even more content!

[twincop]

Dev Update 6

Kartik: Player Dialogue, Improved Communication, Boss Polish, Procedural Blood, and Bugsmashing (as usual)

Don’t worry, I know we went one week without an update. Maybe that was because we’d been working on this for 5 weeks straight on top of our other jobs and obligations and felt tired. I don’t know, just throwing it out there.

Player Dialogue

One of the biggest changes between the previous update and this one is that there is now a system in place for player dialogue options. Just like everything else in the game, this is (intentionally) awkwardly controlled by both players. One (randomly selected) player gets to choose the first half of the response sentence and the other player chooses the other half. This leads to some sentences not quite coming out the way TwinCop may intend.

You can see that the UI even reflects which “side” of TwinCop is speaking. There is a timer at the bottom right corner of the panel to encourage quick responses and reduce dialogue fatigue (I hate it when dialogue cutscenes take unnecessarily long in games... hint: you can press “Start” to skip all dialogue in our game!)

Developing this system came with its own slew of challenges, for instance handling the wide range of responses. There is a total of 10 possible responses; 3x3 combinations of options, or the 10th option: being silent. Eventually it is my goal to have a written response for each dialogue option (the system allows us to easily add whatever dialogue responses we want). We can add a lot of comedic value through this dialogue system and I look forward to seeing how this is fully utilized.

Improved Communication

One of the most common bits of feedback we’ve been receiving is that it is sometimes hard to tell which way the players are trying to move. Since the indicators are only two small triangles that turn white when they overlap, it can be difficult to stay in sync.

The new visual does two important things: it drastically increases the visibility of these direction indicators and helps the player be able to tell which indicator is theirs even when aligned. The former is achieved through (obviously) making the colors more vibrant and adding colored rings around the player. The latter is achieved by offsetting the triangle positions such that even when they overlap and become white (an important part of indicating that the player is healing and charging twinsanity) you still know which triangle is yours.

Boss Polish

Watch the video attached at the end of this post if you want to see what I did. Basically we had been missing some audio during the boss introduction, and the boss kinda just disappeared when it died. I made a short track to play while the boss is transforming, and started the music right when the name appears. I am still planning on improving the visual for the name reveal however.

When the boss dies, it now has a prolonged explosion followed by cheesy light beams that erupt from within. It feels far more satisfying to defeat, and the sound effects (very slowed down and pitch-shifted gunshot sounds) make it feel that much more epic.

Procedural Blood

Up until recently I’d been spawning small blood splat sprites I’d made every time an enemy got shot. I was growing tired of seeing the same blood sprite over and over again, especially when some of them wouldn’t always appear where I expected them to. I decided to try to make a new system for making blood decals and am now using a particle system to paint the blood splat onto the decal layer.

All I did was switch the layer of the particle system to the decal layer (see one of the earlier dev blogs to see how I’m doing the permanent decal system) and tell the decal system to render the particles shortly after they’re created. What that creates is a blood splat shape that actually resembles how and where an enemy was shot. I already had this blood particle system working, so utilizing it with the decal system should’ve been a no-brainer. I’m much happier with how the blood naturally fills the play space now.

That was a dark and gruesome thing to say. Moving on~

Bugsmashing

Due to the plethora of bugs we fixed this past week, let me just list them with minor details so you can see the madness we’ve been dealing with:

Our system for initiating TwinSanity had up until now been requiring players to both press “A” on the EXACT SAME FRAME. No idea how we didn’t notice this until now.

Sometimes when enemies died, their death would count as 2 deaths instead of 1, throwing off the entire wave system

Blood started spawning on the wrong layer, causing lots of z-fighting

Explosions during the boss fight would randomly freeze from time to time

Rockets were being rendered in front of UI

One of the skin color options on the main menu got set to a VERY sickly yellow on accident

Layering for the PopTop machine got broken when we updated to Unity 5.6 (praise the new layering system)

More minute frustrations that were buggin’ up the system.

If you made it this far, thank you for reading and also get a life what are you doing reading this go outside make some friends. Or watch the play through of the latest content here. Your choice.

Thank you,

-Kartik

[twincop]

Dev Update 5

Kartik: Character Select, Backend Improvements and Bugsmashing

Spring has come and so have my allergies, meaning when I come home from my full day of doing a full time job and a part time job I’m a bit more tired and woozy than normal. In other words, not as much work as I would've liked got done this past week. I did get half of a new feature done however, a character select screen!

Character Select

So in the video you can see two panels that let you choose the character and skin color you want, and then you can see the “composite” cop in the middle. I wanted the character select screen to match the comedic tone of the rest of the game, and reflect the same energy as well. One feature I’m still working on is a little animation that shows the half of a face that has been changed being RIPPED OFF with BLOOD AND GUTS coming out of the seam, and have the new half face slam back onto the head. I think this will match the tone.

You can also see two fists on either bottom corner of the screen, and this is how you confirm the end of character selection: both players press ‘A’ (on xbox) or ‘X’ (on PS4) and the fists slowly close in on the center of the screen, have an epic fist bump, and then we transition to the game state.

As for how character selection actually impacts gameplay, it won’t. Not by much. We have some plans to maybe have character dialogue, and in that situation we might have some more character-building through unique dialogue. Other than that, it will be used to customize the high score board to show the portrait of each player next to their name and score.

Kudos to Garret for making all the art and writing the hilarious bios for each character. We are going to work on the seam at the middle of faces on each side. When Garret made it initially, he didn’t know I was going to show the entire face at any point so the art had a black line going down the middle.

Back end and Bugsmashing

As usual, Eric and I love maintaining good back end practices and decent efficiency in how information is handled. Recently I made some changes to the backend in how the various components on the player (shooting, moving, health, etc) communicate with one another. I also updated how Bullets deal damage to entities to be more generic. This unfortunately broke killing and dying in many ways, and this went more or less unnoticed until I was demo-ing the game to some friends.

Of course.

Either way, I spent some time fixing my mistakes, and now the general flow of code is not only more sensible but also a bit more efficient. Not gonna go into detail because you might fall asleep, I know I did while I was working on this. Not as sexy as adding new features.

[twincop]

Dev Update 4

Eric: Messaging System, Explosion Art, Boss Attack

This is my first dev update for TwinCop compared to Kartik’s 3, and it contains a very important element of game development for me: Modular Programming. Modular programming can be defined as a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

Modular code is not needed to make a good game, but it is needed if you want to hold onto your sanity and what’s left of your sleep schedule while you make that good game.

Messaging System

We found ourselves in need of a way to communicate with the player through text (don’t worry, not a lot of text) so that some of the story elements would make sense in this random game world.

“Oh man, you just decided to add that to the middle of your game in the middle of its development?!?!?”

Yes, disembodied voice, we did and it took all of about 2 hours to put in and test to make sure that it worked properly. It was pretty easy since all of the code is so self contained. A message manager creates a singleton instance of itself, and then anything that wants to display a message send an ID of the message that it wants to display, and if the message exists, the message manager tells the game manager to pause the game so it can display the message. And as Kartik put it when I showed it to him: “I love that this just works.” Yes, yes it does, Kartik. Done and done.

Explosion Art

This one is pretty simple. I made a pixel sprite explosion because we were going to have some rocket dudes, and you can’t have rockets without explosions, right?

I followed a tutorial by Pedro Medeiros to create this piece that you can also see here: https://www.patreon.com/posts/explosions-part-7719254. We knew that we would want this explosion for the rocket sprites, but it has now become our generic explosion in the game!

Boss Attack: Barrage

This section combines the previous two! You see, once I had the explosion, I realized that I could make a barrage of bombs attack from the boss that surrounded the player and then blew up after a few seconds.

This attack took me all of 2 minutes to create, no joke. Due to the modularity of the code, I already had everything set up on the back end to where I just need to add the explosion prefab to a list of effects and then added a function to the bosses state machine so that it would spawn these explosions at appropriate times in between firing rockets at the player and just sitting there.

That’s all I have for this dev update. I will be taking some time to crank out some art, so hopefully the next time that I post you will see some new level art!

[twincop]

Dev Update 3

Kartik: Mecha Pontoon Boss Fight, Improved Bomb Defuse, Subtle Improvements

Another week, another update full of fun stuff. We’re reaching a point in development where this version of the game is feeling content-complete. The version we’re working on right now is a “Festival” version that plays well in short spans and quick sessions. Eventually we’re going to have to start thinking critically about what this game’s long term goals are and what the overarching structure is. For now, we continue charging forward!

Boss Fight

That’s right, we’ve got a boss fight. Its a pontoon boat that transforms into a Mecha Pontoon and proceeds to fire a barrage of mortars and tracking missiles. There’s a video at the end of this post, but here’s a gif of the intro:

Eric wrote a very efficient and quick to implement message system that I used to write a comedic intro for the boss.

Yup, the Mecha Pontoon talks, and its kind of an asshole. Also, yes that is a stock photo of a pontoon boat in the television screen and yeah, it is probably gonna stay because it’s hilarious.

The boss is fairly straightforward to defeat as of now- you will quickly discover that the body is impervious to damage, but the small jets on the side are not. Destroying the four jets will defeat the boss immediately, though that may change after some play testing. Playing by myself, I was able to wreck the boss very easily but I imagine it will be harder for others to do the same.

Eric implemented the two attack states of the enemy: mortar barrage and tracking missiles. The boss randomly decides between which state to be in and constantly tries to look at you and follow you.

I’m pretty happy with how this turns out and I’m looking forward to getting others to play this and find the right difficulty balance, and also discussing with the team exactly what dialogue we want to run with. (Special thanks to the Game Boiz for some of the ideas you guys pitched, even though I didn’t get to really do any of those!)

Improved Bomb Defuse

In the above gif you can see how the ‘health’ text has disappeared and been replaced with more a more visual representation of wire health. This is just a lot easier to recognize as progress and I was not a fan of how the text looked on screen. (Thanks Sean Flanagan for this advice)

Subtle Improvements

Since we are quickly approaching a content complete version of this game, I’ve started looking at more polish things so here is a semi-random list of things I did that help the game feel more polished:

Bullets leave a trail: This should help with aiming, giving a better idea of where your bullets are going.

You can’t walk over the bombs in the bomb defuse game

The UI that appears to show you how to start defusing the bomb is now attached to the player to make it more contextual

Added an explosion sound effect (which is just a gunshot sound effect slowed down a bunch)

Added some animations to the dialogue box so that it feels a bit more alive.

There is probably more, but that is all for now. Eric will be posting a dev update soon to talk about the progress he’s made so stay tuned for that!

[twincop]

Dev Update 2

Kartik: Bomb Defuse Minigame, Improved Decal System, More Backend Future-Proofing 

“Game development is a marathon, not a sprint.” - Chris Deleon We’re making good progress but I don’t recommend making games like I do- I spent all of Thursday (15+ hours non stop) to make this much progress in one week, along with some minor work each night during the week. Needless to say I didn’t feel so good on Friday. Do as I say, not as I do.

Bomb Defuse Minigame

I’m most excited and proud to talk about this, since it is the biggest gameplay addition since the last update. Here is a super compressed gif of the minigame in action, and a screenshot of what it looks like as you “search” for the bombs.

How the minigame works: The screen space UI in the screenshot guide you to the three bombs that have spawned in the world. Once you reach the bomb, you are prompted with UI that indicates you should hold ‘A’ (on Xbox) or ‘X’ (on PS4) to enter “defuse mode”. Both players must be holding those buttons to stay in that state. What follows is (hopefully) a hilarious and stressful battle as both players struggle to move the scissors together to cut the right wire before the bomb explodes in your face. After successfully defusing the bomb, the other bombs’ timers are reset and a few enemies spawn to get between you and the bomb. Defusing all 3 progresses you to the next wave.

How I developed this: This was a lot harder than it looks to make. I struggled initially with the visual design of this, I knew I wanted it to be about cooperatively cutting a wire, and I wanted the controls to be intentionally frustrating yet responsive. Initially I tried having 3 or 4 wires, randomly spawned and connected to various places and you had to cut them in a certain order but that proved to be too complicated. This is a minigame and shouldn’t distract too much from the core gameplay. I settled on the two wires with random colors because I realized that controlling scissors with two players is F**KING hard! Even if I made the controls as easy as possible to use, I still struggled to do this. So I made the game VERY forgiving for where you actually close the scissors, you can technically cut a wire even if your scissors are WAY off to the right or left side. I also added a health system for the wires because it was too easy to accidentally cut the wrong wire as soon as you start and it actually turned out to be fun when you’re trying to get into a rhythm of cutting it.

Polish: I spent about 4 hours just basically implementing the minigame, and another 8 hours polishing it. Communication is key in minigames like this, and I wanted to have as little on screen text guiding you on what to do so I did a lot of visual indicators to show you where to go, what to do and how to succeed. This minigame activates fairly early too, so if you fail by not knowing what to do it isn’t too punishing. The mini-game reappears later in the game but with shorter fuses to show you how much you improved. I’m really happy with how it turned out and how few bugs there are relating to it. I have some more ideas on how to improve on it (including a color-blind mode, since being able to tell colors apart are kinda important).

Improved Decal System

This is directly related to the previous Dev Update so read that if you don’t know what I’m talking about. The decal system was working by having a second camera angled far above the entire scene, only rendering the ‘Decal’ layer with it’s clear flags set to “Don’t Clear”. That meant that if anything on the Decal layer appears at any time, it will render as normal but never be cleared (even if that decal object is destroyed).

I realized it was really inefficient for this camera to be constantly rendering the decals if no new decals were appearing on screen, so I disabled the camera and am now manually calling “Camera.Render” on it when any decal is spawned. I realized then that it would be inefficient (and probably cause bugs) for the camera to render twice in the same frame if a lot of decals are spawned quickly so I added a public static boolean to the class handling the camera that is set to true whenever a decal is spawned (thereby ensuring that even if two decals spawn on the same frame, it doesn’t render twice). The decal camera then calls “Render” on itself on LateUpdate if the boolean is true, and then resets the boolean to false.

Future-Proofing Back End

A lot of my time this past week was spent future-proofing our wave manager system so that we can allow for mini games like the bomb defuse one. We have ideas for more creative and hilarious mini games to break the flow of the constant killing and the existing wave system wasn’t geared well to allow for such creativity. There isn’t much to talk about here other than “It Was A Lot Of Work That I Can’t Show You”. We’re ready now to have more minigames and quirky gameplay elements.

Coming Soon...

Next week, hopefully, I’ll be able to show a BOSS FIGHT. Hopefully. Until then, enjoy this gif of a transforming Pontoon Boat that may or may not be related to that.

Also here is a lightly edited video of current gameplay with no audio because I screwed up the recording.

[twincop]

Dev Update 1

Kartik: Permanent Decals, New Enemy, Code Refactoring

I wasn’t planning on starting this dev blog so soon, but I felt particularly inspired to start writing and so here we are. Since this is the first one, I don’t really have a point to ‘update’ from, so I’m just going to talk about what I did over the weekend.

Code Refactoring:

My least part of game development. Since this game was originally made for the Global Game Jam, it is no surprise that the code base was horrendous and far too specific for what we were aiming for in scope for the Jam. Reworking some of the jam-code had been a priority but Eric and I had been putting that off for too long. Finally it came time to rework the wave system. This being a core system of the game I was worried it was going to take a long time but, it was not too bad! Pro tip: practice good decoupling of your classes! Since the system that handled waves was so cleanly decoupled from all the other classes I had a pretty easy time getting this done. The reason for this refactor was because we wanted to have more freedom in “designing” waves with specific timers on when and how enemies will spawn and even allow for “special waves” like mini-games and objective based waves so that the entire game isn’t just firing at swarms of enemies and will have a more interesting flow to it.

New Enemy:

Welcome, rocket dude.

This baddie does exactly what his name and visuals imply: he shoots rockets. See GIF below.

http://gph.is/2mR22Wp

This shows how the enemy targets and attacks with almost the same behavior as the regular shooting enemy (he moves slower and aims a bit faster, and has further “reach”). This also shows the effect when the rocket hits the player and other obstacles (the bullet sprite is the same bullet sprite as the other enemy but is going to be replaced with an animated rocket sprite soon, and the explosion effect is not final, still some polish I want to put on that). You can also shoot the rocket to deal splash damage around it (yes, that includes enemies!). I hope that the last part becomes a fun way of disposing of large crowds of enemies in a creative fashion.

Permanent Decals

This one was particularly fun, mostly because I used a system I normally am too intimidated to try. I knew I wanted the ability to leave permanent decals all over the place so that after each play session the player can see the carnage they’ve wrecked all over the place (really following Jan Willems screenshake advice very closely, permanence!!). See screenshot below, for decals that are 100% permanent throughout a play session, no matter how many enemies you kill and how much blood you shed.

Technical explanation: Basically the way this works is that everything that I want to be “permanent” was set to a render layer I created called “Decal”. I then created an orthographic camera that was looking at the entire play area (which isn’t that big) and instead of rendering that camera to the screen I render it to a RenderTexture which is being used as the texture on an otherwise transparent plane placed directly within the space that the “Decal Camera” sees. This camera is also set to ONLY render Decals and the real key to making this efficient was setting its clear flag to “Don’t Clear”. This means that whatever gets rendered to the texture, is permanent and won’t clear even if the sprite I spawned initially has been destroyed. That means that every skeleton and blood splatter only really has to exist for a millisecond for the decal to be “painted” to the texture. I really hope this is as efficient as it seems to be, this aspect of game development is not my forte.

In conclusion, I got a lot of good work done this weekend, and end of last week. We are hoping to submit to IndieBits, and before we are ready to do that I wanted to implement 2 mini games and a boss fight. Eric is working on the boss fight and I’ll see if I can convince him to post here when he finishes that, or makes significant progress. My next dev update should come in about a week when I’m done with those mini games, and we can see how that fits into this game.

If you made it this far into this verbose long winded dev update, thanks! High five! Fist bump! Tell me what you thought, this is my first time doing this so I’m really curious to see if there is anything I can do to improve or make it more entertaining/informative, or anything I should do to make this more beneficial for myself. I enjoyed writing this but I’m just trying to justify spending an hour or two putting this together vs actually working on the game. Either way say something if you want to. Until the next update, bye!

[twincop]

Patch Notes Version 0.1 (Beta)

This is the beginning of our patch notes system. Even though we are in closed beta and are testing internally, we are trying to get into a habit of posting patch notes here as we go live. For now, this is just a list of the GitHub commits that were merged into the master branch. Hopefully, this will force us to make more descriptive commit messages and get us into a good practice of keeping track of changes. Future patch notes will be more detailed.

Adding services

Moved spawners back and changed the color of the enemy bullets

Fixed enemy spawning

Updated backend to allow for stat tracking and implemented ui for stats

Keeping track of score

Moving scoring to its own manager

Testing C# 6.0

unexpected changes in game scene

Revert "Testing C# 6.0"

Adding in scoring manager and changing the flow of gameover

Car sprite and prefab

Added car to scene

text input and high score UI almost finished, weird bug though

updated name selector UI and fixed accidental pause on final screen

Finishing touches on name UI - still 1 bug

Street lamp sprite added

Updated a lot of visuals

More no-filtering

Settings UI Backend

Main menu implementation almost done

Static markings, added joystick support for incrementing highscore name

Main menu done, new song too

Added tick to name selector, city limits instead of road closed

Updating credits

Added second tick, removed credits & quit from game

Fixed mixer issues on building

Joystick for player 2 name inputting

Twinsanity line and UI fix

Score manager starts at 0

Minor aesthetic thing for me