So, my last blog was discussing how I wanted to go about handling the GUI. Well, we decided on a method! We’re keeping the method of creating and drawing a window nearly the same. We’ve decided to split the backgrounds and borders into different template images, then we’re gonna pass in the size of each of the “cells” for drawing, then it’ll just loop through the templates and grab the portion of the window that’s to be drawn. Simple enough! So we’ll have dynamically sized windows, perhaps based on content, or maybe fixed-size, like if we want dialogue windows to be similar to Final Fantasy or Megaman.
 
Unfortunately, I didn’t get to work very much on the game this previous week. The Boss-man and I went on a three-day training trip to LA to learn about some integration software for businesses. Yay business and utility software! :D
 
We got back Wednesday night, and Thursday was spent talking and learning a little about SAP software and working on the GUI, and the majority of Friday was spent learning Windows PowerShell and writing a BASH script to grab some data for DIV Creative to give to Lauren, our sales person.
 
PowerShell’s pretty easy and similar to Bash scripting. You simply write out the functions' names like "Get-Content" with the arguments as spaces after. I guess it’s no different than calling a utility right on the command line and passing things in.
 
SO! Fun utilitarian and business-oriented work. I’m hoping by the end of this week I’ll have some more fun things to talk about.

So, my last blog was discussing how I wanted to go about handling the GUI.  Well, we decided on a method!  We’re keeping the method of creating and drawing a window nearly the same.  We’ve decided to split the backgrounds and borders into different template images, then we’re gonna pass in the size of each of the “cells” for drawing, then it’ll just loop through the templates and grab the portion of the window that’s to be drawn.  Simple enough!  So we’ll have dynamically sized windows, perhaps based on content, or maybe fixed-size, like if we want dialogue windows to be similar to Final Fantasy, or Megaman.
 
 Unfortunately, I didn’t get to work very much on the game this previous week.  The Boss-man and I went on a 3-day training trip to LA to learn about some integration software for businesses.  Yay business and utility software!  :D
 
We got back Wednesday night, and Thursday was spent talking and learning a little about SAP software and working on the GUI, and the majority of Friday was spent learning Windows PowerShell and writing a BASH script to grab some data for DIV Creative to give to Lauren, our sales person.
 
PowerShell’s pretty easy and similar to Bash scripting.   You simply write out the functions’ names like ‘Get-Content’ with the arguments as spaces after.  I guess it’s no different than calling a utility right on the command line and passing things in.
 
SO!  Fun utilitarian and business-oriented work.  I’m hoping by the end of this week I’ll have some more fun things to talk about.

I'm totally fascinated by games that successfully gamify busy work. I've got an insanely addictive personality, and occasionally I'll find a busy work "game" that completely sucks away my free time. Let's look at some of them!

Plants vs Zombies:
    PvZ has some of the most addictive gameplay I've ever played, but what made me end up playing for days was the stupid garden minigame. You could grow plants, and I became obsessed with growing one of every plant. Usually, you would earn a random seed and hope for a new one, but they had a mechanic where you could buy a seed with a specific chance of getting a new plant. For me, this meant powergaming the earning mechanics so that I got as much gold as fast as possible to be able to afford those special plants.
Progress: Took me weeks, but I eventually "caught 'em all"
 
Dragonvale/Gizmonauts:
    I play Gizmonauts, but Dragonvale is the more popular one. These games are city-builders, and you earn gold by populating your city with levelable robots. What's made me play for so long is their "special" bots. Special bots can only be built by breeding specific types of robots, and only then the breeding is a very rare chance. (Any bot can also be bought using an in-app purchase special currency, but their currency packs are prohibitively expensive for what you get in return.) On average, a breeding takes about seven hours. So far they've released five "special" robots, one of which is a VERY random drop (1/160ish chance). Everything is purchased using in-game gold, including weed management, land upgrades, and habitats.
Progress: I play for about ten minutes every day, and I have every special bot and am level 38/50.
 
Tiny Tower:
    This game devoured my soul. Tiny tower is the simplest game on this list, but easily took up the most of my time. It's so pixelly, I couldn't resist. In it, you build a tower floor-by-floor, and fill it with workers/residents. Building up to the top floor is easy (just takes a lot of time) but what really drew me was the job mechanic. Every new resident you bring into your building has a "dream" job and a level. The top level is level nine, so I became obsessed with filling my tower with level nine dream jobbers. Hard mode, essentially. To bring a new person into your tower, you have two options: 1) Every thirty seconds or so, a new person will want to take the elevator to a specific floor. If they land on a residential floor with an empty space, they move in. If they land on a retail floor, they disappear. 2) Use up a single "buck" to instantly move a randomized resident in to a floor. You  get about 7–20 bucks a day depending on how much you play, or you can buy hellaciously expensive "packs."
    In the early game, when every elevator run had a high chance of hitting an empty residential floor, the elevator was a valid way of getting new residents. But around floor 100/160, if you had a bunch of full residential spaces it became way too low of a chance that the new possible resident would want a ride to that specific floor. So it became a game of grinding out the free bucks, and rolling for the exact person you needed. In the end game, I had only two spots left, both in the same retail store, and grinding those two dream job level nines took me over a month and over 1000 "bucks."
