Nathan discusses problem solving through the lens of software development.

Here are some useful bookmarks collected over the years by one of our lead developers.

Fitness can be fun! And it's necessary when you work a sedentary full-time job.

What's a day in the life of a product support specialist at Tiger Sheep like?

We wanted to see if there was a way to create native iOS apps using JavaScript, and compared Swift, PhoneGap, and React Native to do so.

Addama tells the story of the particular circumstances that led to his career in programming.

The popular mobile game Pokemon Go suffered from an extreme lack of communication upon release and for several weeks after. Here's an evaluation of the situation from a developer's point of view.

In this blog, we explore the negatives of offshoring work, particularly as it relates to developers and project managers.

Addama turns what you may or may not remember from your boring stats class into an interesting discussion on randomness in game programming, with real-world examples.

Imposter syndrome is a very real phenomenon and strikes many people first entering their field of work.

We here at Tiger Sheep get stupidly excited about Steam sales and so I thought, what with the upcoming Summer Sale (crossing our fingers for this Thursday!), I'd take a look at one of the internet's favorite topics: DRM. Yay! I'm pretty pumped, dunno about you.
 
Why do most PC users love Steam so much? The proprietary software uses DRM to track the usage of each purchased game, and as we all know, DRM is baaaaaad. Right? In some cases, maybe, but overall, most people use Steam without thinking of the behind-the-scenes DRM implementation.

The problem, of course, is if Steam somehow fails as a business. Not likely, if they keep doing those fantastic sales, but let’s consider the very low possibility of Steam shutting down. More likely, there’d be some way Steam would allow you to download your purchased games outside of the client. That is, if they’re feeling nice, and if it works out with the game publishers themselves. Maybe they would sell the business to someone else. A lot of game content might be lost, and a bunch of other games may not work at all, but if you’re one of those people with a huge game library, you’d at least be able to recoup some of your investment. A digital game library can be problematic, but I think we’d all agree that it’s more convenient than PC gaming used to be in the past.

The difference lies between inconvenient DRM and convenient DRM. Steam is convenient. Most players would argue this. And with the introduction of Steam Family Sharing, it’s possible for several people to share one copy of a game (although only when everybody except one person is offline. So maybe that’s not super convenient). Steam takes care of everything for you. Unless you’re entering a code from Amazon or a game bundle in, all you have to do is install the game and that’s it, start playing—with the exception of a few games which have third-party software or DRM.

However, if you do not want to deal with DRM but still want a digital game library, Good Old Games is a pretty neat business. All the games they sell are DRM-free—every. Single. One. Dang! That includes not only old games, but many new games as well, although the amount of new games is arguably smaller than Steam’s offerings. However, if you’re someone who waits for a while after the initial release, this may not be an issue.

It’s arguable that DRM is not necessary. It keeps the honest people honest, but doesn’t do jack for preventing piracy. This is a debate that’s been raging around the internet for years, and I’m not going to get into it here. But as we’ve established, there are definitely levels of DRM-badness, ranging from GoG-esque business policies and direct-from-small-publisher sales to EA’s controversial issues. Luckily, the games market is pretty competitive and there are options for pretty much anybody, no matter their feelings on DRM. Whether you’re all about Steam’s convenience or really into buying directly from the publisher, do what feels best.

Category: 

• Blogs

Dear readers: we’re back!
 
We feel terrible about the huge lack of updates lately. Business is tough, making money is tough. You know how it is. However, we’re gearing up to get back on track now, posting at least one blog a week, if not more, and putting more time into making games.
 
By the way, I should introduce myself. My name is Courtney and I am working for Tiger Sheep as a writer and social media person. I’m a pretty big nerd, although I think my gaming interests mostly lie between casual (such a derogatory word for such fun games!) and hardcore. I got a late start on the whole gaming thing, despite my mother’s Zelda obsession, so most of my favorite games from my childhood are browser-based flash games and PS2-era JRPGs. I’m looking at you, Dark Cloud. Presently, my interests are focused on PC gaming and catching up on all the fantastic things I missed out on in the past.
 
My other main interests are books and the book publishing industry. Right now I’m reading some really bad post-apocalyptic fiction and a moderately bad fantasy novel by a Patrick-Rothfuss-wanna-be, but sometimes I read good books too. Sometimes. I’m hoping to figure out how to sneakily work a discussion about the publishing industry into these blogs I’ll be writing, so keep an eye out.
 
Thanks for reading, and I’m looking forward to keeping you all updated on Tiger Sheep, 10,000 Hours, and other gaming-related topics in the future.

Category: 

• Blogs

