Critical Analysis: Endless Runner

Critical Analysis

So our game is an endless runner that incorporates boosts, coins, and different terrains. The player has all the essentials of an endless runner which is having the ability to jump, dodge obstacles as well as manuever the map by moving from side to side using the "WASD" keys. Our endless runner incorporates different terrains such as land and water. You are a the basilisk lizard, which has the ability to run on land and water, running and manuevering the randomly generated terrain trying to survive as long as possible while collecting points and picking up speed boosts.   

Our first brainstorm of our game began with us wanting to make an endless runner that incorporated multiple levels for the runner to be able to interact with. We then discussed different terrains which led us to land and water. We liked where this was going. So Ian and I pitched the idea of using a frog for the player because they are amphibious which fit our game perfectly. We also pitched another creature call the basilisk lizard which has the ability to run across large bodies of water on it hind legs. We discussed the pros and cons of both creatures and decided on the lizard rather than the frog due to having more mechanic and player benefits. 

We then discussed how we were going to incorporate the lizard with the water and land. So for the land it was pretty easy we just wanted it to be able to move from side to side and be able to jump. However we were very split about the water. We wanted it so that the player had the option to run on top of the water or through it. But we did not know how incorporate it game wise. At first we discussed on having a pick up that allowed the player to walk across the water. Basically just skip it. If they didn't pick it up then the player would drop down into the water. So why drop into the water. Well this is where the risk and reward system comes into play. If they dropped down into the water there would be a lot of coins for the layer to pick up however there would be hazards for the player to dodge. We then changed this to have just a speed up that check whether or not you are over water. if the player is then the player ignores gravity for the time the boost lasts. So if the player loses the boost while over top of the water then they would fall into the water. 

We decided to go with the speed boost that lasted a certain period of time. This turned out to be a very good decision because it allowed us to use the boost in many places rather than just for the water. 

We also discussed having the ability to jump on platforms to incorporate the air terrain. It was instantly vetoed because it did not make any sense to have and it seemed out of place. So to satisfy the "air" kind of terrain we added elevations to the chucks such as bridges and protruding environment to give the player a sense of elevation. 

Another thing that we changed was having large obstacles such as turtles in the water and having a bird swoop down and kill you. Reason being is that the proved to be too hard for the player to manuever around and dodge so we took them out completely and stuck with the static objects that take off half of your health.

With all these changes and testing our game turned out really great and had a lot of strong points. One the major strong points was the random generation of the level chunks. This made our game. Without the random generation for the game our endless runner would not be nearly as "endless" as it is now. Huge shout out to Vivek for solving and coding that portion of the code. 

Another strong point of our concept was the speed boost and water mechanic. Its really slick. Ian coded it in a way that it checks to see whether or not the speed boost is on or not. If it it the gravity is off and will not fall into the water. If it is not on then it will fall into the water. It also really gets across our main idea of wanting different terrains and to get across which kind of lizard we initially wanted to use. 

 Overall I am very happy on how this concept turned out. It is a fun, full fledged endless runner that would like to work on further in the future. One of the major success of this concept was getting the random generation of the level chunks to work so that it would actually be endless. Another big success is that we were able to create our initial idea which was having a an endless runner with different terrains. I think with a little work on the terrains I think it would become a fun, novel game mechanic that I think it could be added into other endless runners like Temple Run. But to highlight the major success was the group and the work ethic. Everybody in my group is working at such a high caliber and getting work done left, right and center. I am so happy with my group. They are hard workers and they make these great concepts happen. Well done team.  

         

Proof of Concept: Endless Runner

 the Endless Runner

For our third Proof of Concept our team was tasked with creating a concept that incorporated one of the following archetypes:

- Endless Runner

- Brawler 

- Turn Based Strategy 

The catch for this proof of concept is that we had to incorporate interfaces into our code. A interface is basically a contract within the code which makes the code more modular. The reason why we chose this archetype is because we thought it would be the most fun and we thought it would test our skills the most. 

My responsibilities for this proof of concept was team manager, UI implementation, and coding. Like our last concept we split the tasks evenly based upon our skills and what we wanted to tackle. I enjoyed doing the implementation of the UI as well coding the implementation of it.

