shawn's blog

What happened in August?

Posted in Music, Tone Def by Shawn on September 7, 2012

Well, who knows what happened in August? Now that I think about it, I don’t really remember. But I can pick out a couple of key things.

I updated some elements of Tone Def again

What’s different? Well, a new font, for one. This was created at FontStruct, probably the only place I’ll go to from now on for font. You can create your own font! If you see something that someone made, but wish it could be different, you can edit it! It’s really a great font experience. The font has been updated all throughout the game, and I’m pleased with how it’s turning out.

One major change which I feel added to the game feel x10 was the addition of a custom mouse. I wish I added it earlier.

The mouse pointer for Tone Def

This isn’t just an abstract mouse pointer, however. Each thing I do for Tone Def does take a lot of thought and consideration. One thing I try and do is related everything to something musical, if possible. This mouse pointer is no exception. At the base of the pointer, you can see a conducting baton. The mouse pointer itself is an abstract version of the path a conductor’s hands/baton takes when conducting a 4/4 piece of music.

A single for Tone Def has been released

And the name of this single is called Night Bots. It’s only $1.00 and currently on the OriGaminc bandcamp page……so far, no one has purchased it….*sigh*

Well, I actually have a bunch of codes I can give out for a free download…..

But it was a fun song to make, and it’s in a really cool level  for Tone Def. It’s called Night Bots for a reason.

Monster music for other games

I’ve been asked to make music for two other developers and their games in the Philadelphia area. Needless to say, I’m extremely honored, excited, and very inspired. One game is called Monsta Punch, an iOS brawler. The title screen music, which I’m calling “My Monsta“. I still need to polish this before I can say it’s complete, but this is what it’s going to sound like.

The other game I’m composing for is called Monsters, which is actually currently being Kickstarted (so go Kickstart it) If you want to hear my track, which is currently nameless, then watch the video and wait for the actual game cutscene to start. As I am with most of my musical tracks, I’m not done with it, and will most likely finish polishing things up until I feel like I’m going crazy over that song. I also have a second track for that game which still needs  to be finished.

Philosophically thinking….finally

This didn’t really happen in August, but I should probably mention this. A couple of weeks…er…months ago, I wrote this post, saying that I was going to write longer pieces based a a book called The Little Black Book of Design. And I still plan to do this. Actually, I plan to start within the next few days. It’ll almost be like going back to school, something that many others are experiencing currently. It’ll also be an excuse for me to read more about other things.

Anyway, that’s it for now. Let’s hope the next season is a bit more consistent!

Tagged with: ,

Comments Off on What happened in August?

How the SquareBots are spawned

Posted in Tone Def, Unity by Shawn on July 30, 2012

I’ve been working on the code that manages the spawning of SquareBots (the enemies for Tone Def: ROTS) for quite some time. The method for actually spawning, and some of the other features, have change significantly, and hopefully for the better (or at least I’d like to think such). It feels robust enough for me to think “I’m done with this……for now”.

The first instance of the enemy spawner was….well, terrible. There was one good takeaway I had from that spawner, and it was how I managed a list that let me choose the bots I wanted to have for a level. At the time, there were only 6 slots that I can choose from, and six different bots I had the options of choosing from. I don’t have a screenshot of how this looked, and I’m glad I don’t. How it worked was, the enemy in slot one had the highest chance of spawning, with the odds of an enemy spawning decreasing if placed in a lower slot. It was sloppy but functional code, filled with “Pick a random number from 1-20. If it’s between 1-10, spawn this enemy, if between 11-15, spawn this enemy…”. Something like this (off the top my head):

int x = Random.Range(0,18);
if(x == 0 || x == 1 || x == 2 || x == 3 || x == 4 || x == 5)
{
       enemyReturn = enemyList.GetEnemy(slotOne);
}

I wrote this a long time ago and thought, “Well, it’s good enough for now”, and didn’t look at it again until I was trying to do something more advanced and realized that the code was terrible for what I wanted to do. And this wasn’t even the worst part of the spawner code…..

The worst part was how I managed the rate at which the enemies spawned. Spawning was managed in steps. A graph is the best way I can think about representing this (made with a high quality art program because I couldn’t make this in Excel)