Progress: Completed hardmode, will never play it again.
 
I'll probably write more later. Games like Pixel People, the Steam Trading Card game, and Puzzle & Dragons deserve a writeup too.

I'm totally fascinated by games that successfully gamify busywork. I've got an insanely addictive personality, and occasionally I'll find a busywork 'game' that completely sucks away my free time. Let's look at some of them!

Plants vs Zombies:
    PvZ has some of the most addictive gameplay I've ever played, but what made me end up playing days was the stupid garden minigame. You could grow plants, and I became obsessed with growing one of every plant. Usually, you would earn a random seed and hope for a new one, but they had a mechanic where you could buy a seed with a specific chance of getting a 'new' plant. For me, this meant powergaming the earning mechanics so that I got as much gold as fast as possible to be able to afford those special plants.
Progress: Took me weeks, but I eventually 'caught 'em all'
 
Dragonvale / Gizmonauts:
    I play Gizmonauts, but Dragonvale is the more-popular one. These games are city-builders, and you earn gold by populating your city with levelable robots. What's made me play for so long is their 'special' bots. Special bots can only be built by breeding specific types of robots, and only then the breeding is a very rare chance. (Any bot can also be bought using an in-app purchase special currency, but their currency packs are prohibitively expensive for what you get in return)  On average, a breeding takes about 7 hours. So far they've released 5 'special' robots, one of which is a VERY random drop. (1/160ish chance) Everything is purchased using in-game gold, including weed management, land upgrades, and habitats.
Progress: I play for about ten minutes every day, and I have every special bot and am level 38/50.
 
Tiny Tower:
    This game devoured my soul. Tiny tower is the simplest game on this list, but easily took up the most of my time. It's so pixelly, I couldn't resist. In it, you build a tower floor-by-floor, and fill it with workers/residents. Building up to the top floor is easy (just takes a lot of time) but what really drew me was the job mechanic. Every new resident you bring into your building has a 'dream' job, and a level. The top level is level nine, so I became obsessed with filling my tower with level nine dream jobbers. Hard mode, essentially. To bring a new person into your tower, you have two options: 1.) Every 30 seconds or so, a new person will want to take the elevator to a specific floor. If they land on a residential floor with an empty space, they move in. If they land on a retail floor, they disappear. 2.) Use up a single 'buck' to instantly move in a randomized resident to a floor,. You  get about 7-20 bucks a day depending on how much you play, or you can buy hellaciously expensive 'packs.'
    In the early game, when every elevator run had a high chance of hitting an empty residential floor, the elevator was a valid way of getting new residents. But around floor 100/160, if you had a bunch of full residential spaces it became way too low of a chance that the new possible resident would want a ride to that specific floor. So it became a game of grinding out the free bucks, and rolling for the exact person you needed. In the end game, I had only two spots left, both in the same retail store, and grinding those two 'dream-job-level-nines' took me over a month and over 1000 'bucks'.
Progress: Completed hardmode, will never play it again.
 
I'll probably write more later. Games like Pixel People, the Steam Trading Card game, and Puzzles vs Dragons deserve a write-up too.

Not much game progress on my end this week, as we just hired a saleswoman! We're branching off into basic web design, and I spent a big chunk of the week training our new hire, Lauren. She's a New Media graduate, and has a great mind for social media and SEO. She'll be an excellent addition to the team, especially as we start releasing games and more community interaction.

I come from IRC/AIM/forums, and I'm much more comfortable there than I am with managing the admin of Facebook. I enjoyed using Twitter during the Kickstarter, but unless I'm using it for something I don't use it much. Conversations are too hard to follow. Lauren's presence is going to be awesome, because now I can just focus on my @pixeltramp twitter handle and leave the rest to her.

Not much game progress on my end this week, as we just hired a saleswoman! We're branching off into basic web design, and I spent a big chunk of the week training our new hire, Lauren. She's a New Media graduate, and has a great mind for social media and SEO. She'll be an excellent addition to the team, especially as we start releasing games and new more community interaction.

I come from IRC/AIM/Forums, and I'm much more comfortable there than I am with managing the admin of Facebook. I enjoyed using Twitter during the Kickstarter, but unless I'm using it 'for' something I don't use it much. Conversations are too hard to follow. Lauren's hiring is going to be awesome, because now I can just focus on my @pixeltramp twitter handle and leave the rest to her.