As the team manager i made sure to schedule all of our meetings for the week. We had two scheduled meetings for this concept to discuss what everyone was doing for the concept. The second one was to make sure everyone was on track and to sort out any problems we were having with our tasks or with the game itself. Meeting have become a mandatory practice that I have implemented due to all the benefits that comes with the meetings. As the team leader I also created the trello board for the team and created all the cards that need to be completed. The trello board was not used as much as I would have like last week for our 2nd proof of concept due to the fact of people just doing their own thing. So this week I made sure to let my group know that we have to use it more efficiently and frequently because we were having problems with keeping track of who did what, and what was done or not. I also created, for organisation sake, was a another google drive for our third concept so that everyone could drop the done work into the drive for everyone to access. Like all of the concepts I also conducted a brainstorming session once we got our idea so that we could get a firm grasp on what we wanted to attempt. I also had incorporated smaller sessions within our meetings for problems we had or for things that e wanted to add to the game. I really love incorporating these to our meetings because our group is full of critical and creative thinkers which makes them that much more effective. We have come up with some awesome ideas if were not for the help of the brainstorming sessions.

The other task that I was given for this concept was UI implementation for the score as well as coding. When we distributed the work load I really wanted to do this part because I had enjoyed working with the UI from our previous concept. So what we wanted for our scoring system was to have coins that they could collect like the endless runner: Temple Run. Instead of having three different we just wanted to have two sets of coins, so for instance we have a big and small coin. The big coin counts for 10 points and the small coin counts for 1 points. The way I coded the score was adding collision detection onto the player script. so how it work is that when the player collided with the coin it would compare tags with the object. So if the player collided with a small coin it would then add 1 to the score based on the tag it had. The same thing happens with the big coin. So whatever the tag of the coin was dictated the amount of points. Which was helpful because we could then add that into the interfaces and have multiple tags and essentially have numerous coins with different score amounts. Now the more trickier part of this code was manipulating the canvas text to show the score. So some challenges that I had with this code was not understanding how to go about it. so at first I wanted to type in the text and then add to the text. Which made sense in my head but did't work in the least. So I went on the unity forums to figure out a much easier to go about this. The funny thing was, was that i wasn't too far off with my initial idea. So basically within the code you had to manipulate the score text directly by printing score and then adding in the count. From there you made the text a public variable that you dragged into the script. other than that I did not have any other trouble with the code.

I did however try to work with interfaces. I was unsuccessful at trying to make them work. I went through many tutorials and forums to try and figure out how to implement them properly. Unfortunately I could not get a grasp on how to implement them. So I had to hand that part off to our lead coder Vivek, who was able to explain to me how to go about it next time.

The other thing that we had problems with was the shadows. As dumb as this sounds the shadows were not working what so ever. Fro some reason they were being turned off once the scene was being played. So Ian and I spent a good half hour trying to figure why this thing was happening. We fiddled with a bunch of stuff and did a few google searches but nothing was seeming to work. So we just started playing with a bunch of options and setting. Finally we went into the quality setting and played with the matrices and surely enough it worked.

We then tried to implement this on the master copy and sure as hell it was a different problem. So we went into the material shaders and noticed on top of playing with the matrices the shaders were set to transparent for some reason.

I am very satisfied on how this concept came about. It turned out really good. However if i were to visit this project again to turn it into a full fledged or prototype then there would be a few changes that I would like to implement.

One of the changes I would like to make to the game is the animations to the lizard and the moving objects. It would give the game a overall better feel and would make it more polished.

Another change that I would like to make to our game would be adding in more paths as well as different chunk shapes. Like temple run they have where you can turn and switch direction so that its not so linear. I think if we added that depth to our game it would make it a lot more fun and complete. because it gives player choice along with the endless runner feel. I would also like to edit the chunks themselves. What do I mean by this? Well basically we only have 2 chunks which are the regular path and the water path. I would at least like to add three more to give our runner some variety and more scenery.

A must change would be our player model. right now it is a dinosaur and we wanted to base our lizard off the "Jesus Lizard" or the basilisk lizard in proper terms. So myself and Ian would definitely model and animate the player model so that when it picks up a speed boost then it would look like the model is running faster and when it hits an obstacle then it would look like its slowing down. Also adding a jump animation would make it look more crisp.

Overall I am very happy on how this concept has turned out. Our team did an excellent job once again with getting their tasks done and implementing them on time so that we are not pulling an all nighter the night before the presentation.



 



       