An awesome chart.

As time when on (marked as seconds on the x-axis), the spawn interval range for enemies would decrease. Again, it was good enough to get by, but when I needed to do more dynamic things, it just wasn’t functional.

My first decent revision to the enemy spawner was when someone told me that a curve would be much more elegant than those steps. I agreed, not entirely sure how to go about making this work at first. However, it was much easier to implement than I thought. I wound up using an Animation Curve (I’m using Unity 3D for this game). Now, what I do, instead of the steps, and horrible code on different objects, is evaluate the curve over time.

For example, let’s say that a level has 300 seconds. The graph would tell the enemy spawner to create an enemy every 7 seconds. Eventually, it would be a smaller wait to spawn the closer you get to the end of a level. For this curve, I started at the right and went left. Not only was this more elegant, but it would allow me to have spikes where the spawing dramatically increases for moments in time:

This would make this much more interesting. The sharp declines in the graph indicate where the delay between spawn time would decrease dramatically for moments in time.

But, that wasn’t good enough. The curve would always be the same, no matter what (unless I randomly generated the curve values at the beginning of a level). Each time a person would play out a level, they would know exactly when an enemy would spawn. Even though they wouldn’t know the location at which they would spawn, players would still know when. In order to keep people on their toes, a second curve was added.

In the photo, you can see the drop down menu that has the options ‘Linear’ or ‘Area Between’. For ‘AreaBetween’, instead of evaluating one curve, I evaluate the two curves and choose a random number between the two. Now, if someone chooses to play specific levels where “AreaBetween” selected for spawning, spawning will be less predictable.

The next big change was dealing with the odds of when a particular enemy would spawn. The goal was to give everyone a certain percentage, but use larger numbers than before. 1 – 10 on a 20 point scale wasn’t good enough. So, the first thing I tried to do was make it out of 100. I added an extension method which checked between two different numbers. If ‘x’ was between 1-25, return enemy one, and so on for the other 5 slots. This was nice, but I still had limited control over the actual percentages. I really wanted to be able to say ‘Make slot one spawn 43% of the time’, instead of being stuck fixed with numbers like 25%, 50%, etc. This took me a while to actually finish properly — I found a few bugs within the system not too long ago — but what I do now is delegate out a certain number of points to each enemy slot. So, slot one could have 50 points, slot two could have 30 points, slot three to six could have 23, 18, 10 and 5 (total 144). These numbers are used to set the spawn ranges. The enemy in slot one will spawn when the random number system selects a number between 0 – 49. The enemy in slot two would spawn if a number between 50 – 79 is selected. 79 is chosen because the second slot was given 30 points (remember, I’m staring at 0, not 1). Following this suit, slot three would have the range 80-102, slot four 103-120, and so on.


This felt miles better than the previous code. The next thing I did was make this even more dynamic, and added ways to add or remove the number of enemy slots that I needed. There was no need for me to have 6 slots in a level, and 4 with 0pts for spawning if I did not need that enemy to spawn. This meant doing more work to how the ranges were handled, but the work was worth in, in my opinion.

There are still a few more things that I felt were missing. It was nice to have everything be a bit more ‘random’, but now I wanted some control back. The next feature implemented was the “Forced Spawn” list, composed of enemies that I wanted to spawn manually. I had two methods of how I felt this should be managed. Either spawn enemies when there are ‘y’ seconds left, or spawn a specific enemy every ‘z’ seconds. Both were great options, and it wasn’t as bad as I thought, implementing both of these.

The first slot contains the type of bot being spawned, the second field was the method of how the bot was going to be spawned (interval or countdown) , the third field was a number associated with the type of forced spawning that took place. For interval spawning, the “Interval” field was the delay between each time an enemy is manually spawned. The “Time” field for “Countdown” was the time when an enemy would spawn. In this example, a Masked Bot would spawn when there are 120 seconds left in the level. When interval spawning is selected, you also had the option of choosing when we start the spawning an enemy at the selected interval.  Finally, the last option is “how many enemies should spawn during the forced spawn”.