So, the thing that I started working on this week, and was really hoping that it would only take me two days (at least I learned early about this whole setting deadlines business) is a GUI and windowing system for Deceit. I wanted to design it in a way that would be usable for other games that rely on HTML5’s canvas and JavaScript with some simple modification in the future. The way I’m tackling it is a little bit different because I’m trying to keep it as in line with Steve’s vision of the GUI and windows as possible. He’s the one that makes it pretty, and I’m the one that makes it work, but in this case it’s a prettiness/usability matter, so I’m going to do what he tells me.

He gave me a 40px x 40px template for the first window to be based off of, and after working something out to draw the windows, I’ve decided that’s what the rest of the templates should be, at the moment.  If we ever need a custom window or overlay, Steve could design it and base the dimensions and whatnot off of the resolution we decide the canvas to be and we could just draw it out to the screen.

Now what we wanted was to have a dynamic GUI, so the user could click and drag windows and maybe resize them if need be. I know many times when I’m playing a game, if the windows are static and in an inconvenient spot, I get really frustrated, so I want to make them as seamless with the games as possible. 

Since the scaling unit of our game is 10px =1m, we’ve decided to just let the GUI’s size be based off of that 10px size as well. Our other games are most likely not going to use that same scale, so all it took was a member variable and for the drawing method to take that variable into account to allow the changing of scale later on.

Since Steve gave me a window template of 40 x 40, I’m going to look at that as a 4 x 4 template because of scaling. How I draw the window out based on its size is pretty much a O(n) operation (if you consider n to be the units2 size of the window). It starts drawing from the upper left of the window and travels across in the positive x direction, which in this case is to the right (and hopefully for all other cases in the future, unless I work with some engine that has a strange coordinate system) based on the size of the window. If you dictate that the window should be 100px x 100px, then it scales it into the units of the game, in this case 10 x 10, and then draws it out.  So it will draw a square from the template 10x10 (or 100) times.

I’ll need to work on how it picks out the "frames" from the window template, though, because as it is, I have it check whether it’s drawing the first row, second row, any row in between, and then the second to last row, and then finally the last row. I have it checking like that because Steve drew up the window to have shading in certain parts. He asked if having a 3x3 template would screw things up, and as it is now, it would, because I (foolishly) hard-coded which frames were to be used in certain situations. Here’s an example in some pseudo-code:

                if (first row) {

                    if (first column) {

                                        Draw the top left corner, or frame 0;

                        }

                    else if (second column) {

                                        Draw frame 1;

                        }

                    else if (last column) {

                                        Draw frame 3;

                        }

                    else Draw frame 2;

                }

That’s pretty much how it goes, all the way up to frame 15 (16-1, or 4x4, starting he count from 0).  What I should do is take the total width, in pixels, of the frame template image, then adjust it to the scale, then have a variable set dictating how many rows and columns the template has, and then divide the scaled width by that variable to get the “frame” (I just noticed I’ve been using the word “frame” to describe each cell of the template image, so when I say “frame” I mean “cell” from the image, not the frame of the window) size for the window. I won’t adjust for crazy-shaped or oddly-sized templates for the windows, because I don’t think we’re going to have hexagonal windows where the window’s template is wider than its height.

Changing it to work like that instead of having it set in stone which frames (or cells :D) it should use for which situation will allow us to use frame templates that are 3x3, 4x4, or 16x16 (god help us) if need be.

I’ll have to think a little bit more about how I want to do this. The windows are being drawn for the moment . . . but now that I’ve written this all out and thought about it, I might have to change it a little bit, haha!

So, the thing that I started working on this week, and was really hoping that it would only take me two days (at least I learned early about this whole setting deadlines business…) is a GUI and windowing system for Deceit.  I wanted to design it in a way that would be usable for other games that rely on HTML5’s canvas and JavaScript with some simple modification in the future.  The way I’m tackling it is a little bit different because I’m trying to keep it as in line with Steve’s vision of the GUI and windows as possible.  He’s the one that makes it pretty, and I’m the one that makes it work, but in this case it’s a prettiness/usability matter, so I’m going to do what he tells me.

He gave me a 40px x 40px “template” for the first window to be based off of, and after working something out to draw the windows, I’ve decided that’s what the rest of the templates should be, at the moment.  If we ever need a custom window or overlay, Steve could design it and base the dimensions and whatnot off of the resolution we decide the canvas to be and we could just draw it out to the screen.

Now what we wanted was to have a dynamic GUI, so the user could click and drag windows and maybe resize them if need be.  I know many times when I’m playing a game, if the windows are static and in an inconvenient spot, I get really frustrated, so I want to make them as seamless with the games as possible. 