One year ago, 10,000 hours was successfully funded. But we're only at around 500 hours, instead of the estimated 2000. What happened? We hope this video will explain.

One year ago, 10,000 hours was successfully funded. But we're only at around 500 hours, instead of the estimated 2000. What happened? We hope this video will explain.

Hello!
 
It’s been a little bit since my last blog post, and a few things have been going on. Tiger Sheep went to PAX Dev and PAX Prime in Seattle! It was an incredibly fun time. Unfortunately I can’t really blog about the things that were discussed at PAX Dev, but I can tell you that it was an awesome learning experience, discussing the process of making games and overcoming challenges with other developers, game designers, sales people and all kinds of other people. It was a great time, and I wholly recommend it to anyone who could possibly make it in future years.
 
I met some really great people at PAX, like Adam and Adrian from Little Reaper Games and Clifton, the creator of Clobbr. You should check their games out. I attended the panel for Keiji Inafune (creator of Megaman) at PAX Prime and got a Mighty No. 9 shirt signed by the man himself. I played Cards Against Humanity, Kings of Tokyo, consumed a great amount of alcohol, ate lots of Thai food, and generally learned and had fun.
As a member of an indie dev team, one of the areas that I liked to spend time was around the other indie game booths. I think I might have been a tad too shy, because I didn’t talk to the other developers as much as I’d like to have. I didn’t want to bother them too much because they’re already getting inundated with people, though it was fun to see what other technologies people were using. Lots and lots of indie developers seem to use Unity.  I knew that it was already an extremely popular game engine, but really, a crazy amount of people utilize it. It’s understandable because everything is already in place for you. You don’t need to have learned everything about Direct3D and OpenGL, input devices, sound devices, and network programming to create a well put-together game.
 
When we get to the point where we need to make some serious decisions regarding the engine for Deceit 2 and 3, we’ll probably take a look at Unity, or possibly Torque 2D as the games remain 2D pixel art side scrollers (which is most likely :D) As far as game development goes on the programming side, it’s been on a little hiatus for the past couple of weeks while we finish some work on some business integration and applications. I would say there’s a safe one or two weeks left, and then it’s back to hitting the ground running with Deceit.

Hello!
It’s been a little bit since my last blog post, and a few things have been going on. Tiger Sheep went to PAX Dev and PAX Prime in Seattle! It was an incredibly fun time. Unfortunately I can’t really blog about the things that were discussed at PAX Dev, but I can tell you that it was an awesome learning experience, discussing the process of making games and overcoming challenges with other developers, game designers, salespeople and all kinds of other people. It was a great time, and I wholly recommend it to anyone who could possibly make it in future years.
I met some really great people at PAX, like Adam and Adrian from Little Reaper Games and Clifton, the creator of Clobbr. You should check their games out. I attended the panel for Keiji Inafune (creator of Megaman) at PAX Prime and got a Mighty No. 9 shirt signed by the man himself. I play Cards Against Humanity, Kings of Tokyo, consumed a great amount of alcohol, ate lots of Thai food, and generally learned and had fun.
As a member of an indie dev. team, one of the areas that I liked to spend time was around the other indie game booths. I think I might have been a tad too shy, because I didn’t talk to the other developers as much as I’d like to have. I didn’t want to bother them too much because they’re already getting inundated with people, though it was fun to see what other technologies people were using. Lots and lots of indie developers seem to use Unity.  I knew that it was already an extremely popular game engine, but really, a crazy amount of people utilize it. It’s understandable because everything is already in place for you. You don’t need to have learned everything about Direct3D and OpenGL, input devices, sound devices, and network programming to create a well-put-together game.
When we get to the point where we need to make some serious decisions regarding the engine for Deceit 2 and 3, we’ll probably take a look at Unity, or possibly Torque 2D as the games remain 2D pixel-art side scrollers (which is most likely :D) As far as game development goes on the programming side, it’s been on a little hiatus for the past couple of weeks while we finish some work on some business integration and applications. I would say there’s a safe one or two weeks yet, and then it’s back to hitting the ground running with Deceit.

Well, these last few weeks have been pretty eventful for myself, but unfortunately not as much for the game as I’d have liked it to have been.  I think I mentioned in my last blog post that the GUI for the game was nearly complete, and if I didn’t, the GUI is nearly complete. (And by nearly, I mean not at all.  :D)
 
We ended up deciding to separate the frame of the window from the background itself in the drawing process. That way we could mix and match frames and backgrounds without having to create entirely new images! I taught myself one or two things that I probably could have just looked up, but oh well. I decided to handle the drawing of buttons by letting them handle their own drawing, but based on a parent element, like the window itself. The top left corner of a window is the origin, and the coordinates that you hand any window element that goes inside of a window are based on that origin.
 