The question I face now is, “When do I stop adding features to the enemy spawner?”. The answer could be, when I don’t need anymore, but new features come to mind every time I stop and take a look at this. Right now,  I think I have enough, and I may just be at the point where I have to actually say ‘It’s time to move on’.

But that’s it for now. I need to test all of the code that I just changed…again.

Comments Off on How the SquareBots are spawned

Title Screen Redesign

Posted in Tone Def by Shawn on July 14, 2012

I’ve actually been wanted to replace my current title screen for Tone Def: Revenge of the SquareBots. The biggest annoyance was the subtitle ‘Revenge of the SquareBots” subtitle. It really ruined things for me. Second biggest annoyance was everything else.

I was happy with this for a while until recently. To be honest, what sparked this discomfort is still unknown. Still, right now, it seems like it’s for the better.

The Old Title Screen

 

The new title screen

The background also scrolls, which makes the page feel a bit…alive, for lack of a better term.

Comments Off on Title Screen Redesign

Tone Def s.w.a.g: Hand Fans

Posted in Tone Def by Shawn on July 9, 2012

So, Artscape is in about two weeks! I’m pretty excited to be attending, and don’t want to show up empty handed. Well, I am going for my game, but I also want to hand out things. People like swag. I still enjoy swag. Well, I don’t see why I wouldn’t enjoy getting free stuff at this point in my life, but regardless, I wanted to give random things away. I already have stickers, but it’s definitely not enough. So, I had to think of something new.

Fans!

Why fans?

It’ll probably be hot in Baltimore. And fans will keep you cool. These are hand fans, so you’ll need to do a little work, but hopefully, it’ll be worth it. Let’s just hope it doesn’t suddenly become 32 degrees that weekend. Then people may start using them to burn and keep warm. Actually, that’s not a bad idea. Light it up, and carry it around, like a torch….

Anyway, I didn’t want to spend a ton of money to make these fans, so I went to the trusty, never faulting internet to find out how to make them. While searching, I stumbled upon a make your own fan kit, and picked them up. At the time, they were $12. They seem to go up in price. I’m guessing they realized they could make a killing of off me. If I went down the road of buying fans, I probably would have spent more, since I’d be using someone’s machine/ink/tools/time/etc. Plus they need to turn a profit. Rumor has it that the hand fan industry is pretty competitive. Yeah, time is money, and the time put into making this could have gone to something else, but I didn’t find that feasible for this project.

So, courtesy of Amazon, I received my kit. Not too long afterwards (actually, about three weeks later), I began to assemble the fans.

Tools for the fan. The fan paper, and tongue depressor with adhesive on both sides.

The fan paper was thicker than your normal piece of printing paper, which is good for fan purposes. The tongue depressors came with adhesive on both sides, protected by those strips of paper. The kit also came with a number of white bows (as seen on the Amazon link), but I gave them away. It didn’t really fit the tone of the game……this time. The paper on the top right was the template for the fans on standard paper. I was hoping to go to Staples and have them assist me with making fast and easy copies of a design, but I couldn’t, due to the fan paper being perforated. Their machines were too high speed, and would have potentially ruin the paper. The paper is actually actually very sturdy, but I guess it’s better that I didn’t take the risk. I was also very fortunate, as I had an available printer/scanner. The scanner part made things much easier. So, now the design part!

The design on the computer with the paper template included in the background

I had scanned in the template copy so the size of the design was to scale. It was a standard 8 1/2 x 11 piece of paper, but it would save me time to actually design it on my computer with the template in the background. Of course, when I printed it, I wouldn’t include the background. It was in a different layer in my art program, so it was simple to remove the background:

Design sans the template in the background

Now to print! I didn’t want to just go wild and print a bunch of copies, as this was the first time I was going to use this printer. Making a large number of copies right away could have resulted in wasting paper. Instead, I ran a few test:

Multiple versions of the design printed

The top copy was one made in black in white, simply to save color ink (I hear that it’s expensive). The middle one was my first color print. You can see that the color is a bit faded.  The “High Quality” option selected, which is the reason for that. Again, it was my first time with that printer, so I didn’t know what results to expect. The bottom copy was high quality, and it shows; the colors are richer. However, I also played around with some other settings, and you can see the result of that when comparing the top two to the final one. The two images are a closer to the center and the size of the images is actually smaller when compared side by side. Using my play sessions as experience, it was time to finally print this.