Critical Analysis: Pirate Racing

Pirate Racing

Our proof of concept is a pirate racing game. The player is in control of the their prate ship racing against opposing player which are AI controlled. They have to manuever through the map dodging hazards and obstacles that stand in their way. To make things more interesting, the player has to be aware of the wind. The wind plays a key factor in our game. The winds blow from the north and from the south. So we have mechanic where you as the player control your sails. Using UI and particle effects to indicate the change in direction the player must drop their sails if the wind is coming at them and put them up if the wind is coming from behind. If the player does't put down the sails there will be a speed penalty allowing other player to surpass them. During the race they will come across cannon pickups which will give them projectiles to shoot at opposing players. The projectiles do not harm or kill the opposing players, they slow the opposing player(s) to slow down allowing the player to pull ahead. At the end of the of the map they will reach the finish line and will placed accordingly. 

I think the strong points of this game were the wind/sails mechanic as well fluidity of the boat in the water. 

The wind and the sails mechanic was a really innovative idea that our group came up with. because its a very realistic aspect of sailing that determines your speed and direction. I think we tweaked it so that it was fun and brought a timing aspect into our game to keep players engaged so that they do not fall behind. I think its also another take on racing games which is a breath of fresh air because I find racing games to be repetitive and boring because of just holding down one button. Now with this timing aspect of putting up and down the sails to maximise speed keeps players engaged and wanting to make sure they are hit every wind change to give them the edge on the other player. 

The other strong point of our game is fluidity of the water and how the boat moves within the water. Vivek did a helluva job on the water and the boat movement. He used some really complex coding that involved the meshes of the objects to simulate the water and how objects interact with the water. It really sets the feel of the game and makes you feel like you are controlling a boat in a sense. The motion of the water and the boat is very pleasing to the eye. Very well done.  

So our original idea for our racing game was to create a maze racing game. It required the player to race to the end of the maze before the "beast" could catch up with you and kill you. With a lot of talk and brainstorming we put this idea aside because although it seemed like fun the team felt like it was lacking in mechanic and novelty. We then eventually came up with the idea of a boat racing game that used real physics such as wind, water current, sails, rudder, etc. This seemed like a sound idea because it incorporated all different mechanics that we thought would be cool to explore and utilise.

As we began to talk more and more we realised that we biting off more than we could chew. So we decided to only incorporate the wind, water, and sails. From there we wanted to make it so that it was a multiplayer game. We were all for our game being multiplayer. Then we got onto the the pirate subject and then a whole lot of what if's started to come about. So from this we wanted to incorporate cannons into our game to get the pirate aesthetic. 

From there we divided up the the roles and went our own ways. The next meeting we completely revised our idea from using real physics to a user friendly game that only required the player to change their sails from up and down when the wind changed. The reason why we did this was it was way too janky and realistic which made the game not at all. We were all for this because it made for a better racing game. So we focused on the the main movement of the player and the how we would incorporate the camera to fit for the multiplayer gameplay. 

This also was changed. We found it too complicated to do split-screen and change the camera at the same time for 2 players. So we then decided to just use basic AI for our proof of concept and to focus on just one player. 

So we ended up with a single player pirate racing game which proved to be a lot of fun and balanced. 

I'm very happy with how our final proof of concept turned out. It is a lot of fun and i feel like its a novel racing game which incorporates a type of timing mini game within the racing aspect. This in turn forces the player to focus on the gameplay so that they perfectly time the sail switch so they can get the edge on their opponents. Like I stated before, I also think the fluidity of the water and the boat really gives the game a great feel which immerses the player further giving the game a better feel and gives the player a better playing experience. 

I think our game was a success. We do what we initially set out to do accomplish. Which in hind sight was a rally good thing because we kept revising our initial idea and questioning it and we were able to come up with this great racing game.    

     

Proof of Concept: Pirate Racing

Pirate Racing

For our second Proof of Concept out team was tasked with creating a concept that incorporated one of the following archetypes:

- Match 3

- Racing 

- Visual Novel

As a group we were pretty decisive on what we wanted to make. We chose to create a racing proof of concept due to the fact most of the group was against the other archetypes and also really wanted to attempt to create a racing game concept. 

My responsibilities for this proof of concept was team manager, UI implementation, and coding. However compared to the last proof of concept the work was broken down more evenly. This is due to us growing as a group and learning what everyone brings to the table. We also wanted to make sure no one got burnt out during this proof of concept either.

