More Updates

I finished the first round of refactoring about a month ago and I think I've settled on a visual style that you might call "Oops All Gradients" or "Monument Valley-Ripoff". I wanted to rewrite my code to be cleaner because initial prototype had a bunch of ugly animation code entangled throughout the whole thing. I also avoided making any sort of visual tweaks prior to getting a full game loop implemented; I have a bad habit of getting distracted by visual elements.

I've gone wild with Singleton patterns in my code, and I have a bunch of Manager classes (BoardManager, GameManager, etc). This works pretty well for something small like this, but I know I'll be coming back and refactoring yet again some time in the future. As it stands, all animations are handled in code via DoTween and callback functions. I could use Unity's built in animation stuff (key frames on properties are great!), but I haven't devoted enough time to figure it out yet. I'm sure it's relatively simple, but I haven't been able to figure out how to use the AnimationController state machine stuff to just trigger a single animation without having to do a bunch of state transition and blending stuff.

I had a really great talk with some of my game dev friends, and they suggested moving to an MVC-type architecture. The idea is to move all of the game logic into it's own class/dll and completely abstract it from specific visual representation and input. Communication between the game model and Unity would be handled through input functions and a bunch of event hooks made available to an intermediate controller that would take care of telling Unity what to display. I'd lose a little bit of development/prototyping speed due to having to duplicate some of the state logic in the controller, but it would really help clean up my code and enforce separation of concerns. I could also easily write something to fuzz test game logic, or make a command line version of the game.

