Chad Cable's Dev Blog

A daily-ish dev blog all about my current side projects. You'll find it's an ecclectic mix of prototypes and "covers" - both of which serve to help develop and improve game craft!

[chadlycable]

Composite Lumber

Despite having a functioning cutting system, I couldn’t rest until the plank was a proper dynamic mesh!  This is definitely not the most pressing issue (that honor goes to the whole is-this-prototype-any-fun portion of the prototype) - but I couldn’t stop thinking about how to implement the mesh.  So I decided to get it out of the way first.

Turns out the mesh generation is a little more complicated than anticipated!  My original plan was to generate the border shape, from which I could use any number of methods to turn into a series of triangles (Like Ear Clipping or Dulaunay Triangulation).  Finding the border of a single shape was relatively simple.  The complexity arose as soon as shapes had internal holes.

Here, my algorithms started to get hung up and crossing paths.  After discovering some odd edge cases in my original fill algorithm, I rewrote it using the Scanline Flood Fill.  This provided the benefit of discovering the edges of a shape during the flood step.  With a few changes I had the fill “stamp” edges to make building the shape loops easier.  What this doesn’t account for, however, is single pixel rows.  Suddenly loops are sharing data and crossing streams, often resulting in infinite loops.  An inner shape “jumps tracks” to the outer shape and never looks back.

After several attempts to correct the behavior, I instead took a step back and thought of a simpler solution.  Rather than build a shape, I’m turning pixels into quads.  To reduce the number of quads generated, some optimizations are in place - like expanding in width or height.  There’s still plenty of optimizations to make, but good enough for a prototype.

Beyond that I also added in some “smoothing” triangles to make the cuts look less like a grid and more like an actual piece of wood.  This algorithm analyzes edges and builds triangles over n number of blank spaces.  Once again there’s a lot of optimizations to make, but much better than before.

The result is kind of mesmerizing (Often the outcome of dynamic meshes).  It’s pretty wild to see the logic get carried out frame by frame like magic.  And even though this step wasn’t entirely necessary, it makes a pretty substantial difference to actually see through the holes you’re cutting.

[chadlycable]

Jigsaw Pieces

After building mobile games for years, I have a bad habit of forming ideas in touch and portrait.  Not that there’s anything wrong with mobile games - rather creatively I seemed to only be working in a single format.  Especially since many (if not most) of my favorite games use a controller.  Which is a long way to say it’s time to break that habit!

My focus over the next couple of prototypes is to think about the vertical Joycon - a control scheme who's charm is only matched by its silliness.  That means having a single joystick and a single button to work with.

While it doesn’t yet have a use for the button, one idea was to control a jigsaw cutter.  Players can tilt the stick left and right to guide it, but are constantly moving forward.  To stay in the game, you must keep cutting - hovering over empty sections will cause the jigsaw to slowly sink.

It was also a fun excuse to learn about “fill” methods.  Eventually I want to represent the planks with dynamic meshes, though for now I have the internals represented by a texture.  The anchor points on each plank determine which parts get filled in by recursively branching out from their position.

That is until I quickly ran into stack overflow errors - turns out recursive fill methods are pretty expensive!  I searched Google for more effective solutions, and was able to quickly implement Web Rarely’s method.  Not only was the prototype back up and running, I also learned a little something new.  What a world!

[chadlycable]

Scaffolding

One of the things I liked most about my last Morse attempt was having a range of visual cues based on the player’s progress.  The idea here is to provide less and less cues as you become more familiar with a symbol.  

Level 1: Outlines and length.  This is how you’ll be introduced to new letters, so you’ll see the outline of the symbols as well as the length of the code.

Level 2: Length only.  Now that you’re a little more comfortable with the symbol, now you’ll only see the segmented black background.  This tells you how long the code is, but you’ll have to remember where to Dit and Dah.

Level 3: Nothing!  At this point you’re a pro, so you'll be working entirely off of memory.

While the idea is the same, the execution has definitely changed.  I was never happy with having the bars slide in from the side, since you’re able to see the transition.  This time the bars will transition onscreen, meaning the bands will change their size, position, and opacity based on the incoming symbol length.  The timing isn’t quite there yet, but I’m happy with the overall look and feel.

