Wednesday, October 15, 2014

Showcase : MonoGUI

MonoGUI is a GUI Library for the MonoGame framework that I've been working on for the past year.  The goal was to create an easy to use GUI system that was easy to skin.  I wanted the framework to be used in any game, and to give the developer as much flexibility as possible with how it looked.  On top of this, I wanted to do something new, and give the developer the tools to make the UI look as juicy as possible.  Below is a short video showing the progress made so far.


Seen In The Demo
-Ability to switch between 8 different skins
-Skinned animations when visual state (hovering, pressed) changes (size, position and color)
-Skinned animations on any event fires (OnClick, etc)
-Various different widget types
-Adaptability to different screen sizes

Finished but not Visually Evident in the Demo
-Matrix SpriteBatching:
    This is an extension to the normal XNA Spritebatch, that allows you to push transformation
    matrices without needing a new draw call.  It also handles keeping track of different variables in
    Begin calls as well as clipping rectangles.
-Spritesheet Animations:
    Every Widget is created from defined texture regions, and definitions as to how to respond to
    resizing.  Any source texture box can instead be a spritesheet definition, allowing the skinner to
    include animated textures.  Blinking buttons? flowing gradiants? It's all possible!
-Gradient-Defined Progress Bars:
    Define how a progress bar fills by using a gradient image.  The gradient will then use a fill texture
    to fill from black to white, based on the fill percentage.  These gradients can also be defined as
    animated textures, allowing you to have wavy, bubbly progress bars to use as health bars, or
    whatever you want!

Features to Come
Cross Platform Facade:
    MonoGUI already supports some, but will eventually support more commonly-used Platform
    Specific implementations of features such as In App Purchases, saving data and logging.  This will
    allow the game writer to minimize the amount of platform specific code in their game.
Skin-Defined Sound Effects:
    Allows the skinner to define sound effects to play on various widget events.
Visual Skin Editor:
    A small program (written in MonoGUI!) that allows easy visual editing of Skins.


I'm very excited to start releasing this open source project to the public, and see what cool things are done with it!  It should be ready for its initial release within the next few weeks.

Sunday, February 23, 2014

Showcase : Pixel Artist

Pixel Artist is a mobile game I developed for the BYU Mobile App Competition.  I made it over the course of two months.  All of my previous projects being more experimental, this is the first one I truly consider to be "commercially viable".  A gameplay video can be seen below.


Pixel Artist is a puzzle game featuring over 100 levels where you recreate various works of pixel art.  You jump around and swap colors in an effort to complete the level in as few moves as possible.  It features a relaxing soundtrack, and simple calming gameplay.  Give it a try on Windows 8 or Windows Phone 8!

Windows 8: http://apps.microsoft.com/windows/en-us/app/pixel-artist/20d2b726-758e-43c7-ad14-967158aca373

Windows Phone 8: http://www.windowsphone.com/en-us/store/app/pixel-artist/c706c8f3-695a-4074-9955-4950a3fa6927

Wednesday, January 15, 2014

Showcase : Santa's Sleigh

Santa's Sleigh is a game I made over a weekend for the One Game A Month website.  I wanted to make something small and simple, while keeping with a holiday theme (so I could maybe pass it off as a present to friends and family ;D )

The gameplay consists of reaction-jumping across rooftops in a randomly generated level.  There are several different 'patterns' of houses to give a varied experience.  On top of this, there are a few ways to get points.  The first is to just travel as far as possible!  The second is bonus points for every present delivered.  Santa will drop a present every time he lands on a roof, so this encourages the player to hit as many roofs as possible, instead of just skipping them and soaring over as large a distance as possible.  The third are small pickups that occur randomly.  These pickups (glasses of milk and cookies!) give a large amount of points when obtained, and occur in between houses.

All in all, this was a fun little project, and ended up being a game that's pretty enjoyable to play.  It can be found on the Windows 8 Store, as well as itch.io for standard desktop computers.

http://apps.microsoft.com/windows/en-us/app/santas-sleigh/e3950a20-cdc7-496c-9228-af50e1db5802
http://cardanis.itch.io/santas-sleigh


Sunday, December 1, 2013

Showcase : Defendable Walls (SC2)

Defendable Walls is a mod I made for Starcraft 2.  Messing around in the editor, I discovered a set of doodads added in HotS called Defensive Walls.  They were a set of modular walls that could be pieced together, giving a defensive position as well as a walkway on top for defenders to stand on.  I quickly started using them in my map, but soon discovered that they'd never been finished and that there were several problems with them.

(If you don't care about the technical work behind the mod, and just want to see it in action, there's a video at the bottom of the post)

1) Not all rotations were supported.  Using the walkways on top of the walls were enforced by custom footprints, but rotating the doodads often messed up the footprint, allowing you to walk through the wall.


2) Not all the models had been finished with collision boxes.  This meant that units walking on some of the walls would be in the model instead of on top of it.