I've created a page specifically for this project, which I'm going to call "Blocks" (until I can think up a better name that won't run afoul of copyright claims).

New stuff

It's been a little while since I've posted anything new. Making a game a week is really exhausting and I ran out of steam around the holidays. When I was in the middle of my short game-creating-stint, I recruited several of my coworkers to play my games and give me feedback, and the thing I heard most was "you should spend more time on this game". Going forward, that's the plan. Having a deadline forced me to make progress but I also want to make sure I'm giving my ideas enough time to breathe, so I haven't decided on how much time I'm going to dedicate to each new project. 

The first project is exciting and fun already. It feels like it has legs and could actually be something I end up publishing. We'll see how it evolves.

Week 7

This will be a short post since I didn't get too far this week.

Idea: I saw this vine and thought "I want to make this; there's got to be a game in this". 

What went right:  I ended up with a pretty good starting point for something interesting to work on at a later date.

What went wrong: I didn't spend as much time on it as I wanted to due to the holidays.

What I learned: Music games are a lot trickier than I first anticipated.

Week 6

Idea: This was one of the ideas I came up with when I first started working on one game a week. I thought it would be fun or interesting to have to independently control a character's limbs to move them around. This one was most definitely inspired by GIRP 

What went right: I like the low-poly look that came out of this (lightmapping helps a lot). This is also the first time that I feel like I've designed any sort of level in a game that I don't think is terrible.

What went wrong: I got stuck trying add new mechanics with only a day or two left in the week, which really zapped my enthusiasm to try to finish the game. It wasn't until the last day where I was able to watch someone play the game that I realized that the climbing could work on its own, and I didn't need to add anything else in to make it complete.

What I learned: I need to design out my games before diving into execution; Most of the games I've made so far have fallen into the trap of bottom-up design. Games don't need to have a lot of complex mechanics or design to be fun.

 

Week 4

Idea: Every so often, I'll go on a flight simulator kick and try to learn (or re-learn) how to fly planes. DCS A-10, with it's fully clickable and functional cockpit, is a beast to figure out at first, but there's satisfaction in learning and becoming competent with complex systems. I wanted to see if I could create something that would evoke those same feelings. This idea has stuck with me ever since I worked with some friends on  a game inspired by Artemis. Role playing as a space ship's engineering officer and having ship systems modeled with high complexity is something I would love to be able to create and play with one day.

I realized pretty early on that this is a pretty big task. There are two games here: managing the subsystems that fit into the larger game, and managing the input for one of those subsystems. I decided that I would try to get the physical controls feeling "right" mainly because I didn't have a good idea for the larger game that could be completed within a week. 

What went right: Lot's of juice and polish. I was able to integrate feedback from friends and co-workers throughout the week, and I came up with a decent system for adding in new effects for each stage of the machine. 

What went wrong: Same story as previous weeks: too light on gameplay. I ended up with a poor version of Mastermind. The decision to have the order of the buttons randomize themselves at startup for each game for replayability's sake makes it difficult to give the player a feeling of mastery over a system. Instead, you wind up with players randomly pushing buttons and hoping to get some sort of feedback. I think I also got hung up on modeling systems too much and forgot about how those systems should interact with the larger game.

This week and last week could probably be parts to the same game, so I should probably try to break out of that pattern for the next few weeks.

What I learned: Lots of technical learning this week, especially for sound, particle systems, and lighting/rendering. 

Week 3

Idea: My idea for this week was a bit nebulous. I wanted to make a game in the vein of Space Alert where you have to manage the different systems of a ship under time constraints. I kept going back and forth on if I wanted to make a 'spinning-plates' sort of experience, or something akin to Space Trader, and I ended up with something trying to do a of both.

What went right: I can see the components of a fun or interesting game here, even though it's incomplete. I decided to try to embrace the fact that I wasn't going to finish the game, and tried to add elements to make the experience more absurd and comical. I'm pretty pleased with the music and sound effects, even if they sound cheesy or cheap. I'm also pleased with the way the in-game UI turned out even though it's incomplete.

What went wrong: I didn't complete my game for this week. I got caught up playing around with minor details in the middle of the week and wasn't able to get the full game loop figured out until my last day. Even if I could get everything working, I wouldn't have any time to playtest or tune to figure out what works and what doesn't. The presentation of game elements is a little convoluted, and I didn't have time to add enough UI or instruction to make things easier on players.

What I learned: I need to focus on figuring out and implementing the game loop as soon as possible. I got caught up in fiddling around with sounds and UI stuff without having a game to attach them to. On the technical side, I learned about creating custom assets in unity, which should prove very useful in the future.

Week 2

Idea: I've been wanting to make this game for a while, but the idea is not originally mine. In fencing class, we would play "Steal the Glove", which was essentially a 1v1 version of capture the flag. The coach would place the glove in the center on mask, and two students would try to either grab the glove and bring it back to their side, or tag the person who stole the glove. Part of the strategy was trying to fake out your opponent and get them off balance before you made your real move, and I wanted to try to capture the feeling of playing that game.

What went right: I'm happy with my implementation of the game. I was able to get the basic game hashed out early on and test out what rules translated from fencing class to my version. It's far from perfect, but I can see the core of something worth exploring in the future. It's been fun to play with friends and co-workers, and I was able to integrate feedback without much trouble.

What went wrong: The art could be better, but my focus was getting solid gameplay down instead of creating something with visual appeal. The game looks and plays a little bit like Hokra, which was unintentional, so I hope it doesn't come off as derivative.

What I learned: The feeling of a real world game is sometimes difficult to translate into a digital game. I was able to brush up on coroutines (which always seem to be something I have to re-learn each time I use them) and some of the new Unity 4.6 GUI.

Week 1

Idea: I've always been interested in procedural world generation, so I wanted to see if I could create my own world. The initial idea was to have the player try to survive as long as possible as they searched through an endless desert for food and water. In researching terrain generation techniques, I came across a pretty good tutorial on chunked terrain generation that implemented the marching squares algorithm. I had a lot of fun just flying through the terrain in the editor that I decided to focus on making a game out of it.

What went right: I more or less completed what I had set out to do, and the resulting game is actually kind of fun. I pushed myself to focus on getting something playable instead of getting fixated on premature optimizations or secondary features that don't matter as much. This was also my first time using Unity in a couple months, and it was nice to get back into it.

What went wrong: There's not a whole lot of "game" to it. I wanted to add in some actual objectives, but some of my choices ended up being limited by technical limitations and decisions I made earlier on. I also got stuck trying to solve some interesting tech problems instead of focusing on creating interesting/fun gameplay.

All of the terrain and collision meshes are generated at runtime as you move through the world. Unfortunately, Unity has to do a lot of behind-the-scenes computation when you assign new collision meshes, which means that performance takes a pretty big hit every couple seconds as new terrain chunks are created. The solution was to only generate collision meshes in a smaller area directly around the player instead of on every single chunk. Unfortunately this means that things like bullets and missiles become more difficult to implement since they would end up flying through terrain that is further away from the player. 

If I had more time, I could go a couple different ways with this. I could make it combat-oriented, or I could make some sort of racing type game.

What I learned: If I want to make fun games, I should focus on finding the parts of experiences that are fun and iterating on those instead of technical problems (which can be fun to investigate and solve, but don't necessarily lead to fun gameplay). I also learned a bit about noise algorithms and terrain generation. I'd like to tackle something like this in the future.