26k

Mini Hockey Champ! releases in 2 weeks on Steam!

store.steampowered.com/app/713030/Mini_Hockey_Champ/

NES Metroid has always been one of my favorite games of all time. I always loved the mystery of it all, the game does very little to guide you along your way. When you bomb a wall and find a secret room, it genuinely feels like you discovered something important. It was one of the first games I bought with my own money when I was a kid so I played it a ton. And I absolutely sucked at it. Never fought Kraid or Ridley. Never found more than 1 energy tank and a handful of missiles before I got smoked and had to start over again. I really never saw most of the map before getting frustrated and giving up. That is, until today!

Now granted, I beat the game on the 3DS, so yes, I save scummed the whole way. And it still took me forever, I only got Samus with her helmet off. But, I also found just about every item in the game (missed the wave beam) without a map nor any latent muscle memory since I never got very far as a kid. Despite seeing a million speedruns, none of the map stuck in my memory save a few notorious items (hidden tank in Kraid’s lair). When I found the Screw Attack, it honestly felt great, it was in a place I didn’t even realize existed as I was leaving Norfair after beating Ridley (who was surprisingly simple to kill). Just kinda stumbled my way into it. It’s an amazing bit of discovery that lacks in a lot of modern game design, or I should say, has been designed out of modern games so they are more accessible.

Not too long ago, I had foolishly planned to ship Mini Hockey Champ! in May. I started making lists of things that needed to be done and in a naive, nebulous way that timeframe somehow seemed reasonable. In January, soon after I finished the trailer and got through Greenlight, I had a moment to really analyze where the game was at and whether or not that date was still viable. And here we are!

MHC is my first indie game, but I’ve shipped a lot of games in my life in the AAA space. While incredibly smaller in scale, the overall process isn’t a whole lot different. To get a game out the door at some point you have to make choices about what is and is no longer critical to a game’s release. We scope and scale and ultimately cut down the game into a finished product.

In January I listed out everything I could think of that I wanted in the game and each item’s state of completion. From there, I ranked them by importance and created a consolidated list of features and items that were critical to ship. I came up with about 30 items and worked out a system to determine how ‘shippable’ each was. The image above shows the relevant portion of that list, where each item is assigned a number from 0-100. Anything 50 and over is considered shippable, meaning feature complete. Arbitrarily, anything 75 and over is earmarked as ‘polish’. Hopefully a fair amount of these tasks get some amount of polish time before launch.

Happy New Year! Mini Hockey Champ! is up on Steam Greenlight now:

https://t.co/WE5mMwpK0R

Today is the start of my winter break from work and I'm using that time to get Mini Hockey Champ! ready for Steam Greenlight in early January. I've been plugging away at an announcement trailer for the last couple weeks and it's finally starting to come together in a way that really shows off the game. Similarly, as a project it's beginning to crest that peak where a game stops feeling like a loose collection of ideas and congeals into a solid, cohesive vision.

For what it's worth, this is a game I've started and stopped working on a good 5 times over the last 12 or so years, each time going back to scratch trying to learn why it wasn't sticking, simplifying and refining along the way. In the beginning, it was primarily an issue of not understanding how to make games and getting lost in the frustration that ensues. Over the years I'd get inspired to try again leading to a few awkward iterations that maybe played ok but looked totally uninspired, or vice versa. I’d taper off to work on other game ideas and eventually learned how to code better and figured out ways to produce art without getting bogged down in the details that sink most personal projects. More importantly, I've learned how to relax and just enjoy the process in recent years. I started yet again in earnest back in February and finally here we are 10 months later with a real game that I'm confident looks good and is fun to play. If anything, it's a testament to being able to realistically understand scope while ruthlessly removing anything that stands in the way of completion. Executing on a vision is easier when the path is clear.