For the sake of simplicity, I’ve also decided to have the entire screen be a touchable area.  While I like the idea of a button, having to animate the button to the object is pretty cumbersome.  It also divides your attention between the two extremes of the screen.  Now, you’ll see the letter, and then with each input slowly move your eye down the screen.  I’m torn on whether of not the “active” line should be highlighted, to help crystalize the focus.

I’m also going to see whether I can get away with only using color when failing a symbol.  In my last attempt I was using color to differentiate Dits and Dahs.  That’s helpful in differentiating the symbols, but it makes signaling success and failure a little more muddy.  With real Morse code the sound is always the same, with the length being the only factor.  So maybe it’s worth embracing that visually as well?  

[chadlycable]

More Morse

It seems that I have a bit of a prototyping white whale.  Specifically, I can never seem to “crack” making a game to teach myself Morse code.  I’ve tried it several times before, and even blogged about one of the attempts.  To say nothing of how outrageous it is to be hung up on learning Morse code of all things...

Part of the charm is from the simplicity of the idea.  There’s only two types of input available, and only 26 letters in the alphabet.  This should make for a straightforward, quick turn around, efficiently scoped project!

But where my mistake before was to add layers and layers upon the base game, I never started by trying to nail the actual input.  Who would have thought building a meta game without a solid toy underneath would be an exercise in futility, amirite??...I’ll see myself out.

With this newfound realization under my belt, I’ve decided to take another crack at the idea!  90% of the game is about generating the Morse “pills”, so the visualization needs to be robust and thought through.  In order to have the proper amount of control, it was time to bust out some dynamic meshes.  The number of points on the end caps dictate the number of sections in the body.  The mesh can even be hollowed out, allowing for yet more options!  I also threw in some “jitter” to the mesh, because I may or may not have been playing a lot of Okami, and decided to mimic the style.

I’m happy with how this turned out, but felt like there was more to be done.  Since the main input is expanding the pill, I added “elastics” to the mesh.  Expanding the mesh will cause it to stretch and thin out in the middle, while compressing it will make the center expand.  Definitely makes the mesh feel more dynamic!

The next biggest event is bringing the pills in and out of the screen.  Ever since I “covered” Donkey Kong Country Return’s stretchy UI, I’ve been looking for an excuse to use it in one of my own prototypes.  Simply scaling the meshes like I did before was easy enough to hook up...but doesn’t take advantage of the dynamic meshes!  Now the meshes are able to “ripple” when compressed, like an accordion.  This looks better, though it’s starting to feel like a bit too much.  Don’t get me wrong, it’s been super fun hooking this all up!  It’s just starting to call too much attention to itself.

Which brings us to the GIF at the very top of this post.  The biggest change between them is adding the ability to “stretch” the pill when it’s moving quickly.  That, and about 100 or so small tweaks across the mesh and it’s many, many, many properties.  Overall I’m happy with the progress!  So far it’s been a more engaging development process, and should hopefully lead to a more engaging game!

[chadlycable]

Let’s Get Physicsal

Even though I got the basic input system working, I quickly realized this game is in desperate want of a physics-ish driven character.  True, there’s probably a version of this game that works on a flat surface, but having to worry about obstacles and hills seems like the more natural fit.  

I started by trying to add physics to my existing controller, which was a huuuuuuuuuge mistake - mainly because there were far too many moving pieces!  Trying to debug what’s wrong with the collisions is already hard enough, but add in a strange locomotion system and it becomes tough to know what’s actually at fault.  And while I’ve done one or two 2D character controllers, this was my first 3D one.  This strategy was biting off too much at once.

I scrapped this version and decided to get a simple character controller working first.  After getting in over my head with the custom raycast solution, I ported over my WIP character controller from my Pushmo cover.  This version uses the built in Unity physics collision, but overrides the velocity information.  That way I get all of the collision detection for free, while retaining the necessary control over movement and physics manipulation.

One change from Pushmo is the addition of hills and ramps.  Previously I was directly setting the X and Z velocity values, but this resulted in the controller walking out into thin air when going down a ramp.  For this, I’m remapping the input along the current surface’s normal.  Now when walking down a hill, the velocity is remapped to match the slope, preventing players from walking into midair.  A nice side effect is that player’s movement is maintained along the surface, rather than some of it being “consumed” by walking into the slope’s collision.