3) There was an interesting set of models that merged with cliff edges, but these weren't compatible with the rest of the walls, meaning they'd always hit a dead end.

So I decided to fix these problems, as well as extend the concept a little further.

1) To solve the problem with rotations, I made a bunch of additional footprints that covered the possible rotation values of various pieces.  People using the doodads no longer need to worry about rotating the pieces and instead just need to choose the appropriate doodad.

2) The collision box problem was slightly more difficult to solve.  Opening the models in a 3D editor wasn't possible due to Blizzard's proprietary format, so I had to resort to other measures.  The SC2 editor has an option to create visual models as addons to placed units/doodads.  So when faced with a model that didn't have a collision box, I'd take a working model similar to the broken one, scale it to overlap perfectly with the other model, and then set it to be invisible.  When playing the game the additional model wouldn't be visible, but the collision box would still work, making the unit stand on top of the wall!  The one down side to this is that in the editor the models don't appear as invisible, causing them to look a little chaotic.


3) Fixing the cliff merge pieces led to my favorite part of the mod, the fact that every wall works exactly like a cliff would.  In SC2 cliffs are used to gain an advantage.  If I'm on a higher cliff level than you, I can attack you without fear of being attacked back, unless you bring a unit onto the same cliff level or bring a flying unit to give vision.  Cliffs also allow for interesting units called jumpers, which can hop up and down cliff levels.

I quickly took a merge model and gave it a custom footprint (previously they'd been implemented without one, being treated as a Terrain Object, the details of which I won't go into here).  The first problem I ran into was that the cliff the wall was placed next to would still be solid, making it impossible for units to walk from the cliff onto the wall and vice versa.  I added a "Ground" patch to the footprint, which overrides any pathing it's placed on to be pathable.  This overrides the footprint of the cliff, allowing units to walk straight over it.


The next problem came with vision.  Though the unit could traverse the cliff edge, it still counted as being a level lower until walking onto the higher level.  So you'd visually be up on a wall level with the cliff edge, but not able to see onto the cliff until you crossed the border.  The solution involved the "Placement Apply" layer of a footprint, that gives different options to change how the terrain under the footprint is treated.  One of the options here was "Boost Cliff Level" which allows me to specify a different cliff level for every cell that has this attribute.  I took the "Ground" pathing I made earlier, and applied this attribute to be one level higher than where the wall was sitting.  This meant that while a unit was on the wall, they were a cliff higher, giving them vision of that same cliff level!