As the team manager I scheduled all of our meetings for the week so that we could get together to ask question, implement, solve/answer problem, and to make sure everyone is on track. Having these meetings is very beneficial for our group because it keeps us on track and doesn't allow us to fall behind with the work we have to do. Another task as a team manager is conducting group brainstorm sessions. This allows us to view all routes we can go with our game, code, design, etc. During the barnstorming sessions I used different techniques and methods such as mind maps, group discussions, diagrams, lists, and some different creative problem solving tools. These techniques prove very useful during our sessions because, as a group, we generate many novel and fun ideas. As the team manager I made sure that new trello board was created for our new proof of concept. The trello board proves very useful and helps the group with organisation, I think organisation is one of the keys to an effective group.

Some challenges that I was faced with as the team manager was meeting up for all the meeting that I had scheduled. This was due to personal matters, but i made sure that the meeting continued without me so that group could talk, implement and brainstorm together. The steps I took so that i wasn't left out of any details or decisions was having one of my group members relay back to me what had been said during the group meetings I was not able to attend. 

UI implementation was another one of my responsibilities for our proof of concept. The UI was pretty straight forward. The first part of the UI was the wind indicator. The wind indicator tells the player what way the wind is coming and whether or not they should put their "sails up" or "sails down". The indicators were as simple as two arrows. The green arrow represented "sails up" and the red arrow "sails down". In order to get across the up and down indicators was enabling the one arrow and disabling the other based upon the direction of the wind. I also had to create and implement the projectile count. So I did basically the same thing. All I did was disable the images when the the projectiles were fired and then enabled when the player picked them up indicating to the player how many cannonballs they had at their disposal. The last the UI element I had to create for our proof of concept was countdown phase before the race began. This was a tedious task and proved to be quite challenging. At first I tried to manipulate the GUI text in order to create a countdown but that didn't work. 

To solve my problem, I went through a few tutorials which helped me out quite a bit. Rather than manipulating the GUI text. It taught me how to use sprites and animations to get a across the countdown. It required a little coding that just checked to see if the countdown was in progress. If it was in progress, then all controls would be disabled until the countdown was done.

Coding was another one of my responsibility. All the coding was split amongst all of us so that not just one of us was bogged down doing all of it. This proved to be very helpful and time efficient for our group. My tasks within for the coding was the UI and projectiles. I enjoyed doing the projectile code because it was a lot more than instantiating an object. I had to incorporate count of the projectiles which proved to be a little difficult but with a little tweaking and playing around with code i was able to get it done and working well. The other part of the projectiles was the pick up that came with it. So basically what I did was give the player a max amount of 3 projectiles. If the player shot a projectile the count would decrease. Then if the player collected one of the pickups it would add to the projectile count and destroy the object. However if the player had 3 projectiles and decided to pick up another projectile nothing would happen and the pick up would stay in its original place for another player/AI to pick up and use if they did not have maximum projectiles. 

I did not have any serious challenges with this code. It was just a matter and tweaking certain variables and adding in constraints so that the count didn't get to high or low. 

Again, I am very happy with the turnout of the proof of concept. I think with some more work and fine tuning this game could be a popular racing game. It think it has some novel mechanics that make the game fresh. As wells as the genre of racing. Pirate ship racing is pretty cool. I know for sure if we were to continue with this game our group would make it work and create an outstanding game. 

Some changes that I would make to our concept would be to add in more wind directions. At this point in time we only have wind in the north and south direction. I think it would be worth while adding in east and west winds and seeing how it would play out and affect the overall feel of the game. 

Another change/modification to the concept is not being restricted to using mouse and keyboard. This really affected our overall design and how we went about creating this game. We wanted to have multiplayer very much. Which required us to take into account two players using a keyboard which is a bitch. This also put more restrictions on what keys we could use. And funny enough we ended up not incorporating multiplayer due to time and complications. But adding controllers would definitely be a thing we would add in to our game because it gives us more buttons to work with which means more things we can add into our game to make it more fun. 

I also believe adding in WAY more pickups would be beneficial for our game. Since its just a proof of concept and with the amount of time we had we just went with projectile because it was most fun and incorporated the slowing affect against opposing players/AI. Some of the pick ups that i would add in would be a speed up, immunity to wind, boarding (steal another persons boost/projectile), etc.