With a character controller in and working, it was time to add the physics component.  Rather than directly applying the velocity, players are inputting forces.  The control is much spongier...but that’s also kind of the point.  Collision remap velocity based once again on the surface’s normals.  Hitting a flat surface will kill the velocity, while hitting a slop will redirect it.  Hills are suddenly much harder to climb, because gravity is overwhelming the player’s input speed.  All of this work was a bit roundabout, but it’s very exciting to see it working!

The last portion I wanted to get working was respecting the direction of the player’s skates.  After all, it seems weird that you would slide down a hill if your skates are perpendicular to the slope.  Right now it’s as simple as remapping the current velocity by the player’s direction - though this results in losing a lot of velocity.  I think this will be resolved with my original input, since players won’t be able to turn on a corner and simply lose their momentum.  Once I merge my original controls, this may need revisited.

Goes to show the power of doing things one at a time, rather than all at once.  My original tactic was definitely becoming a hopeless mess!  Thankfully I stayed cool and collected and decided to build a simpler, better foundation before moving onto the more complicated parts.

[chadlycable]

Coasting

Though I never owned one, I imagine I would have adored the Dreamcast.  If nothing else it had such a distinct house style, with every game having an alluring look and feel and world.  Everything is blue, bright, and in the full swing of summer.  And since it’s already summer, what better way to celebrate than to make something embodying the Dreamcast??

The core toy here is the skating mechanics - holding the left or right side of the screen pushes down the respective foot.  Putting down your foot increases your overall velocity, and holding that foot down over time will turn the player.  These two rules offer lots of expression - whether it’s quickly going back and forth between feet to gain speed, or leaning on a foot over and over to curve in that direction.  Something about moving your finger in figure eights seems really satisfying.

While eventually there will be hills and obstacles and that sort of thing, I wanted to get the movement feeling terrific.  As always, I started by driving everything by springs.  Each foot is comprised of two: one for lift, and the other for turns.  While this makes them animate nicely, it’s not really giving me the tight, arcade controls I’m looking for.  I’ll likely end up redoing this part.

Originally I thought left and right movement should be tied to how far you drag your finger away from the center of the screen, but that knocks out two handed play.  Instead this is tied to how long you hold the input.  This works for a first pass, but needs a whole lot of love before feeling just right!

Other than that, I spent a little time doing some silly feedback things:

Making sure the skate wheels rotate properly based on distance covered (Thanks math!)

Adding trails when the feet are along the ground.  This was easy enough with Unity’s Trail Renderers, though getting them to properly “normal” needed a little work (The root transform needed rotated, and then positions needed to be converted from world to local).

Putting lots of little touches on the speedometer UI.  Right now player speed is drastically overturned, so I wanted a quick way to see just how much speed was changing with input.  And if I’m already hooking up a UI, why not add some movement, and a gradient, and text shaking?  Spring cleaning, amirite?

A good start - but lots and lots (and lots) of polish to go!

[chadlycable]

Order’s Up!

It’s been a while since I was able to do some polish work, so it was fun getting to reflex that muscle!  Most of the work was cleaning up odds and ends, which help make the game loop feel more complete.

Much of the heavy lifting was around the customer’s speech patterns.  The first pass had them essentially just rattling off the ingredients, which didn't make for the most elegant or natural sounding requests.  To help with this, I tagged the ingredients as either “normal” or “use with”.  This determined whether the ingredient came before “coffee” like “black coffee” and “decaf coffee”, or whether it came after, like “coffee with cream” and “coffee with room”.  The implementation is subtle, but goes a long way.

On top of this is a ton or randomness options.  Every string is part of a text bank, allowing for a range of strings for every part of the sentence.  Different “ands”, different “withs”, different “greetings”, you name it.  There’s also options for text speed, which impacts how quickly or slowly the requests animate.  If they talk fast enough, they can even get their text to shake in place. And because I clearly have nothing but time, sometimes the customers will talk about something besides their order, forcing players to wait for the real text.

The next area for improvement was adding in additional items.  For now it’s just another type of cup, which has a different list and layout of options.  The dream would be to have a whole assortment of items, preferably having nothing to do with coffee.  Like customers who come up with an autograph book, or the cable company appearing with your latest bill, etc.  Basically anything requiring your signatures, since this game is all about handwriting.

