I'll be trying to update this devblog page daily. Scroll down to see previous entries. Thanks for checking this out and please do like it! Also, if you have any questions about how I'm going about certain things, please feel free to ask in the comments. I've set up a sort of index of topics so that, if you are interested in a certain aspect of development it is easier to find.
Sprite Shape Related:
Design and Animation:
Physics and Contraptions:
Day 35: Platforms, props and contraptions (15 Dec 2018)
This is it. It might be my final post before the challenge closes. Hopefully I'll be able to continue this, otherwise I may just have to start a new post to continue the dev log.
To make the most of the time left, I decided to start work on some of the game elements like platforms and props. More a revisit, actually. Once I decided on my character designs and got them animated, I realized that some of my previous work didn't quite jibe with the look I established. So, it was update time before I bring them into Unity for conversion to sprites and sprite shapes.
Here you can see what I've come up with.
I've got a bunch of trees, rocks, bushes, clouds and platforms. All of those platforms are going to be used as sprite shapes. I can say with certainty that I'll be adding a lot more to the game as I go along, especially once I start designing some non-bunny-themed worlds.
Thanks to everyone that joined me on this journey thus far. It's been a lot of fun, a lot of learning, and wound up turning into the start of game that, one day soon, I hope you'll enjoy. Stay on the lookout for more about Yub Yub.
All the best,
Day 34: More Bunnies! Yes! More BUNNIES! (13 Dec 2018)
With time winding down, I've decided to push the crazy into overdrive on these last few days. Or at least for today. And that spells more bunnies. Baby bunnies, to be precise. The baby bunny puzzles are going to be fun and challenging, requiring Yub Yub to make multiple deliveries at the same time.
I could talk about the bunnies, and how they come a close second to squirrels on the list of things that drive Priscilla (the real like Yub Yub) out of her mind. But, I'll spare you. Instead, have some bunnies.
Day 33: Bunnies and Dialogue (11 Dec 2018)
First up, bunny!
In this game, Yub Yub is tasked with delivering items, starting with food, to the inhabitants of different worlds. The first world will be Bunny Mountain, so obviously I need some bunnies. I've worked on design for them before, but given the redesign and style that Yub Yub has undergone, bunny needed an overhaul as well.
Without further ado, I give you Bunny.
This is bunny's "Hi! Over here! I want an apple!" idle animation. Which brings me to dialogue.
One of the goals and design rules of this game is to not use text. At all. Ever. If I feel a need to explain something with text then I am doing it wrong. Given the massive amount of text I've written for this post, some of you may find that surprising. However, I feel that, if I can explain things with numbers, images, sounds and music, then I will have created something that is universal without the need for language localization.
So, if a bunny (or other inhabitant) wants something, they'll have those little word balloons pop up to express their needs. Or, it could be a sign (as seen in a previous post as well as the background of this post's thumbnail image). I think that the whole exercise will be a lot of fun and also make for a very fun game.
Day 32: Organizing and more camera (9 Dec 2018)
Two things today - revisiting and final polish on the camera and organizing things a bit.
FIrst the camera. The controls for the player are really simple. There are things that are going to be obviously clickable. There are also going to be parts of the world that you'll want to pan to. What I don't want is for panning to accidentally click an object or, in the opposite scenario, for panning to start while you are attempting to click something. That started a whole process of revisiting the scripts that I had written. In the process, I made a decision that the touch asset I was using was just overkill. My touch goals are really simple so, after a little while, I implemented some new touch controls. I also found that the onscreen joystick for touch controls just got in the way, so I ditched it. In the end, I have some interactivity that I'm really happy with.
Next, I realize that this is a very long dev page. There is a lot of info here. It's that way by design and really is documenting the whole process of this game which didn't even have a name when I started. Some of this info you might find useful. So, I decided to throw a sort of index of topics at the top of the page. It should make it easier to get to things that you might be interested in.
Back to work. Tomorrow - bunny shall make an appearance.
Day 31: Camera Time (7-8 Dec 2018)
The clock is ticking on this challenge, so it's time to kick it into high gear. I've been working on tackling an important element of this whole game - the camera.
The game consists of a large world broken down into many small chunks. As an area is completed, one or more new areas will be unlocked. I set out to develop a system where the player can move the camera around, but is limited to areas that are unlocked. I also want the player to be able to zoom in and out to see some parts in closer detail or see the world from a distance.
Since this game is being targeted for mobile devices, I also need to integrate all of this functionality with touch controls.
I tried a few different approaches before I finally settled upon a system that feels good and accomplishes what I am aiming for. This could change later, but I can't imagine that it would change all that much. The only addition that I can think of right now is the possibility of having cutscene cameras, but something like that will be extremely easy to implement.
Step one was setting up a Cinemachine 2D camera. I have it targeting a sprite that is currently visible for testing purposes. During the game, this sprite will be disabled and will serve the purpose of being a focal point for the camera.
Next I needed to figure out how to handle moving this target around. I purchased Fingers from the asset store a long time ago. I believe it was part of the Unity 2D essentials pack for a little while. Anyhow, this is a really robust system for handling touch controls and, given that I am already familiar with it, it was a simple matter to import it and start with my own scripts.
I set up a joystick controller based on one that came with the asset. I only want the controller to appear when the player is dragging their finger on the screen, so that was step one. Next, I tied the output of the virtual joystick to the position of the camera target. All is proceeding to plan.
Next, I had to limit the movement of this target. I opted for a physics based approach. The target and limits are placed on their own physics layer so that they only interact with each other. I set up my area control script so that, if an area is not unlocked, it's box collider 2d component is a collider. If it is unlocked, that collider is set to be a trigger. I also set up four areas that serve as the bounds for the whole level. All of these will never be unlocked and hence always keep the camera within those outer bounds. You can see how it looks below.
As a side note, the Cinemachine camera has an extension called a confiner. It will basically attempt to do what I am describing above. I ran into some problems getting it to work adding in new colliders to the confine area at runtime. This is why I stuck with the approach I described.
Given my love of extending editor functionality for easier development, I also added in some visual aids for these areas. You can turn on helpers from the component and it will show the confines of the box collider in the editor. You can even set the color so that one area is easily distinguished from another. All of this works wonderfully.
Now, I had to set up the zoom controls. I added a Fingers gesture for scaling to my cam control script and tied that into the orthographic size of my Cinemachine virtual camera. I set up 3 floats as well - the normal level, max and min.
Last but not least, I added two small buttons to the bottom of the HUD. One resets the zoom, the other moves the camera position to the center of the current area.
It was a lot of steps but really easy to implement. Now I have a nice, robust camera control system in place.
Day 30: Even more animation (6 Dec 2018)
I get a little OCD when it comes to this kind of work. I was tempted to move on to other things but I had to get Yub Yub's animation just a bit better. I played with timing, added in a fake 3D controller for her head, and made it so her butt is squishy (flat when she sits, rounded when she is off the ground). All in all, I'm pleased with the effort.
I even added her into my thumbnail image. Next I will finally get to those other elements I keep mentioning.
Day 29: More Animation (5 Dec 2018)
I've been getting more assets ready for animation. All of the prep work of breaking down an illustration into individual parts, setting up skeletons, turning sprites into meshes, and then weighting those meshes can go a bit slowly at times. But, once that is done, the animation process is quite satisfying. Much of what I'm doing is getting something good enough to continue development and then worrying about fine tuning later.
With that said, I have Yub Yub set up and ready to bark away.
More animations and game building are on the horizon in these final days. I still have to incorporate touch controls and the Cinemachine camera for panning and zooming around the world.
Day 28: Animation (2-3 Dec 2018)
So I could go on and on about how amazing I find the whole idea of rigging and animating 2D assets in the same way as 3D models. I really could. But I'll spare you and keep this entry short. I decided to first go for Yub Yub's ball machine. I need to add in a bunch of animation events (the ball is currently embedded in the animation, as is the banana item in the window). My goal was to take the flat machine and make it chug along and spit out a ball. Here is the result.
I'll add in a few particle effects, break it into components, and this baby will be done.
Day 27: Designing the look of the world (1 Dec 2018)
Yub Yub is moving right along. Now comes the design and illustration part. I've been using placeholder graphics up to this point, so it's time to remedy that situation.
First up is the piece with the most moving parts so far - the ball delivery machine.
The plan is to bring this in in pieces and then, using the animation features, bring it to life. I intend to make parts shake, have the progress bar fill as the machine chugs along and then spit the ball out of the big pipe at the top.
Next up are some of the props. Just some trees, rocks, and bushes, but they'll go a long way to adding some variety to the world.
Finally, I have a shot of the world and what some of the pieces will look like in it. The platform that Yub Yub is sitting on is the first of my intended sprite shape platforms. There is also a sign that will be one of the types of goal indicators.
I've got background elements in there as well. I intend to create some depth of field effects with a blur shader. Of course there will be some parallax effects as well.
The shadows of the platforms are proving a little bit tricky but I think I may have something worked out for them. I like to design with the hope that I will work out any issues like this in development. The approach hasn't let me down thus far.
Day 26: We have a title! (29 Nov 2018)
It's official - Untitled Challenge Project is untitled no more. Welcome to Yub Yub! Special Delivery.
Yub Yub, a delightful golden retriever, is visiting various locales, delivering the goods that the inhabitants demand. Using her patented packaging machine, Yub Yub rolls items, completing tasks and puzzles and unlocking new areas and item recipes. Yub Yub! Special Delivery is all about casual fun in in a cute, fun filled, surprising world.
You can see some hints of level elements in this picture, but I'll be posting more about all of that later. For now, enjoy Yub Yub!
Fun Fact: Yub Yub is my golden retriever Priscilla's nickname. She's my Yub Yub!
Day 25: Finally some design work... and some talk about shaders and their role in all of this (27 Nov 2018)
Yeah. So it's design time. Having done all of these various parts, I have a really concrete idea as to what this game is going to be all about and even a possible title. But more on that at a later date.
I've set to work nailing the visual style of the game. As I've said before, I want to keep it clean and relatively simple. I've got a bunch done, but what I'm going to share first is the first set of balls.
Yes, Fruit and veggie themed character balls. Getting specific types of balls from point A to point B is going to be at the core of the gameplay. Some (as in most) of the balls won't be available at the start of the game. Completing tasks will unlock new balls and open new areas.
Back to the design. I mentioned in another post that I want the balls to roll around but it is important to me that the shading stay consistent and correct. The bright spot will always be where the bright spot is supposed to be. But, with a rolling, rigidbody how can I do that?
The answer comes down to shaders. By overlaying certain elements, I can create a stack and control, through scripting, how each part of that stack interacts with the world.
Here is a sample of the breakdown:
At the bottom of the image is the base color for this ball. It's a little transparent and has a subtle gradient. This part of the ball will have nothing done to it in regards to responding to physics. The gradient will roll, which technically isn't correct, but I've found that it actually helps to sell the movement.
Next is the shading layer. This is placed on top of the base color and is set to multiply. Next in the stack is the strawberry icon. Nothing is done to alter it's display, but his rotation is influenced by the x velocity of the ball. He tilts as the ball moves in one direction or other. He also is given a light pulsing effect. It helps to make him feel a bit more animated without needing to do any keyframe style animation. Which feels like too much, especially given the number of balls that are going to wind up in play at any given time.
The last layer is the highlight layer. It is set to additive mode (linear dodge) and has a behavior that mirrors the shading layer. Neither of these respond to physics. Or, more accurately, they are set so that they will always point to world transform up.
With all of this combined, I end up with a ball that can roll around, maintain its lighting and feel like it exists in a real, albeit cartoony, world.
Tomorrow, I'll show off some level design elements. Stay tuned!
Day 24: The Collector (26 Nov 2018)
I've had a lot of moving parts coming together over the past couple of days. Designing of elements is moving along and new gameplay ideas are fleshing out. With that comes the need for a few new contraptions. The first is the Collector, mentioned in yesterday's update.
This one is ridiculously simple. Once the required number of balls are collected, the gate will open. That's it.
You'll also notice that I've started working on some fruit themed ball designs. For now, I've implemented the orange and the strawberry. More are in the works with some not being fruit related. But, we'll stick to the fruit for now. They use the setup I mentioned a few days ago so that the highlights and shadows stay accurate to the world. I'm thinking that I may windup rewriting all of that as a shader. We'll see.
Collectors are also going to ball type specific. Only want to count strawberries? That'll work. It's going to work with a gameplay mechanic that I'll introduce with character designs so that you don't wind up with a bunch of oranges in the basket taking up space. All will become clear soon.
Lots happening. More to come.
Day 23: Game Concept Part 1 (25 Nov 2018)
I feel like I'm finally at the point that I'm ready to start talking about game concept. I'll share a very rough sketch and then explain where I'm heading.
I should start by saying that this is not going to be one of those game where you get to kill a lot of things. The game is about exploration, discovery and the fun of completing all of the parts of what is basically a big marble machine. In this, the start of the game, we have a peak on Bunny Mountain. At the top is our Puppy and her ball machine. The machine makes and releases tennis balls which proceed to roll down the mountain. Scattered around the mountain will be various inhabitants including, obviously, bunnies. In this screen, as the balls roll down, they collect in a little basket. Once enough balls are collected there, some of the clouds will clear, revealing another area to explore. The basket opens and you're back in business.
The game is by no means passive. There will be plenty of things for the player to interact with, sending balls in one direction or other. Some will be puzzles, some just hidden surprises. But, all in all, the goal is to have large worlds that capture the mesmerizing qualities of marble runs, something that I love very much.
I released a game a few years ago called Frantic Ball. It explored these ball tracks in a completely different way. For one, the game was done in 3D. It was also, as the title suggests, quite a bit more frantic. This is a chance to revisit that world and explore it in a completely different way.
Given that this will be a 2D game, I'll have a chance to add in a lot more in each world with less of the demands that a 3D game can have. I'm also targeting mobile devices with this game and plan to take advantage of touch controls for things like screen scrolling and zooming. CineMachine is going to come in really handy there. Last, I'll be animating a lot of things, from characters to contraptions to particle style effects. The animation and IK packages will play a role there. I will likely be sticking with Spine for some character animations, but we'll see how my work flow goes with the new animation system built into Unity.
I'm aiming for a clean, cartoony style on this. I plan on working that out in the coming days as well as a few more contraptions. I can see that I need, at the very least, a ball collector.
I've got my work cut out for me, but there's still quite a bit of time left in this challenge.
I'd love to hear what you think.
Day 22.5 Launchers and using effectors (24 Nov 2018)
I'm continually attempting to build ways of moving the balls around what will eventually be the the world that I am planning. Today, I present to you some launchers and lifters. Here is the scenario:
The goal is to get the balls to the upper platform, in one case quickly, in the other in a slightly less speedy fashion. The two gray blocks are a launcher and lifter.
The first thing that I did was add a platform effector to the sprite shape that is the upper platform. If you're not familiar with effectors, there is a lot that you can do with them. In this case, the platform effector will allow objects to pass through from below and then land on the platform.
Next was setting up the launcher and lifter scripts. I actually use one script for both cases. If it is going to act as a launcher, then, in addition to the gray platform moving, a force is applied to launch it up. If it is acting as a lift, no force is applied.
Here is a how the launcher looks in the scene view when selected. A couple of things of note - The big orange box is a sprite mask. There is a lift arm sprite attached to the mechanism that is currently not seen due to the mask, as well as part of the platform itself. This will act to make it look as though the platform is actually lifting from the ground rather than just floating around. The other thing to note is that line with the circle at the top. This is a visual indicator of the platform move amount variable that I've set. I like to have visual feedback for this type of thing.
Anyway, here are the two new mechanisms in action. Enjoy!
Day 22: Cannons one more time (24 Nov 2018)
I decided to add a few more options to make setting up cannons even easier. Here is the (possibly) final version of the inspector for them.
All of the new stuff is in the bottom portion. I set it so that you can specify the time interval. This will put the dots closer or further, depending on you preference. Nothing that major, but it comes in handy for what comes next - collision detection.
In setting up my platforms that the cannon is aiming for, I found it would be helpful to know when a trajectory was actually hitting something that a ball could land on. So, I decided to add in so extra features for this. Currently, if the trajectory arc hits something, the relevant data of the arc is displayed and the line stops.
You can see that the left arc is hitting that upper platform. The right arc is hitting one of those stairs. I want to be able to move the bouncy grey platform and have the arc reflect that in the scene view. This is precisely what happens now.
With this, I get realtime feedback in the editor so that I can really position these elements knowing exactly how everything is going to behave. Guesswork can be fun sometimes, but it can make level design a bit tedious at times. This goes a long way towards making cannons a joy to set up and use.
Day 21: Fun with Cannons! (23 Nov 2018)
As is often the case, I like to have some options available when building things. I also like it when those options are easy to use in multiple scenarios. With that said, I decided to make my cannons a bit more robust.
First, I'd like it if they weren't limited to firing with one force at one angle. Real cannons can fire in multiple directions. Mine should as well.
Second, it would be great if I could have some visual feedback in the editor to be able to set the force and angle values to hit my desired targets.
Third, as always, it's gotta be easy to use.
Here is my test case.
In the middle is my rudimentary cannon. A ball rolls in, it rotates to firing position, fires, and then resets. I'd like it to first have a ball land on the ramp in the upper left and then fire a ball to bounce off of the grey bumper block. There is a collider on the spawner above the cannon so I'll need to arc the shot under that.
Getting to work, I first set up a custom class for the properties of each shot. It includes angle and force float variables. These will be listed in the cannon's component in the inspector. The component winds up looking like this:
Lots to see. All of the stuff at the top is pretty self explanatory. That barrel end transform is where I'll eventually place particles for when the cannon fires. My first target is the platform above and to the left. I turn on "show helpers" and start adjusting the first force and angle values. Now, I wind up with a good trajectory to get to the upper platform.
That "show helpers" means that, whenever the cannon is selected, I can see that trajectory line. It places points at 0.1s intervals along the firing path and displays them in the scene view. If I adjust that "Trajectory gizmo display" number, I get more or less points on the path.
Satisfied with the first shot, it's time to set up the second. I want to arc under the spawner and to the right. I add another fire angle to the list, play with some force and angle values, and end up with this:
I like the trajectory, but it's not hitting that bouncy platform. In this case, I want to move that platform so that it is in the way of the trajectory. Turning on "always show helpers" means that I can deselect the cannon and move other things around while still seeing the trajectories. Moving that platform, I wind up with this set up.
And there you have it. Cannons with multiple configurations that are easy to set up. I love it!
Here is my new cannon in action. Enjoy!
Day 20: Cannons and Dumpers (22 Nov 2018)
Took some little breaks when I could today to work on a few more contraptions.
First up is what I'm referring to as the dumper. It is the lever arm with the block with a 12 on it. The way it works is that once 12 balls are on it, it will tip and dump them. Adjusting the length will determine how many balls it takes to tip it.
Next is the cannon. It's the purple block with the grey block on it. The purple is the base of the cannon and the grey is the barrel. It will suck up a ball as it rolls through, rotate the barrel to firing position, and then shoot the ball to its destination. Afterwards it resets for the next ball. It's a fun and quick way to move the balls around the levels. You can see both in action below.
Day 19: More contraptions! Bouncy blocks and steps (21 Nov 2018)
Time for some more contraptions and updates about others. I made some modifications to the pendulum, specifically to the shape of the "cup" that catches the ball. I basically makes it easier for the ball to roll out of it. I was running into a few cases where the ball would get stuck. Another solution is to simply make the release point lower. Either will work. Both solutions together make it just about fool proof.
The first new contraption is a bouncy block. Really simple, just an angled block that falling balls can bounce off of to redirect their fall. I have a physics material 2D assigned that has a 0.6 bounciness set. That feels like the sweet spot. You can see them in action here below.
I'm planning to jazz them up in game with some nice, steel drum sound effects and a custom shader to add a bounce effect. Nothing too fancy here, like I said.
Next up are stairs. These were fun to set up. The most basic element of the stairs is a single step, one of those angled brownish blocks. It's a sprite with a polygon collider and an extra component, a stair step script. That has a bunch of variables in it that don't need to be set at all but that I left viewable in the inspector as a sort of sanity check.
Really simple. Once set up like this, I store it as a prefab. The real magic happens in an empty game object with a Stairs component added.
Add the stair prefab you want to use and you wind up with...
... a staircase consisting of one step. But, do you see those settings in the inspector? Changing the value of the number of steps to something like, say, 8 will give you...
... a staircase with 8 steps. That's a bit more interesting. The rest of the settings control how far and fast the staircase moves, delays between movements, and the sorting order of the sprites for the stairs. If you uncheck the "stairs move right" then, you guessed it, the whole thing will flip so the stairs go up and to the left. It automatically places the stairs based on the prefab stair's width so adding staircases couldn't be easier. Just like many of the other components that I built, if I think that there is a remote chance I'm going to have to do anything repetitive in the design process or anything that is going to require fiddling with a lot of elements, then I try my best to write up something that automates the whole thing. I'll clean the whole thing up with a custom inspector, but this is working really nicely now. Check it out.
This one moves a little slowly, but that was just for testing purposes.
I've got a few more contraptions to knock out. If anyone has ideas for others, I'd love to hear them. Once those are done, maybe I'll finally get around to the object pooling that I've been avoiding unnecessarily for so long.
Day 18: More contraptions! The Pendulum and The Lifter (20 Nov 2018)
As expected, today was about creating some more contraptions to move those balls around the world. The first was an easy one - the Pendulum!
This little guy catches a ball as it rolls of the platform and swings down to release it on the platform below. It then swings back up to get ready for the next ball. If, however, another ball comes along before The Pendulum! has had a chance to swing back up, then it acts as a ramp to the other platform.
It's all based around that trusty hinge joint once again, this time with a motor attached for the swing back up. In the real world, it would likely use a weight at the other end to achieve this, but since I have motors I might as well use 'em! The nice thing about that is that I can control the speed of the upswing to get back into position faster or slower. It's a fun addition that I'll be putting to good use.
Next up is the lifter. I know. Not as exciting as The Pendulum! Or is it? The lifter serves as a way of taking the balls up to a higher platform and dropping them off. This one was a little trickier to implement.
My idea was to use my bezierFollow component to place the various teeth around a sprite shape and then my bezierAnimate component to move them along. Simple enough, right? Well, in the process of doing this I discover some minor issues with how I was calculating the normal at any point along the sprite shape, so it was back to the drawing board on that one. In the end, I got so that it not only works in every situation, it is also a much simpler set of code. Score one to the lifter for that.
Next, I started placing the various teeth around the sprite shape using the aforementioned components. The first time, I set up six teeth and then set their start positions, loop time, and other settings. It was nice, but I realized I wanted them to move slower and I also wanted more teeth. This meant recalculating start positions (the first time was just simple, single digit increments), changing all of their timings and tinkering with a few other settings. And doing all of this multiple times without knowing if I'd actually be happy with the end results. Also, the thought of doing it this way every time I want to use a lifter would mean that I'd probably be very unlikely to use a lifter.
But, all of this just sounds like math, instantiating prefabs, and other things that a script would be perfect for! So, back scripting I went.
This one is actually a lot of fun to use. You attach this component to the sprite shape you want the teeth to move around it. It grabs the sprite shape controller component for you. Next, set the prefab to use as the lift arm. All that prefab is is a sprite with a collider. Next, tell it how many of these you want placed around the sprite shape and how many seconds a loop should take. Autostart makes it start on play. Ping pong will have it complete a loop in one direction and then turn around and go the other way. Clockwise is just what it sounds like. Y offset is how far above the sprite shape the teeth will lie. And last but not least, show helpers will turn on some gizmos and other info in the editor window.
Setting all of these automatically creates the game objects, adds the necessary components and applies the relevant settings. It makes it all SOOOO easy. Another win for the lifter.
There are other uses for this (which is why I didn't just name the component "The Lifter") and probably a few other settings that I'll add in later. But, I really like how this all turned out. In action, it is a lot of fun. As these components and contraptions come together, I'm getting closer and closer to the actual gameplay part of this whole process.
Check out the lifter and Pendulum! in action...
Day 17.5: The Rocker or "Fun with 2D Physics" (19 Nov 2018)
I've heard a lot of grumbles in the past about 2D physics in Unity. I've done plenty with physics in the 3D realm, but was concerned about how all of this was going to affect this project. Well, let me tell you that my concerns were unjustified. In the short time that I've been working on this project all of my experiences have been nothing but positive. Which is great, since a lot of what I have planned will be dependent on physics working as one would expect.
Today's part two involves creating my first contraption for the game. Little balls will be rolling to and fro. At some point, I'd like to be able to guide them down one path or another. I considered just cheating all of this with some clever use of colliders and triggers, but this is precisely the sort of thing that physics is meant to handle.
I present to you a rudimentary rocker.
The blue dot in the center with the big green circle around it is a hinge joint. The green circle indicates the angle limits on this joint. I have chosen to give this unrestricted movement but to set the option on the joint to enable collisions. This means that when the rocker tilts, it will only go as far as the collider of the lump of the brick sprite shape beneath it.
It may be hard to tell from the image, but I also set that pivot slightly off center. This makes the whole thing a little bit heavier on left side. Why? So that, when the game starts, the rocker will tilt in that direction.
The green bar protruding from the center is just a child of the hinged object. It has a Box 2D collider attached to it but doesn't require a rigid body. It'll serve as the part of the mechanism that guides a ball in one direction or another.
Like everything else, I'm keeping the design basic at this point just to nail down the mechanics and illustrate my process. Eventually, all of these are going to get a nice redesign. Hopefully before this challenge is done.
Anyway, you can appreciate how this mechanism works in the clip below. It performs the task of guiding balls in one of two directions quite nicely.
I think I'll be building out more contraptions like this over the next few days. It should be fun!
Day 17: Balls and a proper 3D feel (19 Nov 2018)
Now that I've got lots of parts built, I figured I'd spend some time tackling a slightly different issue - balls that have proper highlights and shading.
I'm going to have a variety of balls that roll around on the little platforms I'm been experimenting with. The thing is, I'd like it if they could have a sort of 3D feel without being actual 3D objects. This means that, as they roll, the lighting on them would need to stay constant while whatever pattern is on them moved around.
My solution is to layer some sprites. I'll start by showing my test subject - a really simple tennis ball pattern.
As you can see, they are rather flat. Which I suppose could be fine, but it's not something I can live with. I decided to add a script to the main ball that will control two child sprites that are just black and white images - one for shading and one for highlights. I'm using a blend mode shader on these two sprites to overlay them on the parent design. Then, in my script, I make sure that the rotation on these two shading sprites remains constant. The overhead is relatively low and I like the effect.
Even as test subjects, these guys have a lot more life to them. Best of all, once I decide on the look of the game, I can design a bunch of patterns for the balls (tennis, soccer, basketball, etc) and them use the shame shading sprites each time. Nice!
Day 16: Decorations, Part 2 (18 Nov 2018)
I spent a good bit of time working out the whole decoration system. I want it to play well with everything that I've done so far and not have it be a confusing system to use. It is, at it's core, a component that will allow for the mass production of game objects that are "attached" to a sprite shape. If the sprite shape is static, wonderful! This will work. But, if I'm using one of the various methods that I have for moving the spline points around at runtime, well... it works then, too!
Here is a view of the custom editor I've come up with:
There's a lot happening, but it is pretty straight forward. First, you select the sprites you want to use. Next, set if your sprite shape is going to be moving around. Next are scale related variables. If you want the scale to be random, go for it. If not, the fields displayed change and everything gets set to that scale.
Quantity works the same way. Want a fix number of decorations? Uncheck that random box and say how many.
Next are display related items. The order relative is just what it sounds like - do you want the decorations to appear above or below the sprite shape? Set that here. Finally is the Y offset - how far above or below the spline the item will be placed.
Current decorations is a list of the decorations currently associated with this component. In the case of the image above, I haven't made any decorations yet so that list is empty. All of that changes once you click the "Add new decorations" button. Like magic, you'll have a whole new set of sprites attached to your sprite shape.
Here is a sprite shape before adding decorations...
... and here it is again with a few alien blocks on it.
And here is a new view of the inspector:
You can see that the only thing that has changed is that now the decorations list has those 3 alien blocks in it. You can select them individually from here and adjust their positions. They all use the BezierFollow script I talked about in a previous post to position themselves, so moving them around with that is easy. Or if you just don't like them, you can clear the decorations or just keep clicking "Add new decorations" until you have a set that you are happy with.
The "Reposition Decorations" button is useful if you play with moving around the points on the sprite shape's spline and don't have this set to be a dynamic sprite shape (which you definitely shouldn't if the sprite shape won't be moving).
On the whole, I'm happy with this. The last thing I'm going to add on is the ability to add colliders to the objects as you add them. Other than that, this is useful and easy, just what I like in script.
Day 15: Decorations, Part 1 (16 Nov 2018)
So sorry for the delay in the updates. I've been hard at work on a few things. The first is a system for adding decorations to sprite shapes. Imagine having a shape that you'd like to decorate with tree, flowers, or other objects. Wouldn't it be nice to be able to just attach a script to the original sprite shape, set some sprites you'd like to use for ornamentation and then click a button and have it decorated? That's what I'm currently working on. I'm build out the functionality of the main script now and am then going to create a nice editor script so that you can set parameters for randomness in the number of objects, object scale, and object placement. Most of the basics of the main script are now done but I have a few more bells and whistles that I plan to add. Once it is done, I'll grab some screens and post more info. In theory, it should be pretty nice and should allow for easier creation of static levels as well as adding things in for procedural content.
It already allows for setting the display order, min and max scale, and number of objects - which will also be able to be a range. Once done, it should make life and level design easier. In theory.
I hope to post more tomorrow but have a dinner party, so it will likely be Sunday that I have another big update.
Day 14: More Spline Fun - A little lump that glides along a sprite shape (13 Nov 2018)
In my last spline scripting effort, I made some deformations that move a sprite shape controller's underlying spline in a waving motion with lots of options. But, I thought it would be nice to have a lump form in that spline and glide along rather moving like an inch worm. So, back to scripting.
There are a bunch of options. What this does is take a straight, level spline, add in three points to form the lump and then move it along. Ascending means it moves left to right. Looping is obvious. Ping pong means it moves in one direction and then the other. You can set the height of the lump, the delay before the lump forms and starts moving and how long it takes to reach (nearly) the end of the spline.
On other fronts, I'm not sure how in love I am with my current character designs. I'll take some more time with that. Rather than brooding and feeling unproductive, I figured I'd jump into something that I know I'd be able to put to good use.
As always, if you're interested in how I went about any of this, just leave a comment.
Day 13: Cleaning up the bunny (12 Nov 2018)
"So, what did you do today?"
"Some work stuff. A little bit of coding. Cleaning up the bunny."
She looked at me. Puzzled. Clearly uncertain if she heard me correctly.
"What was that last part again?" Her request for clarification amused me. I paused, as if confused by her lack of understanding.
"Coding?" I asked, as if bewildered by her question.
"No! It sounded like something about a bunny!" She could tell I was toying with her. Best not to press my luck.
"Oh. Yeah. Cleaning up the bunny. See?" I tilted my iPad in her direction. Procreate was open with the sketches that I posted yesterday.
"These are my rough concept sketches for some game characters." I double tapped the home button, pulled up Affinity Designer, and loaded the file for the bunny.
"This is a cleaned up version of the bunny sketch. I like the crispness of the vector art and work with this program on an iPad with an Apple Pencil just feels really good. I still have a bit more work to do, but I'm generally happy with how it's coming along."
I could tell from her reaction that my explanation was far nerdier and less interesting than was she was hoping for. Little did she know that, in a day or so, perhaps even tomorrow, I would tell her that I was exploding a puppy. Oh boy. That should be interesting.
Day 12: Character Concept Time! Part 1 (11 Nov 2018)
With all of the bits and bobs I've been working on built, it's time to take a break from the coding and do a little bit of character design. In the process of making and experimenting with all of this, I think that a solid game idea has come to fruition. And, sure enough, it will in fact involve a puppy.
The world and environment of the game is going to be fairly blocky in nature. The platforms will have nice bendy features so it would be nice if the characters could reflect that as well. There is one major exception to this, but that will come in a later post when I get into how the game actually plays.
The first world will feature our protagonist, the puppy, the enemies, and will be populated by some cute bunnies. I'm going for a very stylized look on the characters, with them having a sort of somewhat blocky but rounded egg shape. I think that they'll fit into the environments as I envision them quite nicely.
First up, we have one of our bunnies. I usually start with a set of really small thumbnails. I want the characters to be able to read well at small sizes. Plus, starting small means I can't really get into the hard details. I got a body shape and proportions that I liked and then did a few more little sketches to work out poses. If it doesn't pose well at this stage, then it just doesn't work.
There is also something that I love about animating things that have such simple forms. If you can make something like this expressive and fluid, then I feel like you're doing something right. Despite the simplicity of the character, when it comes time to rig and animate it, I know I'm going to build out a somewhat complex sprite mesh and skeletal system. That will be fun.
I went back and forth a bit on giving him feet and ultimately decided against it. I think there is something cute about him being almost like a Russian nesting doll in shape. I don't think the the feet really add all that much.
With the bunny concept at a point that I was happy with it, I decided to move on to puppy. Puppy will follow the same structure. As the main character, I know I'll be doing a lot more animations for him. He's a golden retriever. I have two of them. They are awesome. They are really funny, sweet creatures. And very expressive. I wanted to capture that in this simple style.
He's going to have a lot to do in the game, so I know that his rig is likely to be a bit more involved than the others. And, again, despite his simplicity, there are going to be a lot of moving parts in order to allow him to move fluidly and feel like a squishy, bendy, fun little fur bucket.
I'll probably do some concept sketches for the enemies as well, but it's more likely that I'll just pop into Affinity Designer to do a cleaned up, vectorized illustration of these two first.
I love this stage of development. Once I get them done, I'll start on the environments and finally have some game screen concepts to show off.
Day 11: More Wave Action (10 Nov 2018)
Yeah. Surprise, surprise. Still haven't gotten to implementing object pooling. What I did do, however, is add a couple more options to my wave animator. It can now have a wave that moves up or down the shape instead of waving the whole shape at once. This is great for pushing objects along. I also added in an option for sharp points instead of those smooth bulges. You can see the inspector panel has the new stuff added.
You just set the option for "One Way" and then choose a direction.
First is a wave ascending up the shape with ends moving.
Next, a wave descending with the ends stationary.
It's also smart enough to return the shape to it's original position in the event that you stop the cycle in mid wave. Of course, you can still set the amount that the wave bulges as well as how fast it moves. Waves are fun!
Day 10: More fun with Sprite Shapes - Doing the wave! (9 Nov 2018)
I'm beginning to think that I'll do anything to avoid getting to the pooling scripting for this game! But, an idea struck me and I just had to implement it. I thought it would be cool to make it so that I could have sprite shapes oscillate like a wave. Right? And, at this point, the more tools I have in my arsenal for level design, the better.
I had a few requirements when building this out:
It would have to do all of the heavy lifting for setting up the points on the backend.
It would have to have options for turning certain behaviors on and off.
The way it works is that you add a sprite shape to your scene. Set it as normal (applying the actual sprite shape asset to it) and then edit the spline and remove all but two points. The script will actually handle the point removal, but, for sake of illustration here, let's just say that you did this part yourself. You are then left with something that looks like this:
You don't need to worry about the tangents or tangent modes at this point. The script will set those up. You then add the Sprite Shape Wave component to this game object.
You can see that there are a bunch of options here, but the most important at this stage is the "divisions" variable. This allows you to set up the number of sections that you want the shape divided into. It will then take this shape, add in the necessary number of points, and set their tangents so that they are all equally spaced. If the shape is rotated (the actual game object), then the tangents are set so that each point is level, to the game object, not the world.
"Move ends" means that the end points of the spline will move - having this option allows them to be stationary so that they could be potentially attached to other static platforms.
"Move negative" allows for the points to oscillate above and below the start position. If it is turned on, you have movement that looks like a sort of sine wave. If it is turned off, odd points move, then even points move.
"Looping" is easy. And "Start" gets the party going.
Here, I set the divisions to 4 and let the script work its magic.
Below are some samples of the whole thing in action.
This one has 5 divisions, the ends move, and it moves negative.
This one has 8 divisions, the ends don't move and it does not move negative.
Finally, 14 divisions, ends move, does not move negative. You can see that there are a lot of possibilities. And these gifs don't do justice to just how smooth the whole thing is.
I'd love to here what you think about this and everything else I've posted so far. These sprite shapes are turning out to be a lot of fun. And, I think I've managed to nail down exactly what the game is going to be. More on that later.
Perhaps tomorrow will finally be pooling day. Stay tuned to find out!
Day 9: Copy the splines... but just a part (8 Nov 2018)
One of the many options I like in the sprite shape set up is the ability to use a sprite's borders so that the you can cap off the ends of a shape. This is great for things like platforms and walls. As you can see from yesterday's entry, I like the idea of being able to have a sprite shape controller set up that gets it's spline info from another sprite shape controller.
But, what if I want to do that, add a nice wall or something, but I only want to do this for part of the shape? Say from the second point on the spline to the end? That's what I got going today.
That wall section is getting it's spline info from the platform below it. Any changes on that spline, even at runtime, will change the wall shape as well.
I've got three variables here that work this magic. The short spline boolean tells it to use a section. When this object is selected, the spline points are displayed and numbered on the parent for sake of convenience. That is where the start index variable comes from - it says where to start the section of the spline that you will be using. Last is the length. This tells how long the short section should be. Both of these are smart variables - you can't set the index to something greater than the number of points on the parent spline or to something that would result in a spline with less than 2 points. The length will also make sure that it can only be as long as the parent spline allows based on the start value.
This is also going to allow for some interesting things like collider sections. Imagine a sprite shape with a gap in the middle that appears and disappears. I can just build that parent spline, disable it's renderer, and then have three of these mirrored sections. There are lots of other uses as well, beyond just the cosmetic, decorative functions.
With that, I feel like I finally have the sprite shape components that I wanted to build out completed. Until I think of something else. I can finally get back to pooling (yay) and building out actual gameplay elements.
Day 8: Mirroring Splines (7 Nov 2018)
So, today was supposed to be about object pooling. It was not. Object pooling should actually be really easy to implement. Instead, I was looking for a way to be able to have my sprite shapes share a single spline.
The example project that is available has a script to do this, however this script is designed for completing the conforming splines in the editor. I need something that will work at runtime. I also need something that will work with the splines deforming. So I suppose it is coding time.
Here is an example of what I've some up with. First, let's take the main sprite shape.
Nothing too exciting. It does have the control node for moving the shape with the up and down buttons. Next, I create a new game object and position at the same location as this one. For sake of ease, I just made it a child. I set the sprite shape that the controller is using to a set of vines taken from the 2D Game assets. Similar to what was done in the blog post about Sprite Shapes.
The shape shape that the vines are using have options for 2 variations and a blank space as well. My script allows for me to set the sprite index of each node independent of the original spline being mirrored. This allows for having different sprites at each node. I felt this was necessary, especially since the original sprite shape only has one graphic that it uses.
Finally, I created one more mirror, this time for adding a wall.
So, there you have it. Three sprite shapes all sharing the same spline. If I update that original or move the nodes around at runtime, everything deforms together.
I plan to add a little more functionality to this script. One thing that might be nice is being able to replicate just a portion of the spline. Since each point is referenced by an index, I could set it up so that the mirrored spline only goes from the 2nd point to the 4th point on the original. This would make it easy to add nice end caps on the wall, for example.
That's all for now! Thanks!
Day 7: SPAWNERS! But... spawning what exactly? (6 Nov 2018)
I'm finally getting the first hints of gameplay incorporated, now that I have a bunch of the control mechanisms built. First on the list? SPAWNERS! Which... well, isn't really a surprise given the title of this section.
I'm using another one of the 2D Game assets as a placeholder for the spawner for the time being. Also, I'm using TextMesh Pro for the text. I've been a long time user of this asset and it is nice to see that it is fully incorporated into Unity. If you aren't using it yet, get on board. It is really amazing.
Anyhow, what do the spawners spawn? Balls. Nice little rolling balls. Aside from dogs and puppies, I also love marble tracks. My last game, Frantic Ball, had these as the core gameplay element. You can read more about that game here.
There's not a whole lot more to say about this. Balls roll. Balls hit pink area. Balls are destroyed. Check out the gif to see the spawner in action as well as how the balls play on the moving platforms. Up for tomorrow - object pooling and something more than just balls being destroyed. Stay tuned!
Day 6: "Wait. What just happened?" and Puppy (5 Nov 2018)
So, this is one of those things that I wonder if anyone else out there can relate to. You write yourself a nice script. It does what you in the way that you expect. All is good and right in the world. You are a supreme programming god.
And then you change a couple of the variables and it starts misbehaving, mocking you. Running around the supermarket, knocking things off shelves. Generally making you reconsider your status as a minor deity.
This was today with my little "I can move objects along a sprite shape in new and exciting ways" script. It was supposed to update itself when the sprite shape's spline was edited. In theory. In practice, not so much.
I tracked down the offending code, rewrote some things, and, in the end, came up with something even better. I have reclaimed my throne. For now.
After that, I felt like I needed a puppy break. A quick retreat to my happy place. Time to animate a walk cycle for my little fat puppy character. I present it to you here. Enjoy!
I'm not sure if this is the pup that'll make it into the final version of the game, but he's good for now. Such a good boy.
Day 5: Animating objects on a spline and no more manual updating of the colliders (4 Nov 2018)
Still no fancy graphics, but I do have some nice new functionality. A practice of mine is building out my components so that they are easy to use and give some nice visual feedback. Even though I'm the only person to use these tools, it makes the process of building out levels and worlds much easier in the long run.
Today it was setting things up for animating objects to move along the sprite shape. I built out a custom inspector so that the start and end points are easy to see. They are controlled in the inspector with sliders that automatically update if the spline is edited and points are added or deleted. To set the positions, just move the slider.
I also set up an option to "take the long way around," essentially allowing the object to move in the opposite direction. In this case, the object will move to the left and, since it is an open ended spline, come back in on the right and continue moving until it reaches the end point. You can see all of this in action in gif below.
One other thing that has annoyed me that I decided to address. I am not fond of the idea of having to manually edit the collider to get nice little end caps on a shape like this. It seems like less of an issue with closed shapes, but these open ended lines would have a noticeable gap at both ends of the auto generated collider. Given that I'll be moving spline nodes around at runtime, this had to be addressed. I opted to add in a component that detects if the spline is open ended and, if is, add a collider on each end to address the issue. These new colliders take their properties from the sprite shape, so it is just a nice little addition that easily solves this issue.
Day 4: Now with more movement options! (3 Nov 2018)
Today was a little more code cleanup as well as adding in some things to make level design and editing easier.
I've built in a waypoint system for the control nodes of the spline to follow. I have two options for this now - one is automatic movement, the other is controlled by buttons. I've set up both so that if you select the control node, the waypoints are displayed in the editor as well as the paths between the points.
For the button controlled node, all of the functions associated with the buttons are added at runtime based on the position of the waypoints and a vertical or horizontal movement selection. The buttons also enable and disable based on the availability of moving in a direction (if you are at the highest point waypoint, then the "UP" button disables, for example). For both options, things like timing of movement, pauses, etc. are variable based and easy to edit and play with to get the right feel.
I'm still using placeholder graphics, but, as the mechanics are getting built, I'm getting some ideas as to what the world and game theme will likely be. I'll let that gestate for the some time and share it once I've had a chance to brood on it a bit.
Next up is animating the object that is sitting on the spline and possibly using splines as movement paths for the control nodes.
For now, enjoy a GIF showing off some of this in the editor.
Day 3: Cleaning up and setting up (2 Nov 2018)
Now that I've got a bunch of code written to control moving spline points and attaching objects to and moving them along sprite shapes, I figure it is a good time to go in and clean up the code. Some of the scripts I wrote only functioned if the were a child of the sprite shape. Others, like finding the normal at any point on the spline, were a little clunky. A good clean up was in order to make things more efficient. Especially considering what is coming next.
Some of the animation that I am planning is perfect for using Unity's timeline and for others that approach is just overkill. I'm going to be incorporating DOTween for some of this. It's an easy install and is perfect for I have planned. I can't recommend it highly enough! I'll be adding in the new variables I need, writing a few new classes, and getting everything together for the next stage.
Day 2: Scripting Part 1: Controlling splines (1 Nov 2018)
A big part of what I hope to accomplish comes from being able to control the underlying spline of the Sprite Shape component. A big thanks goes to Rafael Muñoz (who is also taking part in this challenge) for pointing me in the right direction with the BezierUtilities built into Unity.
First up was moving the points on the spline and having the SS update. This was pretty straightforward. I have a game object (in this case it is a simple circle sprite) that control the position of a point on the spline. I've set it up so that I can just assign the object to an index of the spline and then that point matches the position. Easy!
Next was attaching objects to the spline. Doing so at the nodes was really easy, but I'd like to be able to attach anywhere on the spline. This is where the BezierUtility came into play. I found some code in the forum that almost did the trick but seems like it was a little outdated. Getting the position was step one. I also wanted the option of being able to have the object match the nomads of the curve. This was less obvious. I came up with something that works. I don't know if it is 100% correct, but it certainly does the trick. You can see the results. This allows not just for attaching the object but also being able to move it.
Finally, as the spline changes, you can see that the attached objects move as well and also adjust their rotations accordingly. Neat!
Day 1: Setup and determining initial issues to resolve. (31 Oct 2018)
I spent the day importing the Sprite Shape package and getting a feel for it. As with everything Unity, set up is a breeze. The Sprite Shape stuff seems pretty robust and, for the most part, self explanatory.
I'm using assets from the 2D Game Kit for experimentation and testing. I'll likely also use some of the stuff from the examples posted on GitHub.
All of this has resulted in me identifying a few things that I'll need to address:
Attaching objects to nodes on the shape. The code from the SS blob post will help a lot there. It's basically written for me!
Moving nodes during game time. This one could be a bit trickier. I'm looking to be able to have nodes move based on user input. I don't see any real issues as long as I can access the nodes that I want to move. The aforementioned code should help a lot with that.
Physics issues arising from moving said nodes. Given that nodes could be moved fairly quickly, I need to make sure that a player doesn't pass through a platform if the node is moving too quickly. This one could be trickier than the rest and I'm thinking that I'll need to go with a recasting approach for this rather than relying purely on physics. We'll see as development continues.
All in all, a decent start. Definitely not moving at a sprint but I have a good handle on how this works and the major goals I need to accomplish. I'm hoping to have this all resolved by Day 5 at the latest.
Introduction (29 Oct 2018)
Hi! My name is Alan Thomas. I am an independent game developer. I've released nine games over the last few years for both iOS and Android. I've been using Unity for a few years now and for my last couple of games. I love it.
I saw this challenge and was immediately excited by it. When I came to Unity, I was transitioning from 2D games to 3D games. Unity was a natural fit. But, recently, I've been feeling the pull back to 2D games. There are some things that 2D is just great for. In particular, as much as I love 3D animation, traditional cartoons have always held a special place in my heart. I've also been working a bit in Spine recently and love the way I can animate there, bring into Unity, and then work some magic to make it really come to life. It is like magic.
What I haven't had was a solid project to work on. I've fiddled about with a bunch of ideas but, for one reason or other, none have materialized into a game that I could say was officially in development. I'd prototype, try it out, and then decide that the initial idea maybe was either too grand for a one man team or just not really all that fun.
Then this challenge came along...
Blah blah blah! Enough with the jabbering! What is the project already!?!
This project is something that I've toyed around with for a while in my head now. It is something that I dabbled with a bit in a 3D environment but quickly became way too cumbersome and difficult to control. It was clearly not the right fit. But 2D. That's a different story.
I revolves around a mechanic that will rely heavily on the Sprite Shape component. This was something that I was excited about when it was initially announced and I've been waiting for it to be included since then.
My intention here is to treat this page as a sort of dev blog. I'll be adding content as I build out the mechanics. I imagine that some new ideas are going to spring up as this process continues and that, once the challenge is complete, there will be all sorts of things that are included that I can't even imagine now.
I can also say that other components, like the Cinemachine 2D camera controls, will play an important part in this project.
So where is this puppy and how it is involved in the game?
Once I decided to start this challenge, I was sitting and trying to figure out what the world of the game would be. Who would inhabit the world? What are the enemies like? What would be a catchy title for the game to capture a sense of the game and all that it is about.
The honest answer is that, as of right now, I have no idea. And I didn't want to fall into that trap. If I said that it is a sci-fi game with aliens and shooting lasers and everything else, then I could be limiting the evolution of the game. And, for further honesty, I don't really have time to dwell on that. I want to build the mechanics out and let the game determine what it is going to be from there.
But, I can say that it will, in all likelihood, involve a puppy.
I'm more than slightly dog obsessed. I can very easily get distracted by videos of golden retrievers just being golden retrievers. I have two of them. They are fun and hysterical. I was actually already in the midst of drawing and animating a golden pup what I stumbled upon this challenge.
So, for now, the official title of the game is Untitled Challenge Project (Probably Involving a Puppy). We can call it UCPPIAP for short.
I hope that you'll join me for the ride. I think that my idea is good and that the game will definitely be different from a lot of what is currently available. Theoretically, it could be fun. Let's find out together!
All the best,