Since the scaling unit of our game is 10px = 1m, we’ve decided to just let the GUI’s size be based off of that 10px size as well. Our other games are most likely not going to use that same scale, so all it took was a member variable and for the drawing method to take that variable into account to allow the changing of scale later on.

Since Steve gave me a window template of 40 x 40, I’m look at that as a 4 x 4 template because of scaling. How I draw the window out based on its size is pretty much a O(n) operation (if you consider n to be the units2 size of the window). It starts drawing from the upper-left of the window and travels across in the positive x direction, which in this case is to the right (and hopefully for all other cases in the future, unless I work with some engine that has a strange coordinate system) based on the size of the window.  If you dictate that the window should be 100px x 100px, then it scales it into the units of the game, in this case 10 x 10, and then draws it out.  So it will draw a square from the template 10x10 (or 100) times.

I’ll need to work on how it picks out the “frames” from the window template, though, because as it is, I have it check whether it’s drawing the first row, second row, any row in between, and then the second to last row, and then finally the last row.  I have it checking like that because Steve drew up the window to have shading in certain parts.  He ask if having a 3x3 template would screw things up, and as it is now, it would, because I (foolishly) hard-coded which frames were to be used in certain situations.  Here’s an example in some pseudo-code:

                        if (first row) {

                            if (first column) {

                                                Draw the top left corner, or frame 0;

                                }

                            else if (second column) {

                                                Draw frame 1;

                                }

                            else if (last column) {

                                                Draw frame 3;

                                }

                            else Draw frame 2;

                        }

That’s pretty much how it goes, all the way up to frame 15 (16 – 1, or 4x4, starting he count from 0).  What I should do is take the total width, in pixels, of the frame template image, then adjust it to the scale, then have a variable set dictating how many rows and columns the template has, and then divide the scaled width by that variable to get the “frame” (I just noticed I’ve been using the word “frame” to describe each cell of the template image, so when I say “frame” I mean “cell” from the image, not the frame of the window) size for the window. I won’t adjust for crazy-shaped or oddly sized templates for the windows, because I don’t think we’re going to have hexagonal windows where the window’s template is wider than its height.

Changing it to work like that instead of having it set in stone which frames (or cells :D) it should use for which situation will allow us to use frame templates that are 3x3, 4x4, or 16x16 (god help us) if need be.

I’ll have to think a little bit more about how I want to do this.  The windows are being drawn for the moment... but now that I’ve written this all out and thought about it, I might have to change it a little bit, haha!

In light of Nathan’s opus, I will keep my entry short, on the importance of writing down what you are actually doing. Earlier this week we were discussing as a team how we were managing some graphical elements and the gut response from development was that we needed to structure things in a specific fashion to not break our current logic. Ultimately this was accepted, and everyone is just working around this limitation in our design.
 
Now to be clear, I am not advocating a no-limits mentality where you bend to every idea of any particular department. Limits on design and function are incredibly important and should be adhered to once decided upon. These limits however should be for good and communicable reasons that are backed up by a solid foundation, for example. To implement that feature as you have described it will take three to four days of design and another week of testing and rework to implement. This brings me back to the idea of writing down what you are doing. During our blogging session Nathan was writing about the techniques and design techniques used within Deceit and while writing his blog realized that his initial assumptions were flawed and what the art department was asking for would indeed be possible with only some very minor adjustments. If we didn’t do our weekly blog our final product would have been less interesting than it is now, and will be simply because we would have limited ourselves with no solid reason to back it up. This leads me to the conclusion that writing out your thoughts can definitely help bring a problem and the possible solutions into a greater degree of clarity.

In light of Nathan’s opus, I will keep my entry short. The importance of writing down what you are actually doing. Earlier this week we were discussing as a team how we were managing some graphical elements and the gut response from development was that we needed to structure things in a specific fashion to not break our current logic. Ultimately this was accepted, and everyone is just working around this limitation in our design. Now to be clear, I am not advocating a no-limits mentality where you bend to every idea of any particular department. Limits on design and function are incredibly important and should be adhered to once decided upon. These limits however should be for good and communicable reasons that are backed up by a solid foundation for example. To implement that feature as you have described it will take 3-4 days of design and another week of testing and rework to implement. This brings me back to writing down what you are doing. During our blogging session Nathan was writing about the techniques and design techniques used within Deceit and while writing his blog realized that his initial assumptions were flawed and what the art department was asking for would indeed be possible with only some very minor adjustments. If we didn’t do our weekly blog our final product would have been less interesting than it is now, and will be simply because we would have limited ourselves with no solid reason to back it up. This leads me to the conclusion that writing out your thoughts can definitely help bring a problem and the possible solutions into a greater degree of clarity.