There’s an additional keyboard option as well.  Since players may find their handwriting incomprehensible, there’s an “Orders” keyboard.  Here you can call out the ingredients on the cup in hopes of getting the order served.  This would have been impossible to do on the native keyboard, so it was worthwhile work getting the QWERTY keyboard working in Unity.

Other than that, a lot of little touches.  Putting some feedback/wind lines into the callout sequence.  Customers responding to “bad” orders where you callout a non-existent name.  Adding in customer textures.  Fading out customers when entering and exiting.  Having Easy, Medium, and Hard modes defined by a difficulty curve.

That said, while all of the parts are interesting, they don’t feel great together.  In large part, you need to constantly shift between the two counters which totally breaks any sort of flow or process.  By the time you understand where the options on the cup are, you need to change gears and decode your handwriting.  A more fun version would most likely be in multiplayer, with one player writing down names and the other calling out orders.  This provides focus to both players, while also heightening the transcribing game.

In the meantime, feel free to try out the WebGL version here!

[chadlycable]

Text to Speech

An idea?  Check.  Drawing support?  Affirmative.  Object manipulation?  Objectively manipulating.  A loop?  Uhhhh, not so much!

I like the interaction of drawing on a cup, but to really test the game I need a good reason for having to draw on the cup.  Crossing off the proper boxes on the cup feels like an obvious, natural mechanic.  The problem comes with the name, since there’s no way I’ll be doing any handwriting recognition.  To turn this part into a game, I decided to have players type out the name they just wrote down.  This game becomes about managing speed with clarity.  Write quickly to keep customers happy, but not so quickly that your handwriting becomes illegible.

Part one was properly detecting where players were drawing on the cup.  My first thought was to attach colliders to the model itself, and then see if the player drew through any of these sections.  This solution felt too labor intensive however - making changes to the texture would mean repudiating the model colliders.  Instead, I decided to base it off a secondary “lookup” texture:

On the Unity side I keyed each "ingredient” with a specific color, trying the two pieces of data together.  Because I already know where on the UV the player is drawing, the lookup into the secondary texture is trivial.  Plus, this system is super simple, allowing for quick, on the fly changes to layout (Or even number of ingredients).  This system will work regardless of number, position, or even shape of the model.

Part two was getting a reliable keyboard.  While I could have used the native keyboard, that requires letting go of all layout and flow control.  That, and I was curious to see how quickly I could get one working!  Getting the keys onto the screen was the easy part - each row is given a string, with each character in the string representing a key.  The bigger problem came from my arch-nemesis, Unity’s input system.

The biggest challenge came from handing input back and forth between the keys.  I ended up using a similar solution as the Sushi prototype, where the keyboard background acted as a backup input catchall.  Dragging off a key hands over the input to the background, while dragging onto a key hands it over the new key.  Releasing on either the background or the key notifies the other, in order to ensure the events are properly logged.  This is important for ignoring “OnEnter” events, since as far as I can tell there’s no way to know if a touch is “down” (Obvious on a touch device, but not so with a mouse).

From here, I’m looking forward to polishing up a lots of odds and ends, as well as implementing some sort of difficulty curve.

[chadlycable]

Mocha-inations

Even though it’s still early days in the prototype, the game was begging for at least some artwork.  While it’s cool being able to draw on a cylinder, it’s nothing like drawing on a proper cup.  Especially since the interaction is all about drawing on specific parts of the cup!  So I took some time to get basic assets in - namely a real cup model and texture.

The next challenge was getting more of the gameplay flow in.  With the cup taking up so much screen real estate, I wasn’t sure how to tackle “submitting” the cup.  I also wanted the ability to discard cups you didn’t like.  The cleanest solution was being able to drag down the cup back to the counter, and from there make a choice of what to do - trash it, submit it, or re-edit it.  You’re able to drag the cup “halfway” in order to see the customer, which should be useful for reminding yourself of their name or order without having to place the cup back on the counter.  The placement of the drag section (at the top of the screen) is problematic on iPhone though, since it trigger’s the notification tray.

I also decided to make the “up close” cup and the “counter cup” two different objects.  This was mostly to separate the complexity, since the two only overlap in visuals.  The “up close” cup gets all of the drawing support, which needs things like a mesh collider and render textures.  The “counter cup” gets the drag support, with things like a hover state and particles.  I’m pretty happy with the solution, though it required some back and forth between the systems to ensure the small things remained consistent...like the current rotation of the item.  Having it “reset” it’s rotation completely broke the connection between close and counter.