I am very happy with how our game turned out. My team did an awesome job as usual at getting work done and coming up with novel ideas for our game. Its a pleasure to work with them.  

Proof of Concept: Gravity Switch

Gravity Switch

For this assignment we were tasked with creating a proof of concept for one of the following archetypes:

- Platformer

- Card Game

- Scrolling Shooter

Our group decided to create a platformer that would use the core mechanic of manipulating the gravity of the player and the objects.

My responsibilities within the group were team manager, UI implementation, coding, and level design. In any group that I am in, I tend to take the role of team manager because I want to make sure that everything is organised, everyone knows what they are working on, scheduling, etc. That's exactly what I did for our group. As the team manager I led discussions about what our game was going to be;  how we were going to attempt to create our game; and what needed to done in order to achieve our goals. Using mind maps, lists, and trello we came up with many good ideas which led to us going with the idea of gravity manipulation. During our time working on the proof of concept I made sure that we had scheduled meetings so that we all knew what exactly had to be done and for people to ask questions and share ideas with the group.

Another responsibility of mine was level design. Ian and I were our teams level designers. We went about designing our level so that it would gate the player, teaching them how to play the game and how each ability is used. We also designed it to show what kind of puzzles they would likely see in the game if it were made into a full fledged game. Before making the level in Unity we both sketched up level designs and shared them with the group.We had them pick which parts they liked and didn't like about each of our levels. Ian and I then combined our levels to the specifications of the group and then started creating the level within Unity. We created the level so it became progressively challenging and so that the player could experience and test the full extent of the gravity manipulation mechanic. Some challenges that we had with this level was implementing puzzles that used the abilities of the player. The reason why this was one our challenges was due to not knowing if we could implement "Wall Walking" into our game via code. So we made two different levels, one level had "Wall Walking" gating and puzzles and one level that did not. However our main coder, Vivek, was able to create the mechanic via code so we went with the level that had the "Wall Walking" puzzles. Another challenged that we faced was the actual scale of the level. At first our level was way too big  so we had to scale it down. After we scaled it down we then realised the level did not have enough depth, meaning it was small and lacked puzzles to showcase our core mechanic. Part one of this problem was getting the proper metrics for the level. We based the scale of the level on the scale of the player. Which we should have done in the first place. The second part was adding in some more puzzle areas to gate the player and to make the level showcase the main mechanic more thoroughly.

Coding was another responsibility that I was tasked with. I did some simple coding for the game which consisted enemy lerping and re-spawning/checkpoints for the player. For the enemy lerping I reused some old code that I had and then modified it slightly. The modification that I added was a sine functions so that the enemy would look like its accelerating rather than having its lerp movement so linear and boring. The player respawn was fun to learn. I had some troubles with it at first because I had it so when the player died it would respawn at a given place. However it wanted the the respawns/checkpoints to be progressive in terms of when the player reaches a certain checkpoint in the level they will respawn there when they die. However the problem that I was having was that when the player died, regardless of where the player was, the player would respawn at the beginning checkpoint. So i went on to the Unity the unity forums to get some help on how to make progressive checkpoints. It actually was much easier than I anticipated. In simplest of terms, I had to place a trigger on the the checkpoint and when the player enters the trigger it would keep track of which checkpoint the player passed. Once the player died, they would respawn at the checkpoint they were last at.

UI implementation was the other responsibility I was tasked with. Spencer created the UI for our proof of concept and I placed it within our game. I made sure everything worked such as lives, the gravity meter, and the orb count. I also added in some fonts to make it look more pleasing to the eye. One of the things that I had a challenge with was programming the gravity bar. The reason why I was having trouble programming the gravity bar was because I had to try to understand and figure out code that Vivek created. The gravity bar had to gain gravity when the player collected an orb and lose gravity when the player inverted gravity or shot an orb. I couldn't figure out where these things were in the code nor how to implement it correctly. So Vivek and I worked it out together since he was the one to create the code.

Overall, I am very pleased on how our proof of concept  turned out. I think it brings a novel idea that can be expanded upon and can be created into a very fun game.

However, some of the things that I would fix/change with our proof of concept would have to be the wall walk. It works well for the proof of concept but it's a bit glitchy when you reach the top of the "gravity wall". I would change it so that once the player reaches the top of the wall the player gets a small force added to it so that it does not get stuck on the corner of the collider.