It’s a common theme among small business owners that the hardest part is giving up control and I would say this is true. Being on my second small business myself, I would also say that it is much easier the second time and just as it was in the first an absolute necessity for growth. I had a pretty good idea what I was getting into with Tiger Sheep, and I know the role that I eventually want to play and the roles that I don’t. Like all good plans though, it enters a state of flux the moment real life gets ahold of it and we end up rolling with the punches and just trying to direct the business to the end goal.
 
This brings me back to letting go of control. In order to reach the end goal of almost any endeavor when you are the employer, you have to absolutely have to relinquish the minutia of daily projects and trust your employees to get it done. As an example, my first hire for Tiger Sheep was Steve, whose skill set was completely complementary in nature with no real overlap making it easy. I didn’t have to give up any responsibilities except those I was clearly not qualified to be handling. This state of business worked great at first but like all businesses hope to do, we grew and our project load increased to the point where I was becoming a real bottleneck. This bottlenecking is a symptom within the business that usually means it is time to start giving up some responsibilities, and if you have been following my previous posts you already know that to relieve some of the bottleneck I hired Nathan.
 
The trick, though, to having Nathan be an effective crewmember is to let him do his job and to not micromanage. This is the step where a lot of business owners fail, they cannot let their employees make mistakes or find their own solutions to problems. As anyone who has worked under a micromanager can attest, it is typically not a pleasant experience and ultimately leads to one of two outcomes: either the employee gets fed up and quits, or the employer feels they have to check and redo everything anyway and lets the employee go. Ultimately I have to trust my people to do the jobs they were hired for so that none of us go mad and the business can thrive. As I have been able to trust Nathan after verifying his work every few days just to make sure our visions are reasonably in sync, it has freed up my time to focus on my other tasks more fully, and ultimately the business is doing better with development humming along. Art is no longer waiting on projects to get past my bottleneck, and SAP projects are getting a cleaner, more focused response since I don’t have any nagging concerns about development holding me up.

It’s a common theme among small business owners that the hardest part is giving up control and I would say this is true. Being on my second small business myself, I would also say that it is much easier the second time and just as it was in the first an absolute necessity for growth. I had a pretty good idea what I was getting into with Tiger Sheep, and I know the role that I eventually want to play and the roles that I don’t. Like all good plans though, it enters a state of flux the moment real life gets ahold of it and we end up rolling with the punches and just trying to direct the business to the end goal.
This brings me back to letting go of control. In order to reach the end goal of almost any endeavor when you are the employer, you have to absolutely have to relinquish the minutia of daily projects and trust your employees to get it done. As an example: My first hire for Tiger Sheep was Steve, whose skill set was completely complementary in nature with no real overlap making it easy. I didn’t have to give up any responsibilities except those I was clearly not qualified to be handling. This state of business worked great at first but like all business’s hope to do, we grew and our project load increased to the point where I was becoming a real bottleneck. This bottlenecking is a symptom within the business that usually means it is time to start giving up some responsibilities, and if you have been following my previous posts you already know that to relieve some of the bottleneck I hired Nathan. The trick though to having Nathan be an effective crewmember is to let him do his job and not micromanage. This is the step where a lot of business owners fail, they cannot let their employees make mistakes or find their own solutions to problems. For anyone who has worked under a micromanager can attest, it is typically not a pleasant experience and ultimately leads to one of two outcomes: Either the employee gets fed up and quits, or the employer feels they have to check and redo everything anyway and lets the employee go. Ultimately I have to trust my people to do the jobs they were hired for so that neither of us go mad and the business can thrive. As I have been able to trust Nathan after verifying his work every few days just to make sure our visions are reasonably in sync, it has freed up my time to focus on my other tasks more fully and ultimately the business is doing better with development humming along. Art is no longer waiting on projects to get past my bottleneck, and SAP projects are getting a cleaner more focused response since I don’t have any nagging concerns about development holding me up.

Hallo!

Physics!  That’s what I’ve been playing with over the past week.  We decided to start using Box2D for our physics and collision handling.  The fellas at Impact created a pretty simple wrapper for it, so we figure, what the hay, it’s early on in development, and having a good handle on a little more advanced 2D physics and more robust entities couldn’t really hurt.  The worst thing that it’s really done is make us take a little longer to get things truly rolling.

So first we’ve added a finite state machine, then I figured out layered sprites (which is interesting, since we changed to Box2D for physics, we had to work around how we handled layering a little, but no biggie), and now we have a little more advanced physics and collision.  I think that’s about all we really need to really get started on some other content for the game!