And would it really be a blog post without additional updates to the touch implementation?  My original assumption was that touches that “leave” an object should simply release the object and look for a new touch target.  But now that you can drag cups around the counter, that will by definition force you to leave the cup’s collision volume.  World widgets now are now asked if it’s okay to release the touch on “exits”, so that objects like these can keep holding onto the touch even if the finger isn’t over the current object.  That way, you can drag at any speed while still receiving the input!

Basically, I miss the touch system Walaber implemented back in the early Unity days, before they had a proper UI system (*shudder*).  It was the same system we used on Where’s My Water?, which allowed for setting touch priorities (allowing you to override typical distance checks), work between 2D and 3D objects, and hanging onto touches after they left the collision volume.  More than anything it helped to obscure and systemize touch input to the point you can simply fugetaboutit.  I tend to redo it on every prototype...but it might be time to make it modular.

Next up is getting customers customizing!

[chadlycable]

Spin to Win

With drawable objects in the proverbial bag, I turned my sights to getting the full gameplay loop implemented.

Behind the scenes, it meant redoing my touch detection.  Since I wanted more control over filtering (spherecasts > raycasts for Big Ol’ Fingers™), I abstracted out the drawable surfaces into a more generic widget class.  That way all of the objects in the scene would be interfacing through a single system, making for a clear line of communication between who owns what touch.  And since I wanted to support multi-touch, there was some additional work to do there.

Once configured, it was trivial adding a new “rotate” widget.  This lets players freely rotate the cup by sliding their finger back and forth.  It seemed fun having it be a physical band, though the texturing and animation still need a lot of love.  Feel good having the fine tune control over the cup (As does being able to rotate and draw at the same time).

I also took Unity’s new Post Processing stack for a, uh, spin.  This definitely feels like overkill, considering I just wanted to blur out the screen when the cup is up close.  For now, I used the Depth of Field effect, and did a quick first pass on the transition tuning.  It gets a little blurry up close, so it’ll need some more love.

[chadlycable]

Pen to Paper...Cup

Toru Iwatani (the designer of Pac-Man) has a quote that I frequently return to and find inspiration from:

Around the time that we launched Pac-Man, video arcades were filled with games where you shoot aliens.  It seemed very dark.  It was for men, it wasn't fashionable at all....When you think about things women like, you think about fashion, or fortune-telling, or food or dating boyfriends.  So I decided to theme the game around 'eating'

Obviously for one, I should try to be more overtly stereotypical when talking about ladies, amirite?

Second, I love how he found an incredible game in an unexpected, but universal, activity.  Not everybody shoots guns, but everybody eats!  It’s so great how hard it is to unsee the inspiration as well - I never associated Pac-Man with eating, but now I can’t help it.

All of which is a long preamble to making a game about being a barista.  Specifically writing orders and names onto a cup.  And that requires mapping input to a model.

First off, I needed to map input to a model to UV coordinates.  Using a mesh collider made this process straightforward - cast a ray onto the model, and the mesh collider can point you to the UV coordinate.  Easy!

Turning these inputs into a line was...far trickier.  Below are versions one, two, and three:

All three of these are evolutions of trying to write directly to the texture using “stamps”.  When the UV coordinate is calculated, I go into the texture and superimpose another texture.  The biggest problem here is that none of this looks like a line, and instead a series of dots.  To fix this, each touch would interpolate from the previous position to the current position, drawing dots along the way.  In addition, I made the stamping areas much larger to try and cover the gap.  Each iteration was better, but not great.  It technically works, but has zero feel of a real life marker.  When writing is the whole point of the game, this implementation cannot stand!

Instead, I moved over to a mix of line renderers and render textures.  You can see the result at the top - much, much better!  Here’s what it looks like behind the scenes:

Now when the UV is calculated, an offscreen line renderer is updated.  The benefit of using a line renderer is that, uh, it looks like a proper line!  Plus, this will make it significantly easier to bend and distort the line to give it some extra expression, sort of like how Paper makes everything you draw 100x better.  When a line is completed, it essentially gets rasterized.