And since Impact handles the drawing of images from a sprite sheet by cell numbers going from left to right, top to bottom, instead of row x column, I had to figure out how to get the cell number of each cell that I wanted to paint on the canvas programmatically.  What it basically came down to is multiplying the number of columns times the number of rows, and then adding the column number of the cell you want.  So, if you have a 2D array, and it’s C columns across, and the cell you want is at row r and column c, then you’d get the number of the cell (indexed at 0) by C * r + c.  So if I had an array that was 4x4, and I wanted to get the top left corner [which is (0,0)], I’d use 4 * 0 + 0 = 0.  The top right corner, which is (0,4), would be 4 * 0 + 3 = 3. Remember, it’s 3 because arrays are indexed at 0. Last example, if I wanted to get the number of the cell at (2, 3), it would be 4 * 3 + 2 = 14. I know it’s nothing fancy and I figured it out in about five minutes, but, you know.  But, it’s still nice to know.  :)
 
Handling the drawing in terms of a 2D array helped me iterate through the drawing of the window based on the width and height that you give it. I used a nested loop, the first loop iterating through the height, and the second iterating through the width. The loops increment themselves based on the cell size that you passed to the “GUI Master” (the cells are always squares, for simplicity’s sake), and from the index in the loop, it determines which cell it’s currently drawing. 
 
I should talk about the templates a little. The templates themselves don’t have to be squares, but the template for the border must be an even number of cells across and down. The background template can be whatever you want, just as long as you’re not sticking half of a cell in it. The border template is a little different because it needs to have a "filler" cell to draw when the window is larger than the template. Those "filler" cells are the inside corners of the template. It’s assumed that the creator of the window isn’t going to want it to be smaller than the template, so it won’t be a problem.  If the creator does want the window to be smaller than the template, then there are other problems.
 
So the loops iterate along going cell by cell, and they draw from left to right, top to bottom. They’ll start with the template, and basically draw it up to the halfway point, then draw the filler cell until they’re the-rest-of-the-template’s-cells away, and then continue drawing the template. So if the template is 4 cells wide, but the window is 10 cells wide, it’ll draw 2 cells, then the filler cell 6 times, and then the last two cells. Then for the background it just basically grabs the cell size of the border, multiplies it by 2, subtracts it from the height and width, and then draws the background cells based on that, tiling the background image. Boom! There’s a window when all is said and done! I stuck some buttons on the window, wrote some code to check whether the buttons were being clicked, and then the game loads a level. Here’s a screenshot: (insert levelselect.png)
 
That’s pretty much it! I have to work on some other things along with the game at the moment, but the next couple of things I want to tackle for the game are animated background tiles (which is already implemented in Impact), platforms, ladders, and checking enemy logic. After I get those things done, we can make a decent first level that might be fun! With a spider! Maybe two!

Well, these last few weeks have been pretty eventful for myself, but unfortunately not as much for the game as I’d have liked it to have been.  I think I mentioned in my last blog post that the GUI for the game was nearly complete, and if I didn’t, the GUI is nearly complete.  (And by nearly, I mean not at all.  :D)
 
We ended up deciding to separate the frame of the window from the background itself in the drawing process.  That way we could mix and match frames and backgrounds without having to create entirely new images!  I taught myself one or two things that I probably could have just looked up, but oh well.   I decided to handle the drawing of buttons by letting them handle their own drawing, but based on a parent element, like the window itself.  The top-left corner of a window is the origin, and the coordinates that you hand any window element that goes inside of a window are based on that origin.
 
And since Impact handles the drawing of images from a sprite sheet by cell numbers going from left to right, top to bottom, instead of row x column, I had to figure out how to get the cell number of each cell that I wanted to paint on the canvas programmatically.  What it basically came down to is multiplying the number of columns times the number of rows, and then adding the column number of the cell you want.  So, if you have a 2D array, and it’s C columns across, and the cell you want is at row r and column c, then you’d get the number of the cell (indexed at 0) by C * r + c.  So if I had an array that was 4x4, and I wanted to get the top-left corner corner [which is (0,0)], I’d use 4 * 0 + 0 = 0.  The top right corner, which is (0,4), would be 4 * 0 + 3 = 3.  Remember, it’s 3 because arrays are indexed at 0.  Last example, if I wanted to get the number of the cell at (2, 3), it would be 4 * 3 + 2 = 14.  I know it’s nothing fancy and I figured it out in about 5 minutes, but, you know.  But, it’s still nice to know.  :)
 