There are some aspects of the physics we’ll have to really nail down, like how we would like the player to move on the ground and in the air.  How will he react when he’s hit by bullets or particles?  How will enemies react, physically, when the player hits them?  These are things we’re still mulling over, but I think we have a decent idea, and it’s just a matter of playing with numbers once everything is in place.  It’s been kinda fun messing with it a little in the meantime, like having bullets smack the player around, pushing mannequins and so on.

What my big focus for the rest of this week will be is cleaning some things up and making the code reusable.  Our first tenet is ‘make it fun’ followed by ‘make it work’.  ‘Making it fun’ is coming up with great ideas, ‘making it work’ is just getting it into the game as a proof of concept.  Then the next is to ‘make it fast (and reusable)’, so I’m going to take what we have and break some functions down and remove some of the copy+pasted pieces.  I do my best to break functions down into simpler parts and keep variables and whatnot from becoming obfuscated, but at first I’m just gonna throw it in and get it going, and after I get a handle on it, I clean it up.

After that, I’m going to make some development and testing tools, and try to figure out Box2D’s debug drawing capabilities!

Post is best read with this in the background: http://www.youtube.com/watch?v=13tnjh3dZw4

Behold! New clothing options:

The Rogers, for peaceful players looking to be a good neighbor.

The Casual Friday, for the the thrift shop set.

The Draper, for those of us who have never heard of 'business casual.'

And the McClane, for the Alan Rickman-phobic.

The better part of my week was spent adjusting the player's clothing, which gave me the chance to add a couple new outfits for the player. I also got the chance to FINALLY fit the player into a 40x40 grid instead of 42x42, so now the player will play much nicer with the level's 10x10 grid.

We've been brainstorming what to do with the player's clothing, and user choice. We want a little bit of character customization, but we don't want a full character generation sequence. We've decided to have an office that you start out in, and the user can switch their clothing there. Want a (terrible looking) fedora? Want a trenchcoat? Toggle them, and then choose your outfit!

You'll earn upgraded equipment throughout the game and some of these upgrades will be visual, but for the most part your clothing selections in this office will stick with you unless you choose to return to the office. Should be fun.http://www.youtube.com/watch?v=13tnjh3dZw4

Well, it is week 2 of having a dedicated developer and I must say it is all that I had hoped for. All of the projects that I have wanted to get done I was able to draft up some rough specs for, and just turn Nathan loose on them. It's amazing, because I back in 2-3 days and we have a working prototype. Having this extra capability at the company’s disposal, especially when those capabilities are creative in nature comes with one terrible pitfall… scope creep. Scope creep means different things for different industries, but is most commonly used in development to talk about when expected and requested changes evolve and grow more numerous and complex throughout a project until the final deliverable looks nothing like the original plan and takes 3 times as long in addition to costing 10 times as much.
 
For Deceit, I have gotten into the habit of carefully assessing the scope of the project every week to make sure that we don’t fall prey to impulse design changes. The hardest part of this relates to my post last week, with making accurate time assessments of what new features and functionality will really take to add using the tools and architecture that we have committed to for our first couple of projects. In Impact, for example, it is pretty easy and intuitive to extend the base functionality. This flexibility is great, and we have identified 3 elements of functionality that impact lacks natively to extend. These three major extensions are a Finite State Machine to handle more complex game logic, Layered Sprites for a more dynamic character and world, and dynamic camera and lighting systems to help with atmosphere and to enable some more interesting level mechanics. The rest of the time should be spent on level design, player and enemy behaviors, and art. This will allow us to hopefully roll out a playable level ASAP and a finished first chapter shortly after that.
 
Tiger Sheep is looking at a 10,000-hour project, so it is actually easier for me to manage scope creep as I have an easy outlet for great ideas that don’t fit nicely into the plan for game 1, and that is that we will simply add some of them to games 2 or 3. Since each game we put out we will be trying for a few new features and refinements at the minimum, all of the interesting ideas go into the list of things that sounds awesome and/or useful. When it comes time to start game 2 we will crack open the list and choose the most worthy candidates to be added to the scope of the new project. For us, this approach has been effective and so far we are keeping the scope in check and the game is progressing faster than ever before.
 
Until next week,
John-Michael

Hello, world!

What I’d like to speak at you about today would be composite sprites, or multi-layered sprites!  We thought it would be a really cool idea to have modular equipment for the player, but aside from just affecting stats, we want it to affect how the player looks himself.  More than that, we were thinking it’d be cool if you could have your hat shot off, or if an enemy could steal your gun and you could watch it fly away (and maybe steal it back :D).   

Implementing composite sprites also means we can have dynamic enemies and more interesting boss fights.  We haven’t dealt with composite sprites in the likes of Vectorman and such, yet, but I’m sure we will.  It’d be neat to have large bosses with moving parts.