When there’s only a single point, a circle is put at the UV position instead, but gets swapped out as soon as two points are detected.

What you may notice in the top is that I’m drawing over the cup’s UV seam.  Since there’s no “invalid” UV position (that would be off model), instead I look for any drastic changes in neighboring UV positions.  If the distance is too great, the line gets rasterized and starts over.  There’s probably some work to be done in trying to make this transition smoother.  Or maybe I make the seam looks more like a coffee cup seam, where you’d expect the line not to be perfect.

[chadlycable]

High Rollers

There’s a lot of different pieces to build before Pocket Dice Rollers starts to resemble anything close to a game loop.  Knowing that the snowboarding section is going to take a pretty serious amount of work, I thought I’d start with the getting the dice game up and running first.

Half the fun of playing dice is watching the dice move and roll!  Even though it might end up causing headaches down the road, I decided to implement the dice as actual physical objects.  Already it’s clear I’ll have a lot of edge cases to resolve, and there’s going to be lots of value tweaks to make sure the game is fast and snappy and responsive.

Because the dice exist in both 3D world space and 2D UI space, it was crucial to have a data representations for the dice.  That way, dice values and textures and representations can be passed along as a group, instead of each system having it’s own way of interpreting the data.  This should also make it really simple to include new dice types - whether that means numbers outside or 1 to 6, or wild numbers, or special actions.  For this, I have a “DiceFaceData” Scriptable Object, which contains an int for the value, and a texture for the face.

The other dice interactions involved selecting and unselecting dice.  For now I’m thinking you’ll tap on the dice you want to keep, putting them up in the UI.  Determining the value is a matter of comparing the normals of each face.  Whichever face is the most “up” is set as the face.

Pressing the dice in the UI will place it back into the board.  To make sure I didn’t place dice on top of one another, I have a really simple sphere cast look over the grid.  It adds “valid” positions to a list, then picks a random one.  This makes it feel a little more organic, rather than filling the first open slot every time.

A good start...but lots more to do!

[chadlycable]

Pocket Dice Boarders

One of my favorite games in the last couple of years is hands down Pocket Card Jockey.  It’s supremely weird, and features one of my least favorite flavors of solitaire (Golf, blek!).  But I’m head over heels obsessed with it.  I’ll need to confirm this, but I believe I spent 80+ hours playing this game.  Game Freak should stop making Pokémon games so that they can continue making obscure masterpieces.

Unrelated to my adoration for PCJ, I got an iPhone for Christmas, after having pretty low end Android phones for a couple of years (Also a Blackberry Q10, because how could I pass up owning a square screen?)  Which means I’ve gotten back into the habit of playing phone games.  And now all I want is PCJ on my phone!

All of which leads me to this blog post, where I exclaim “I want to make a PCJ inspired game!”

For now, my plan is to mix a Snowboarding game with Yahtzee.  You’ll control the snowboarder through the track, and when it comes time to do a trick, you switch over to Yahtzee.  Which, by the way, has a great built in “don’t repeat a trick” mechanic.  There’s still a lot (see: a lot) or pieces to figure out, but that won’t happen until I get things hooked up.  Stay tuned!

[chadlycable]

Finding Love

After some quick play testing, my “rules” solution ran into a big problem:

They made the game reaaaaally difficult!

That’s because there was simply too much for people to figure out.  Not only did they need to figure out which petal had which rule, they also had to figure out what the rule actually was.  The latter in particular proved challenging, especially since some of the rules are hard to figure out.  And as more and more petals disappear, the rules are more likely to have edge cases.  All of this makes the game feel unfair, since the patterns are nearly impossible to reproduce from turn to turn.

So instead the game now clearly displays the rules for the round - though it no longer says which petal those rules belong to.  There’s still a lot lost in translation (I was too in love with the UI layout, which required really short sentences), but overall made the game feel much better.

Outside of that, I spent some time classin’ up the joint!  The intro screen slides in the rules around a flower petal.  The intro screen requires input from both players to start.  The petal animates in.  The petal “root” can be pressed to rotate the entire flower (The side petals are basically impossible to pull off on a phone).  The colliders were switched from boxes to 2D Polygons, making the back petals possible to touch.  There’s dumb, random text when someone wins.