Handling the drawing in terms of a 2D array helped me iterate through the drawing of the window based on the width and height that you give it.  I used a nested loop, the first loop iterating through the height, and the second iterating through the width.  The loops increment themselves based on the cell size that you passed to the “GUI Master” (the cells are always squares, for simplicity’s sake), and from the index in the loop, it determines which cell it’s currently drawing. 
 
I should talk about the templates a little.  The templates themselves don’t have to be squares, but the template for the border must be an even number of cells across and down.  The background template can be whatever you want, just as long as you’re not sticking half of a cell in it.  The border template is a little different because it needs to have a ‘filler’ cell to draw when the window is larger than the template.  Those ‘filler’ cells are the inside corners of the template.  It’s assumed that the creator of the window isn’t going to want it to be smaller than the template, so it won’t be a problem.  If the creator does want the window to be smaller than the template, then there are other problems.  :)
 
So the loops iterate along going cell by cell, and they draw from left to right, top to bottom.  They’ll start with the template, and basically draw it up to the halfway point, then draw the filler cell until they’re the-rest-of-the-template’s-cells away, and then continue drawing the template.  So if the template is 4 cells wide, but the window is 10 cells wide, it’ll draw 2 cells, then the filler cell 6 times, and then the last two cells.  Then for the background it just basically grabs the cell size of the border, multiplies it by 2, subtracts it from the height and width, and then draws the background cells based on that, tiling the background image.  Boom!  There’s a window when all is said and done!  I stuck some buttons on the window, wrote some code to check whether the buttons were being clicked, and then the game loads a level.  Here’s a screenshot: (insert levelselect.png)
 
That’s pretty much it!  I have to work on some other things along with the game at the moment, but the next couple of things I want to tackle for the game are animated background tiles (which is already implemented in Impact), platforms, ladders, and checking enemy logic.  After I get those things done, we can make a decent first level that might be fun!  With a spider!  Maybe two!

Soooo, I was gone from the 24th, and then got back to work on the 5th. I moved! From Green Bay, WI to Portland (actually, pretty much Beaverton, but we’ll call it Portland. :D). Sorry that there was a little bit of a hiatus in there as far as heavy work goes, but it was a little full of stuff. I started my trip back to Green Bay on that Wednesday night, going from Portland, to San Francisco, to Chicago, to Green Bay! Then it was packing. We spent a solid two days packing, then I spent two days in my hometown, Manitowoc, WI visiting family and friends, then another two days of packing, then we finally left from the small town of Mattoon, WI on our wondrous 2000 mile (~3218 km) journey!
 
We saw Crazy Horse, drove past Mt. Rushmore, the Corn Palace in South Dakota, drove through the Badlands (and got out and climbed around a little), camped at the Missouri River, which was absolutely beautiful, by the way, and generally made a mess of things on our way to Portland. 
 
Once we finally got here on August 4th, we spent the majority of the day unpacking, and then I got back to work on Monday! I finally did a ton of work on the GUI and got it where we needed it for the simple sake of switching levels without changing code. Throughout the next week or two I’m gonna get some other stuff in, we’re gonna make a level, and by the end of the month (crossing our fingers) we’ll have a decent, playable, first demo level for you guys! Wooo!

Soooo, I was gone from the 24th, and then got back to work on the 5th.  I moved!  From Green Bay, WI to Portland (actually, pretty much Beaverton, but we’ll call it Portland.  :D).  Sorry that there was a little bit of a hiatus in there as far as heavy work goes, but it was a little full of stuff. I started my trip back to Green Bay on that Wednesday night, going from Portland, to San Francisco, to Chicago, to Green Bay!  Then it was packing.  We spent a solid 2 days packing, then I spent 2 days in my hometown, Manitowoc, WI visiting family and friends, then another 2 days of packing, then we finally left from the small town of Mattoon, WI on our wondrous 2000 mile (~3218 km) journey!
 
We saw Crazy Horse, drove past Mt. Rushmore, the Corn Palace in South Dakota, drove through the Badlands (and got out and climbed around a little), camped at the Missouri river, which was absolutely beautiful, by the way, and generally made a mess of things on our way to Portland. 
 
Once we finally got here on August 4th, we spent the majority of the day unpacking, and then I got back to work on Monday!  I finally did a ton of work on the GUI and got it where we needed it for the simple sake of switching levels without changing code.  Throughout the next week or two I’m gonna get some other stuff in, we’re gonna make a level, and by the end of the month (crossing our fingers) we’ll have a decent, playable, first demo level for you guys!  Wooo!