I then took this a step further.  Another interesting option in the "Placement Apply" layer, is the Blocks Vision modifier which (surprise surprise) blocks vision.  If the unit is one cliff level higher than the vision blocker, it can see over it.  So I took the footprint of the walls and added a level of vision blockers around it (the part of the walls that couldn't be walked on).  This allowed the walls to be treated as cliffs in the vision blocking sense, where to see over them you'd need to be on that cliff level.  I also found that if I set the "blocking" part of the footprint to cliff rather than unpathable, this would allow units like Reapers to actually hop onto the walls (since the inside of the walls were technically a cliff level higher).  This is my favorite addition to the mod, and allows for some interesting gameplay opportunities.



One last problem I had with the cliff merge models was because of how the game handles the height of units on different terrain.  The game looks at the center of the unit, the terrain it's sitting on, and  then raises the height of the unit to be on top of that terrain.  The way the merge models were done, in order to position them on the edge of the cliff, the center of the model would actually be on the cliff slope.  This would cause the model to rise up slightly to where it didn't line up with the cliff anymore.  I solved this in the same way I solved the collision problem.  I made the doodad nothing but an invisible model, and then offset the footprint.  I then attached a similarly offset model addon, which was the actual model I wanted it to be.  This allowed the center of the doodad to be far enough away from the cliff edge so that it didn't gain any height, while still placing the model on the cliff edge.



All in all, this has been a long project (easily over 100 hours) but I've learned a lot about the SC2 Map Editor and had a lot of fun.  I'm excited to see what maps people make with the mod, and the interesting uses people find for it!



If you'd like find out how to implement the mod, as well as the download link, see this post on SC2mapster:
http://www.sc2mapster.com/forums/resources/data-assets/59847-defendable-walls/#p3

Showcase : Chrono Defense

Chrono Defense is a game I made for the Ludum Dare 27 Compo, using the theme of 10 Seconds.  It was my first attempt at participating in the Ludum Dare challenge.  It's an alternative form of Tower Defense where your units move and have different AI, and it's up to you to put them in proper situations.



I wanted to make a game that used the theme in a less obvious way than most (oh look! Each level is 10 Seconds!).  I'd already committed to making a Tower Defense game, so I decided to change how you "purchase" the towers.  Rather than use a currency, I settled on using a periodic purchase time where you could buy new turrets.  The catch is, you only have ten seconds to "warp" in new units and larger units take more time to warp in.  So the game pauses, you choose what units you want to fill up the ten seconds, as well as the order they warp in, and then place them on the map.  The game then resumes and throughout the next ten seconds your units warp in.  The units appear in order, so if you chose a seven second unit followed by three one second units, the one second units won't start warping in until the seven second unit.  This allowed tactical judgement in not only placing your units, but the order that you choose them in as well as place them.  Players have to think ahead to when the unit will actually become useful.  I added another level of strategy by making the units not just towers, but moving and dynamic.  They each have their own AI that you need to take into account when purchasing them.  All in all I really liked these mechanics and would like to expand on them in the future.

The Ludum Dare 27 Compo had 1436 entries.  Out of those entries, my highest placement was in Theme, which was 141.  Over all I was proud of my placement, this being the first time I'd done anything like this.

My other placements are below.

Coolness50%
#141Theme3.68
#239Overall3.41
#271Fun3.29
#298Mood3.08
#415Audio2.78
#508Innovation3.03
#705Graphics2.64
#750Humor1.94

The version I submitted can be downloaded at:
http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=26403

The last few hours of the competition I spent working through deployment issues I hadn't faced before.  Because of this, I lost time I was planning on spending on content (new levels, extra enemies, actually balancing the levels).  So the competition version had only one level which was next to impossible (though I did find a way to beat it), and had only two different types of enemy.

I spent a few hours after the competition ended (the same amount of time I would've had if I hadn't run into the deployment issues) finishing these content additions, to the tune of two more levels and an extra enemy.

I've made this new version available at:
https://dl.dropboxusercontent.com/u/85698531/ChronoDefense.zip
(If the game doesn't run, run oalinstal to install openAL, which is a dependency of Monogame)

One of the major time sinks I faced in this competition was GUI elements.  I spent a lot of time implementing buttons and screens instead of adding to actual gameplay.  Another time sink was the framework for entities and weapons.  I wanted to make something dynamic, and modeled it after the way Starcraft 2 handles units and weapons.  As much as this allowed me to be dynamic in my weapons and units, it took a lot of my time.

Either way, I'm happy with how the project came out, and I'm planning on doing a larger scale version of it sometime in the future!

Showcase : Stick Man Trampoline


Stick Man Trampoline is a small game based off of Breakout and Pong.  I wanted to make a simple game with basic but fun gameplay, allowing me to focus on other aspects of the game design.  I wanted to have a small project to experiment with making a game Juicy, and multi-platform programming.

The game was made over a month using the Monogame framework.  All the art was done by myself (hence why it's so simple), and the music was done by Eric Skiff (http://ericskiff.com/music/).

To make the game juicy, I tried to add animations to everything.  The player and trampoline are animated with satisfying jiggles and wiggles, and I made each level have a small animated portion (whether bubble particles or a shining sun).

The game currently compiles to Windows, Windows 8 and Windows Phone (though the current version of Windows Phone is having issues I haven't solved yet).  I wanted to build to Android and iOS as well, but that requires Xamarin which I don't have a license for.

As of the current writing of this, Stick Man Trampoline is released on the Windows 8 App Store, with over 10 000 downloads and a 4.2 star rating.  It can be found here:
http://apps.microsoft.com/windows/en-us/app/stick-man-trampoline/c4c04fd8-5436-40a4-983f-486bc9129d2c

You can follow the development of the game here:
Designing the Mechanics
A Juicy Experience

Sunday, November 3, 2013

Stick Man Trampoline : A Juicy Experience

A year ago I watched an incredible talk about making games "Juicy".  The entire concept of the talk was how much value you can add to a game by adding simple, often visual additions and details.  I've linked it below, since I think it's something everyone should watch.


So as I started working on Stick Man Trampoline, this talk popped into my mind.  The art I was making (with my very simple paint skills) was minimal at best.  I started thinking about how I could make the most of the simplicity in both gameplay and art of the game.  So, I decided to take that very simple art, and make it as "Juicy" as possible.

First off, I added a simple animation to the stick man.  Bouncing upwards, his arms and legs are tight, almost as if he's pencil-diving into the air.  As he reaches the apex of the jump he starts kicking his feet and flailing his arms until he hits the trampoline and goes into a 'pencil dive' again.  This simple addition added a new level of fun.  (I'm sadistic, and found watching the stick man flail his arms constantly to be very entertaining).

Next, I wanted to do something with the trampoline.  Originally, it was a simple black line.  Now it jiggles!  Every time you hit it, it'll wiggle up and down a little bit before settling back in.

Lastly, I wanted to create at least some level of narrative for the incessant jumping, so I made a few different random backgrounds to each level.  To emphasize on the "juiciness", I made sure to animate at least one thing for each background.  Bubbles float up underwater, the sun pulses in the desert, etc.

All in all, I really enjoyed this project.  The multi-platform architecture seems to be working well (I have, however run into some issues with Windows Phone that I'm looking into).  I also enjoyed the experiment in making a game "Juicy" and am planning on working this concept into my next project.