I've shown the game a few times now during various points of development, but never really talked about what the game actually is. At its core, Mini Hockey Champ! is an arcade hockey game born in the tradition of the fun, accessible sports games of last century. It's the type of game that you can sit down and instantly understand how to play within seconds, but hopefully get lost in for hours at a time. Games are short and furious, perfect for passing the controllers among friends on the couch, but also when you just want to play alone. The game has a full championship mode with playoff progression and stat tracking, so there's always something to work towards beyond the wins and losses. It also has an arcade mode with a host of unlockables that modify the game in fun ways. Most importantly, it's a hockey game made by a person who loves and plays the sport, so there is authenticity rooted in the arcade spirit. On the fly line changes should feel natural to anyone who is a fan of the game, just like knowing when the right time to step up and throw a big hit is or how to deke and go back hand, top shelf.

First art pass on the goalies is complete, for the most part happy with how it turned out despite spending way more time than I expected on the mask. 

I’ve been working on this for a long time, off and on, through the years in various incarnations. I think I’ve finally focused the idea down to something that’s still fun but also reasonable to complete. So ya, I’m making a hockey game.

My plan was to eventually swap out the temp buildings from the previous parts with nicely chunked, prefab building kits, making a sort of layer cake with ground and mid floors, topped with different roofs and frankensteined together across the city. Using prefabbed buildings would provide complete control of the interiors, which could also be broken into modular pieces and used in a similar fashion. This is a actually a really good plan.

So obviously I decided against it and opted to try and create the buildings procedurally too, because hey, why not? More importantly, it’s really labor intensive to hand make a bunch of buildings using tiles and after making one I gave up and decided to let the computer do it for me.

I created a simple set of tiles to get started, walls, doors, corners, etc. including variants for ‘closed’ buildings that wouldn’t have accessible interior spaces:

Each building was subdivided into yet another tile grid, in this case 10x10:

And then subdivided again based on its total footprint, so at a minimum each space consisted of at least 2 actual buildings:

I won’t go into crazy detail here on how this gets laid out because most of it builds off the concepts used to layout the city (considering corners, edges, etc.) The next step was to start substituting correct pieces and fitting them into place:

Then I started to add in some variation in sizes, starting on the x axis:

Then adjusting the Z size so that buildings would jut out in relation to each other and create a natural back alley behind them:

Add in windows and doors at random intervals, ignoring shared walls:

Finally closing off the structure with a floor and ceiling/roof. Notice how some buildings lack interiors, while others have front doors but no back exit:

Then I built off the footprint of the bottom floor to grow vertically, using randomly sized ceiling pieces to alter the Y scale of the buildings:

Driving around town:

Interiors looking out to the street:

Overall the city has a nice density to it, with a good mixture of interiors and negative alley space created for the player to explore:

I’m pretty happy with how this is looking! Just to be safe, I should probably check how the overdraw looks on th...

ohhhh, right. Right. Riiiight. So all those interior spaces have backfaces and windows and doors and thousands of tile pieces and, well, we have a problem don’t we? This is only one grid too, for a city we’re talking 4+ of these and since we’re already killing it on performance, imagine all those layered in above?

The trick with dynamically generating content is that while you gain flexibility and variety, you give up the built in controls the engine provides for optimization, features like baked culling volumes. But before all that, I absolutely need to clean up my tiles, starting with eliminating backsides for exterior-only locations. I have to consider eliminating tiles in repeating sections and scaling instead, as well as seeing if I can do something about sharing repeated vertical geo. I most likely will have to write a system to LOD/impostor buildings in and out when they’re not in view or at distance. Ultimately, this is going to require a few different solutions working in concert and some mindfulness going forward on performance. If it’s struggling with my simple tileset, imagine the hit when I have actual geo in, plus textures, cars, AI, sound, fx, lights, etc etc...

In part 1, I was able to get the basic layout of a grid based city up and running. For part 2, I’m going to focus on cleaning up the distribution of buildings, namely the removal of orphans and islands. Below you can see both problems quite clearly:

Starting with orphans, we have buildings that are unreachable from the streets, for example the 2x2 blue building nestled within the lower left block wouldn’t really have a place to put a front door. I needed a system to be able to detect this happening, so the easiest way to accomplish this was to check where a building started and ended within the block. By definition, orphans can’t exist on the top or bottom row of a block, so I’m focused only on those buildings who’s start point isn’t 0 and who’s width is less than the width of the block. When I find one of those buildings, I simply remove them:

Pretty easy and I like the negative space it creates which will be useful later on, but we still have the larger issue of islands, a perfect example being the 1x1 orange building on the left edge. After weighing the pros and cons, I decided it made the most sense to just require that all blocks be larger than 1 in width and height. With that in place, let’s look a single block now:

Nice, that solves one issue, but it still leaves me with the problem of mid buildings that are the same width of the block. The 2 mid buildings in the blue block are problematic because only one side could open up to the street. So I implemented a rule that looked at the width of the block and if it found a building at full width, it subtracts 1. It’s a bit messy, but it works:

Now with orphans and islands eliminated, I can focus on building orientation. Doing so required 2 steps: First, I need to classify where on the block a building sits. Second, I need to be able to substitute buildings out when they get rotated and no longer fit the footprint. Similar to the orphans solution, before each building is made it checks to see where it sits x/y within the block, whether it’s on a corner, etc. It takes that info and then decides which direction to rotate. However, if you look at the buildings carefully, you’ll notice I have both a blue and orange building that are the same size. The orange building is 1x2 deep and the blue is 2x1 wide, which means they need to be swapped for each other when rotation happens, otherwise they’ll jut out. With that solved, the blue and orange buildings can be used interchangeably:

And a little detail of all the doors facing out correctly:

With everything put together, the city layout is starting to look solid:

A few years ago I started building a first person game where you could walk and drive around a little city, interact with items in the world, and the like. It was fun to make but it eventually became tedious to hand craft every intersection, wall, and window despite how much I enjoyed all the ideas that came flowing out during the process. Recently, I started to feel the itch to give it another go but this time I wanted to try and generate the world instead, focusing more on systems and content. Fair warning, you’re probably not going to see anything complex or groundbreaking here, but if you enjoy the idea of process, read on.

I’m building this on a standard grid, accepting the fact this limits the end result to a degree, but my goal is to make a game that takes place in a city, not city-generating game. Let’s talk hierarchy real quick, because it’s important. At the root, I have an empty GameObject called ‘world’ which will act as the parent to the entire city, giving me control of scale. Everything is made at a scale of 1 in Unity. The city for now is 2x2, broken into 4 chunks called grids:

Each grid is divided into 4 blocks that are made to fit within the grid. I have some control over the size of the blocks which will come in handy down the road. After the blocks are defined, I place 4 nodes around the block, 1 at each corner:

I’m visualizing the nodes above, but they will eventually become invisible triggers. These can be used for things like nav pathing, but right now I’m going to use them to build my streets:

The nodes and blocks are placed into an array, and from each node I run through the city looking for either blocks or nodes. This is accomplished by searching up and then right from each node (down and left are covered in the process). If I hit a block, we skip to the next node. If I hit another node, I store a connection between the 2 and then build a road between them. After all the roads are built I look at each node’s connections and based on the number made, I place an appropriate intersection tile at its location:

With roads squared away, the next step is to subdivide the blocks into buildings. This part of the implementation is super basic and will be improved as I go, but in the interest of getting some framework done, the first step was to evenly divide the blocks into 1m buildings:

Each building knows how much space it occupies, so they in turn instantiate the appropriate geo for that size: 

I’m using prefab buildings of different sizes, but later on this should be flexible enough to kitbash buildings on the fly or possibly even procedurally generate unique layouts entirely. For now, we’re sticking with prefabs:

For visualization sake I textured the streets so the sidewalks and intersections were more apparent and wrote some rough code to orient buildings so their ‘front’ faced the street:

Which only kind of worked, since what is the ‘front’ of a building with two open sides? The last step is scaling the entire city up via the world object. The tiny blue dot in the left corner is actually a car.

I’ve reached a good stopping point, but there are some obvious issues with the building layouts, namely the orphaned buildings in the middle of larger blocks. Currently, I’m only fitting buildings into the height and width of the block, but my next step is break the block out into another array and do some combining logic on neighboring buildings so orphans won’t be an issue. I’d also like to add alleys that cut through larger blocks as well.

I used to make a new google doc for every project I started. At some point, I realized instead of creating a holding space for brilliant ideas itching to be made, I was really just planting another tombstone in a graveyard of projects never to see the light of day again. Once you commit words to the page, all the bullet points quickly become this impossible task, crushed under its own weight of perfection and scope control. So I stopped doing that entirely about a year ago in favor of a inconspicuous text doc on my desktop, filled with indecipherable shorthand bunched together from a multitude of games I've tinkered with over the last 9 or so months.

I spent most of my winter break rapidly prototyping ideas I wanted to get started on, 2 to be exact. Maybe 3. There was also Motor Money Crash, which is still a thing I want to make. So, 4? Anyway, I spent December being really productive, but ultimately not really producing anything other than frustration. Starting and stopping is nothing new, I’ve been doing it for over 12 years now, but it got to the point where I realized I was no longer restrained by ability, only time. I have very little time to make anything.

Ideas are worthless without execution, evidenced by my prolific google docs collection. At some point, probably close enough to the end of the year where I could admit to making some sort of resolution but won’t, I decided that execution mattered most and I would make it my goal to ship a game this year. Ship, as in ‘make a complete game and attempt to sell it somewhere for money’.

Once you get past all the romance of anything new, you can see it for what it is and then decide if it’s actually worth pursuing. Of all the things I’ve made over the years, one prototype I started about 4 Decembers ago I absolutely loved, but didn’t know what to do with at the time so I iced it. It was too simple. Last December, it finally dawned on me. This simple idea was the only shippable game I’ve ever started. This is something I can actually finish.

Continuing on from yesterday, the next step is to start scattering objects over the surface of the procedural terrain, starting with trees. The easiest way to accomplish this is to place a tree at each vertex point, modulated by some density setting, and then filtering out which vertices should be considered invalid for what you're scattering. Since these are trees, it makes sense that we skip any vertices that are below sea level

you had one job

That's better. But, it still feels a bit mechanical, so I switched up from the vertices and instead placed a tree at each triangle's centroid (which is my new favorite word).

Better, but probably a bit too dense. So I cut the density in half and the distribution starts to feel a bit better. I also started diversifying the materials to separate everything out

For the last few days I've been working on a procedurally generated terrain system in Unity, something simple and clean that would add some variety to the game I'm currently working on. After brushing up on mesh generation in Unity a bit, I dove in head first and created this

Yuck, not what I expected.

After a bit more research, mostly on smoothing groups, I learned that in order to get faceted surfaces (something you take for granted working in and through a 3D app) a mesh can't share vertices, which meant the really clever and efficient system I made to generate the above was useless. So after a bit of this

I figured out a way to assign vertices that shared space an index number, pushed that into an array and got this

which quickly became this

the water plane being a separate piece of generated geo using the same code. This suddenly was looking promising, so I switched over to an orthographic camera, upped the poly count and starting getting results like this

with each vertex in a linear index, I run them through a simple sin function using their an x/y coordinates, upped the poly count again to get this

which is starting to get where I want to be. After a few hours of adding finer controls to the generator, I'm starting to see the kind of results I was hoping for. It doesn't have enough knobs yet to get the geographic diversity I eventually want, but it's starting to come together in a nice way. I left off with upping the poly count 1 more time along with the overall size of the generated space, resulting in this