So, we had to figure out how we wanted to do this.  The beautiful thing about programming is that there is almost an unlimited number of ways to implement something.  It’s also a bit of a curse.  We found a couple of different ideas for doing things and kicked some of our own around a little as well, but settled on the equipment of the player being their own entities in and of themselves.  We decided to have them be actual objects, so they could have physical properties and be affected by enemies and different situations.

One of the benefits of this, is that we didn’t have to code a method of generating an entirely new sprite sheet for the player based on their current equipment. We can just grab the (X, Y) coordinates of the player and tell the equipment where to be from there.  It’s actually a bit of a parent-child relationship.  The player owns the equipment, so the player essentially tells the equipment where to be, and the player’s state defines the animations and such for the equipment, as well as the player itself.

The only major hiccup that we came across while trying to implement it, is that Impact kept deciding to draw the hat and coat behind the player.  I almost tore my hair out trying to figure what exactly was going on at first.  I wrote a couple of log statements for debugging it, and could see that the object was being instantiated.  The hat was in the memory, but it wasn’t appearing!  Well, that’s when I figured out it was drawing the pieces of the player in the wrong order.  Impact has a property for entities called the ‘zIndex’.  I changed the zIndex for each piece of the equipment and also for the player, but it was still drawing in the wrong order. Ugh.  Well, not only did I have to specify the zIndex, but I had to tell Impact to sort the list of current entities by the zIndex.  I called that sort function, but it still wasn’t drawing correctly.  It turns out, I had to tell Impact to sort the entities by zIndex in between the update cycle, before the frame was drawn and before the next cycle began.  Once I did that, everything was hunky-dory.  Now it’s just a matter of cleaning things up and making it nicer to add new things in the future.

After getting the state machine and these layers of sprites lookin’ good, there’s some business things we need to take care of, so it might be a day or two before I’m chugging on the game again.

Tune in next week for another episode of 10000 Hours: A Deceitful Programming Extravaganza!

Tags: 

• featured

We realized recently that we needed layered sprites. We plan on having multiple coats, multiple hats, multiple shoes, multiple ties, multiple everything, and making a separate spritesheet for every possible combination would have been a hassle and seemed like the wrong way of going about it.'

On my end, changing this made things a little bit of a hassle. Our current textured protagonist was made with no hat, black shoes, a white shirt, and a trenchcoat in mind. If we ever wanted different clothing that altered the pixel shape of this basic setup, I'd need to deconstruct him, or else we'd end up with having to make a customized spritesheet for:
 

•        Hat / Trenchcoat / T-shirt /  Shoes

•        Hat / Trenchcoat / T-shirt / Rocket boots

•        Hat / Trenchcoat / Formal shirt / Shoes

•        Hat / Trenchcoat / Formal shirt / Rocket boots

•        Hat / Nothing / T-shirt / Shoes

•        Hat / Nothing / T-shirt / Rocket boots

•        Hat / Nothing / Formal shirt / Shoes

•        Hat / Nothing / Formal shirt / Rocket boots

•        No hat / Trenchcoat / T-shirt / Shoes

•        No hat / Trenchcoat / T-shirt / Rocket Boots

•        No hat / Trenchcoat / Formal shirt / Shoes

•        No hat / Trenchcoat / Formal shirt / Rocket boots

•        No hat / Nothing / T-shirt / Shoes

•        No hat / Nothing / T-shirt / Rocket boots

•        No hat / Nothing / Formal shirt / Shoes

•        No hat / Nothing / Formal shirt / Rocket boots 

...That's just the basic list, too. We plan on adding a lot more variables than just 4 choices, and it would quickly become unmanageable if left to be done manually.

To fix this, we turned to layered sprites. Now, I just have to make sprite sheets for each possible object, and the game only pulls the specific ones currently in use. Get a boot upgrade? The current boot sprite sheet is replaced by the new boots. Want to take your jacket off? Now it's easy, and the character has something undernearth his jacket. (hurr hurr)

The only complication is the Z-axis. Which pieces are on top of which pieces, when there's overlap? What if the protagonist's tie is in front of the trenchcoat in some sprites, and behind in others? Things like that won't be the simplest, but should be an interesting challenge.

This will be a fun process, and I'm looking forward to the possibilities it opens up for later games. Character customization, especially. I want you to be able to choose to have tentacle hair. Someday.

Tags: 

• featured