Another thing that i would change with our proof of concept would be the enemies. I would like to give the enemies an AI script to seek out the player when they are in a certain vicinity. I think this would give the enemies more depth and would also pose a more difficult challenge for the player while manuevering through the level.

I would also like to incorporate different types of enemies. In our early designs for this proof of concept we did have different types of enemies but it got lost during the development of the concept. I would like the to have a boss as well as enemies that can only be killed a certain via gravity switch and what not.

All in all I am very happy with what we did as a group. I think made an awesome and novel proof of concept and would love to continue working on it.

      

Critical Analysis: Gravity Switch

Critical Analysis

The design of Gravity Switch started off as a concept of being able to manipulate all sorts of elements such as water, fire, air, etc. We then came up with the idea of gravity and being to manipulate it. From there we decided that we would allow the player to manipulate the gravity of themselves and the objects around them to solve puzzles and manuever around the level in a new and fun way. The main mechanics of the game that we wanted to incorporate were gravity inversion, which allows the player invert their own gravity. And wall walk which allows the player to walk up vertical walls. Another part to our game was being able to shoot a gravity pulse to invert an objects gravity. 

In order to manipulate gravity, the player would have to collect gravity orbs to fill the gravity bar in order to use the gravity inversion and gravity shot. Each of these mechanics use up the gravity orbs which in turn gives the player motive to collect more orbs so that they can continue to move through the level.   

As group we wanted to make sure that the main mechanic(s) were solidified and worked nicely before we moved onto secondary mechanics. 

The definite strong points to our proof of concept would be the main mechanics which were the gravity inversion and the wall walk. These two mechanics make our game. The gravity inversion allows us to switch our gravity so that we can move around the map appropriately. It allows the player to progress through the map, avoid enemies and hazards, and solve puzzles. Same thing applies to the wall walk mechanic. It gives our game more depth into gravity manipulation. So rather than just being able to walk on the top part of the level we are also enabling the player to walk on a vertical wall. This opened up many new puzzles and level designs for us because it gave us a whole other dimension to work with. We created new puzzles and areas that you couldn't do with the gravity inversion solely which kept our concept fresh and kept the players who played wanting more. 

In previous versions we wanted to create a mechanic that allow the player to swing from one point to another. Kind of like a spider-man mechanic. We scrapped this idea because it really didn't fit into the the whole idea of gravity manipulation. It also was way too hard to implement properly with the time we were given plus the mechanics we had already decided on and started to create. However if we had more time I would've like to have implemented this sort of idea which gravity manipulation in mind because I think that we as a group would've came up with a really cool mechanic for a really cool game. 

Another change that we made to our game was not having two different types of objects. We stuck with the one object which was the invert-able box. The object that we scrapped was the regular one. The reason for this was because it felt like it was just there and doing nothing much of anything. The only thing that it was useful for was pushing it, using the players force, over top of the door switch. We also felt like we could just use the invert-able objects more and more effectively rather than having two types of objects. 

We had a really cool design for the gravity bar that we unfortunately had to change. The gravity bar had really cool mask that made the bar look very mech. However it ended disrupting the players view of how much gravity they had in the bar so we removed the mask.

Map size was another thing that we changed quite a bit. At first we thought that the level was too small. But once we allowed other students to play our proof of concept they thought that the level was too long. So we ended up cutting our original level in half so that it wasn't too long but also had enough content to showcase our full concept. This was harder than expected because we had the level all planned out to gate the player and showcase our full concept. However, getting the feedback from the the other students really helped us. It made us think on how we could condense and scrap certain areas to make concept short and sweet.    

I am very pleased with how our proof of concept turned out. We were able to implement all of the mechanics we wanted into our game cleanly and effectively which made our proof of concept so much more appealing and fun to play. The art assets also were done exceptionally well which gives the overall concept a nice feel and look.

But the mechanics and how we used the mechanics really sold this game to me. Being able to solve the puzzles and manuever the map using the gravity manipulation is very clever. And as the game designer it really makes us think how we can incorporate the gravity manipulation into a new puzzle or vice versa. I think we made a fun and novel concept that could be turned into a really fun game. I know that I would certainly love to work on this concept further and publish it either on itchio or steam.