Printing on the fan paper

I read online that the slightly thicker than normal fan paper could jam the printer easily, so I took my time with printing. At first, they went in 3 at a time, then I got a bit pompous and moved up to 5, then 7. There was a minor setback. I made an attempt at 7, and two pieces were fed through the machine at once. Nothing was ruined, fortunately. The computer just yelled at me since it was expecting 7 pieces of paper and didn’t realize that two went in at once. Silly computer.

After printing, the fun task of assembling the fans came. This wasn’t difficult, just a bit time consuming. So, cue the TV as background noise. (Also, I may start watching Bones now). It didn’t take too long, but the results are:

The finished TDROTS hand fans

I’m happy with the end result. So much that I plan to make a few more. There are about about two weeks until Artscape and the Gamescape Showcase, which is enough time to make a few more. If I attend any other events after Artscape, I’ll definitely bring a few to those. But that’s it for now. There’s some game work that needs to be done…..

Comments Off on Tone Def s.w.a.g: Hand Fans

Tone Def Iteration 3

Posted in Music, OriGamInc, Tone Def by Shawn on June 14, 2012

Looks like I’m getting to the end of iteration 3. Iteration 3 has been going on for quite some time, and I believe that I have made progress.

Progress is a vague term, and I guess I should narrow things down my specifying it as significant/little progress.

I think it has been better than bad. The iteration began with a few task, but at this point I am at 60 task for this iteration. Of course, this is a longer iteration that other ones, which makes sense with the increase in things I have to do for this specific iteration. These past iterations also lined up with important dates, which is why they haven’t really been consistent. However, now that I have no more ‘non self-imposed’ deadlines coming up, I will start to set up my iterations with a dedicated interval most likely every 2 to three weeks.

So what was done this iteration? More music, more levels, more modes, more instruments. However, what I really want to include is a decent tutorial system, rather than what I have now- temporary slides that show you how to play.

In other news, I’ve been planning out the details for the soundtrack to TD:ROTS. Most of the music is designed to loop smoothly as you complete the level, but that does leave something left to be desired when listening to the tracks. The goal is to have multiple versions of almost every track, one being the looped version, the other being a version that plays out a bit more traditionally; it would include an opening/closing, and possible some more tidbits which would be difficult to include in the game.

Oh, and I’m currently looking for play testers for TD:ROTS. In person only!

And there’s an interesting (at least, I think it’s interesting) article in Technically Philly, feature Tone Def. During that, I realized that I like to talk about my game too much.

But that’s it for now. I need to become a bit more active with this blog. I’ll probably do that after they add that often requested 25th hour to the day.

Comments Off on Tone Def Iteration 3

Summer plans – 2012

Posted in OriGamInc, Tone Def by Shawn on May 31, 2012

What do I plan to do during the Summer of 2012?

[updated June 14th 2012]

Comments Off on Summer plans – 2012

Keeping the beat.

Posted in Other, Tone Def by Shawn on May 8, 2012

Well, I’m still working on Tone Def: ROTS.

A lot actually. Which is why I haven’t been updating this as recently as I normally do.

And technically, I’m in iteration 3. The 3rd iteration ends around mid June, so around 30 days from now. In regards to my progression with this game, there’s been a lot of development in regards to what the player can actually do. However, there needs to be more for the player in regards to progression. In most tower defense games, you don’t have everything you need/want at the beginning of the game. You have to earn it, either by playing long enough, destroying enough enemies, or maybe another, non-traditional method. My current concern is to figure out the best way to go about expanding on what is currently set up. It would be nice to implement something new or unconventional, but it can’t be too obtuse, preventing the player from understanding how to acquire more tools for the game.

Side note: One nice thing I find about writing updates on work is that it helps get the through processes going. During this minor update, I though of a few new (reasonable!) ideas that I would like to include, related to player progression and design, including a really cool tree-like design.

That’s it for now though. I need to get back on track with planning, and figuring out how I want to deal with my future task.

This wasn’t a very good update for anyone but myself……

Comments Off on Keeping the beat.