SO. It's been quite the hiatus, Kickstarter. The last six months have been full of massive side-projects, and while they unfortunately served to pay for our livelihoods, they were… distracting.
Luckily, you’ll be seeing a lot less of that now. These side-projects have let us grow to the point where the company could afford a new hire, and he will be coding 80% of the time. That means more features and more updates, more hour spent towards the game, and finally lets me progress on new sprites and backgrounds.
Overall, we’re at almost 300 hours of work done. That’s severely less than the amount we were planning on being at this point in time, but we hope you’ll forgive us!
We’re really excited to be progressing towards the 1000 hours mark, and to FINALLY get our first batch of rewards out to our wonderful backers. We’ve acquired a vinyl cutter, so you may be getting something a little more exciting than a simple art print! Stick around, there will be a ton of updates about our first game ‘Deceit I’ coming soon!

Ahh, it feels good to finally sit down and start blogging. As the captain of my small crew I can see some exciting times ahead, these last few weeks have set us up for some great successes in the coming months and I am really looking forward to the journey at hand. To start off I would like to introduce Nathan to you, our incredibly patient and supportive fan base,  and if you have not already done so please read Nathan’s introductory post. It is both informative and entertaining.

My initial plan was to talk about development issues encountered during the technical design process, but that responsibility shifting away from myself I too will shift my plans and this series of posts will now be focused on a higher level of design, planning, and management. So to kick off that tangent I will impart my recent lessons from running Tiger Sheep.

Recent Lessons: Companies with two focuses can be tough, without enough support behind you to manage it. For the last 9 months the largest challenge to game design and progress has been myself getting tied up with the SAP side of the business. Since the SAP side of things is our primary source of income, when there are demands, SAP gets done first. Ultimately, I've realized that the 10,000 hour project was not going to progress satisfactorily unless I made a change. That change is the acquisition of a new developer to complement Steve on the less busy art side and get some dedicated hours going on Deceit. I ultimately fell into the trap of underestimating our technology projects. As projects would come in my thought process was as follows:

• Monday: “Great, a new project! I should be done by Wednesday with two solid days of game development.”
• Tuesday: “Going well! Might need a little of Thursday morning, but no problem”
• Wednesday: “Oh crap, didn’t see that coming. There goes Thursday...”
• Thursday: “Ok, almost done! Just a little cleanup left.”
• Friday: “Clean-up and all miscellaneous baseline business tasks are done, Hopefully I can get some time next week to work on Deceit.”

This seemed to happen on a majority of my weeks and I don’t foresee anything changing in the near future. Now I can continue to work on projects, while providing oversight to the code development, art progression, and story. We've been getting into the habit of holding morning meetings and having short huddles throughout the day and the technical elements are seeing daily progress.

Until next week when I am sure I will have another recent lesson that I completely did not see coming, have a great week and keep working towards your goals, they will come with persistence and a little self-reflection every now and then.

-John-Michael Davis

Tags: 

• featured

Hello Ladies and Gentlemen,

In the dew soaked, cool, early hours of the 19th day of September, in the year of our Lord nineteen hundred eighty-eight, cries rang through the halls of Holy Family Memorial Hospital in Manitowoc, Wisconsin.  Those cries were together a song, a sweet symphony, composed by Nathan Lutterman.  The days after were filled with trials and strife, but also happiness, love, and excitement. 

Soon, Nathan was walking, talking, laughing, and playing as a child does, but something in particular caught his attention.  It was an old computer, a Kaypro II, and with it, a single 5.25” floppy disk.   On that disk contained the beginnings of an interest that captured not only the mind and imagination of Nathan, but of millions of people around the world.  Pac-Man, Asteroids, and other games sparked a long passion of his, leading to his enjoyment of Sonic the Hedgehog, Shining Force, Act Raiser, Command & Conquer ’95, Worms, StarCraft, and so on.  Love of video games led Nathan into a love of computers in general and an interest in programming.

That love fueled him through high school and into the land of Green Bay, Wisconsin to attend the University of Wisconsin – Green Bay campus for Computer Science, and although there have been many exciting adventures since, his current and most exciting is that of his travel to Portland, Oregon and his employment with Tiger Sheep, LLC as a software developer.  He hopes to continue his education upon earning residency in Oregon and hopes to become a world-class developer.

As you might have seen from previous blog posts, and hopefully just read above, I’m now a software developer for Tiger Sheep!  I’m ridiculously excited, and jumped head first into development for Deceit, and hope to have a long and wonderful relationship with both John-Michael, A.K.A. Boss, and Steve, A.K.A. Coach.  Portland is a whole new world for me, a dazzling place I never knew.  Way up here, it’s crystal clear, that now I’m in a whole new world, with you.

As someone from Manitowoc, Wisconsin, I love beer, cheese, bratwurst, beef, and cranes. I’m going to do my best to contribute creatively and industriously to the company, and want to make fun, exciting games to share with others.

It’s good to be here, and I’m sure you’ll be hearing more from me soon!

Nathan

Tags: 

• featured