Those small changes ended up making a pretty clear difference.  There’s definitely some room for improvement, like getting the rules to be legible to both players, or even having “test” flowers to see what the rule actually means. For now though, it’s all in a much better place than it was a week ago!

Try out the WebGL version here!

[chadlycable]

Single Player?  More Like Mingle Player!

With the basic input working, my attention turned to making this an actual game, rather than just an interaction.

First up was implementing the “rules”, where each petal has different behaviors.  This seemed like a logical first step in adding some variety to the game.  Otherwise it’s as simple as odd or even.  I added in a set of textures and colors so that each rule gets assigned a random petal.  

At first, the rules were fairly straight forward to implement - for a petal that removes its neighbors, I simply looked to the left and right in the petal list.  This quickly became an issue since a lot of petals look like neighbors, even though they aren’t in the data structure.  So I rewrote the algorithm to use the dot values, in order to determine which petal was closest in either direction.  Is the petals are closely aligned enough, they’re considered neighbors.  Dot product saves the day once again!

Next, I switched the game over to a two player game.  This reduced a lot of the complexity that would have been involved in a single player game.  The opposing player is what drives a lot of the interest - will they figure out the rules as quickly as the other?  Will they make a fatal mistake and not get the last petal?  If it remained single player, that would have meant adding a lot of additional systems.  Like giving players a random “date”, and they have to decide whether they want to fall in love.  And then there could be a risk/reward in how many chances you get to find love, so you start to gamble with what makes for a “safe” mate.  That could still be interesting...but multiplayer was a much quicker route to “game”.

For now, the rules are shown to the players at the beginning of each round.  Some rules are hidden, however, leaving it up to players to try and decipher what the rule is, as well as which petal the rule belongs to.

[chadlycable]

Pedal Plucking Action!

A little more progress on the “She Loves Me…” game - but now with 100% more plucking!

This iteration was mostly about getting more feel into the game.  Now when you drag on a pedal, it also offsets the base flower.  This goes a long way towards making everything feel more reactive, and provides a great “reaction” for when you finally pluck the pedal.  All of the values need a lot more tuning, but a good start!

“What’s the game” is still looming over my head.  I have a couple thoughts about providing randomness to the system (providing random partners with random traits, and maybe having random requirements for what makes a suitable pair).  And maybe you get a certain number of flowers, making players decide whether they should “settle” for something they know is possible.

But the odd/even problem remains!  Maybe it’s something along the lines of passing the flower back and forth, with each player being allowed to take 1 to 3 pedals off?  And the game becomes about trying to trap your partner into an unwindable situation (As in passing off the flower with 4 pedals left, forcing them into a checkmate).  Feels like that adds in a lot of extra junk though.

[chadlycable]

She Loves Me…

With Valentines Day around the corner, and a craving to make something small and polished, I immediately went to the ol’ “She loves me, she loves me not” toy.  Basically, pulling pedals off a flower.

The goal here is to give each pedal a ton of feel and give and play.  Swiping your fingers over them causes them to rustle back and forth.  Pulling on them causes them to stretch and shake and discolor.  The next step will be plucking them from the flower once stretched far enough.

Implementation wise, everything is running on springs.  It’s my go to…maybe too often!  One hurdle that came up was getting this to play nicely with Unity’s input system.  The IPointerEvents are wonderful when making a single element work, but becomes problematic when handling input back and forth between different elements, or trying to treat “touch enters” like “touch downs”.  That, and there’s no clean way to ask a PointerEvent if the touch is even “pressed” (I guess you can assume for a touch device, but the problem remains for mouse input).

After fighting with the system for a while, I defaulted to doing a kind of hacky (but flexible) solution.  The background implements the touch events - “down”, “up”, and “drag”.  The background then fires a sphere cast into the scene and finds all of the colliding pedals.  A little roundabout, but this implementation gives me a lot more control about deciding which pedal is touched, as well as having some filtering involved (Unlike the pixel perfect PointerEvents).  All in all I’m happy with it…but also kind of wish it wasn’t so one off.

What’s the game though?  This part is still unclear.  One thought was to give players a picture of their date, and their goal is to make the pedals count to the desired answer - meaning you may want to avoid falling in love with a specific person.  The problem is that the rules are deterministic, so everything comes down to whether there’s an odd or even number of pedals.

But, uh, figuring that out will be a problem for another day.