Ball on a Stick: 7/18/16 Update by Dan Andre

So the last couple of weeks have had their ups and downs, including a short metal health break for me and Danielle who seriously needed it. But now we've hit a very important milestone in the design process. Ball on a Stick is now officially in it's beta testing phase.

But before getting to this point, we've made some very important decisions regarding features.

First, we've upgraded to Unity 5. Originally this was to implement In App Purchases, because Unity's system was supposed to make this super easy. But other new Unity 5 features have made our lives infinitely easier for adding new features and fixing old ones.

Second, as hinted at, we've dropped In App Purchases. Once again Google rears it's ugly head on this one.

One of the biggest things this project has taught me is a new hatred for Google's convuluted systems. You need to make like 8 seperate accounts to do ANYTHING on any Google website, and it just becomes so ridiculous. We just got tired of it and decided to drop the feature instead.

This may hurt our bottom line, but we want to keep this project simple.

Another big focus before Beta was graphics. As previously noted, we implemented the randomly generated flower system. After that, we got focused on giving every ball in the game a special animation when the player sets a new record. This took a while, and required a lot of sound gathering.

This required the gathering of some public domain sounds off the internet. I take pride in the fact that I gathered as many of the sounds as I could myself, and wanted to do all of them myself. Unfortunately, since I don't have a sound studio, I can only do so much.

But regardless, I think everything came out well, and now we are officially testing the game once again.

During this process, we've already made some adjustments and improvements to the game.

We've had some reports that the game is difficult for beginners, and a few people have suggested the idea of being able to resize the ball to make the game easier. I thought about this for a while, and we came up with a solution to this.

The ball's size is now linked to a slider in the options menu that allows you to change the size of the ball if you are finding the game too difficult.

The trade off for this is that the smaller you make the ball, the less rewards you recieve.

Our plan now is to continue testing with these new improvements to see if we can make the game more user friendly. Last time we tested our focus was core gameplay mechanics. This time, we're focusing on the playability and balance of the game. We want to release ASAP, but we also want the game to be good.

So as always, stay tuned here for further updates as we get close to the game's release.

My Favorite Enemy in Platforming by Dan Andre

To know me, is to know 3 characters from my childhood; Captain Jean-Luc Picard, Batman, and Sonic the Hedgehog. These characters helped shape me into the man I am today.

Today though, we're just gonna focus on Sonic, and a particular enemy within the original Sonic the Hedgehog. The Crabmeat.

It seems like a simple, rather stupid enemy on the face of it. He's kinda slow, doesn't move very far, and he really telegraphs his attacks. And if you encountered him on flat land, he would pretty much be trival to deal with.

But this never happens. The way he is designed is for very spesific scenarios and setups


Whenever he appears, he is almost always placed on higher ground, usually on a ledge, blocked on the other side by either a rock or another ledge.

This is because of a very important aspect of his attack, as well as a very important point about platforming enemies in general.

His energy orb attack shoots like a mortar, in an arcing shot that falls down on you. Him being in this position makes it so you pretty much have to deal with him. You can't jump over him because of the blocker on the other side of him, and in the position he is in, a wrong jump will make you run either into him or one of his shots, making it so you need to time your jump well. The nice thing about this setup, is that he is always placed in such a way that if you don't jump and hit the ledge, you are usually safe from the arcing attacks and can wait for your opportunity to strike. But the best way to deal with him the way Sonic concievably would, to attack quickly, bounce off his head and over the obsticle, looking way past cool in the process.

The bigger point is that enemies in platforming aren't about cool attacks, they often don't attack at all and are actually pretty dumb. It's their placement which makes them threatening. The entire point of the enemies are to make a less predictable form of hazardous terrain to make traversing the level more fun

I love the Crabmeat because he is so simple, and yet creates so many interesting platforming scenarios, and was one of my first insights into game design as a kid, since Sonic 1 was the first game I ever played.

If you read my other post about Naughty Dog, you know I'm incredibly enthusiastic about platformers, certainly so back when I was a kid, but I still love them today because they are such a simple and fun form of game design. One that I think goes unappreciated by people who identify as "Hardcore Gamers".

Anyway, we were just discussing platformers on Unity Forums, and it inspired me to make this post.

Ball on a Stick: 6/27/16 Update by Dan Andre

So it's been another week of hard work on Ball on a Stick, and we've had to make some hard decisions in this process.

Most of the work we've done this week has been under the hood. Specifically, banging our heads on the hood as we try to implement Google Play Services. After 3 days, and even bringing in outside help from our good friend Laurence(You may remember him as the programming genius from Rat Boy) We still haven't been able to get it working. So we've decided to drop Google Play Services.  We have wasted more hours on it, and suffered through way more frustration than it's worth. The game works fine without it.

That all being said, the majority of the work left for the game is visual. Danielle has been working feverishly on artwork. In particular she has been drawing a lot of flowers. This is because we have added a nice new feature to the game. The scenery around the ball is now procedurally generated, so the flowers around the stick sprout randomly from an array of different flowers. It seems trival, but we think it really brightens up the frame and that random factor makes the frame always feel fresh.

Each time the scene changes.....

...So do the flowers.

Our focus now is adding explosions to all the balls. I think I noted this recently, but the balls now explode when the player sets a new record. Or at least, they are supposed to. We are still making particle effects for each different type of explosion based on the type of ball. That will be our focus as we work today. Finding matching sound effects for these explosions is another challenge, as one obviously can't just blow up their backyard and record it. We are finding work arounds through royalty free sounds and such.

The other big feature we have left is In-app purchases, which may require an engine upgrade. But we'll be handling that last.

After that, we will be beta testing and beginning our proper marketing for the game, then we'll be releasing ASAP. Our hope was to have this game done WAY before now. We are ready to be working on bigger and better things. 

We'll update again once we have ourselves a working Launch Candidate and have a release date.


Ball on a Stick: 6/12/16 Update by Dan Andre

So after a couple of weeks or reletive hardship on the code front, this week has been very productive.

Yesterday, after a bit of minor gear grinding, we finally fully implemented the currency system to the game, and me and Danielle both agree that the game feels much better with it.

And unlike previous updates, this time we have screenshots!

The amount of Gold Orbs you have is displayed at all times during gameplay now.

The amount of gold orbs possessed by the player is now displayed on the gameplay screen, as well as in the options...

You can also see here that we now have a button on the options screen for buying new balls with your Gold Orbs. Clicking this button will unlock a random ball from one of the 40 locked balls in the default game (There will be 50 total balls in the first release of the game). Each unlock will cost 100 Gold Orbs.

A new ball is unlocked!

You can also see a Buy Ball Packs button, that will be where the player can go to unlock paid ball packs. But we don't have in-app purchases working just yet. But as designed now, the player will never need to pay for any balls in the game, all of them will be accessable with Gold Orbs. All of the paid packs will be subsets of the balls in the main game, if the player wants a spesific ball and doesn't want to leave getting that ball to chance.

There are two ways to earn Gold Orbs. The first is through gameplay.

The new Game Over Screen

You will earn Gold Orbs based on the how well you do in the game. The longer the player can keep the ball balanced, the more Gold Orbs you will earn. You will also earn a bonus if you set a new personal record.

The other method of getting Gold Orbs is watching ads. You'll recieve a boost of 20 Orbs each time you watch an ad, and more importantly, you will be helping pay the bills of 2 broke game designers.

We ended up going with Unity Ads over Google Admob, because Google Admob was senselessly complicated to set up in terms of the amount of accounts and other hoops we needed to jump though in order to get it to work, while Unity Ads took less than an hour to set up and works great. It seems ironic to me that Google got rich off of it's very simple website, and yet every other website it has ever put it's hands on has become bloated and needlessly overcomplicated. I mean come on! Why do you need 3 accounts to do practically anything with a Google website, like Youtube or Admob? Ridiculous. But this could be a post for a different time.

You'll also notice the sign in button on the game over screen, that is for Google Play Game Services, which we are still trying to figure out for our Leaderboards, as well as a few other bugs that seem to be happening with Google Play Game Services Integration that seem to once again go back to the problem of Google making things more complicated than they need to be.

We are coming very close to having our Gold Candidate ready for testing, so it won't be too much longer until release! 

Check back here for more updates soon

June Update by Dan Andre

So I tried to post this a few days ago, but computer problems conspired against me

I just wanted to update the progress of my different projects here, more than anything just to organize my own thoughts.

The big project that has been taking center stage for the last month or so has been Ball on a Stick. We are within our anticipated launch window, and we are now just making some of the most important final touches on the project with the hope of having a Gold launch candidate ready very soon.  As noted on the Unity Forums, we had a minor hangup earlier this week involving the integration of the Google Play Game Services asset pack, which ended up making the project completely unbuildable. With the help of programmer extrodinaire and old Rat Boy friend Laurence, we were able to get the package integrated, and now the services should work (though, at the time of writing, basically none of the stuff from the package that we wanted to the way we want it to in game. But thats more on us than it is on the package I suspect)

We hope in the next week to get Google Admob online, which will require importing another Google Asset pack (hopefully with a little less pain than the last asset pack), as well as polishing up some existing features such as some special new graphics for when the player sets a new record, and a revamp of our currency system, which will now allow the player to unlock new balls by buying them with in-game currency.

But this is not the only project I am currently working on.

My currently untitled game for the visually impaired has been quiet for the last few months as Ball on a Stick jumped forward into the spotlight, but I am definitely not done with that game. The main reason I wanted to take some time with Ball on a Stick this year was to help Danielle learn the ropes of Unity a bit. This means now she can help me a bit more with the blind game.

The other reason we took up that project was because during the winter I couldn't record the sounds I need to finish the blind game. I need a few more sound effects, and since I don't have access to a Foley studio, I have to make due with what I have, and that requires the weather to cooperate with me, which in a Pennsylvania winter is not something it ever wants to do. I can only really record when it's warm out then, and it took until about a week ago for winter to finally end.

So now, I can get back to where I was with sound recording. Of course, now I have more sounds to record than those just for this project. I now have those of course for Ball on a Stick, and a new collaboration

One of my other friends and The Rat Boy projects AI specialist, Joe Rines, has asked for my help for sound recording for his new Beat 'em up title that he's working on, and I happily obliged. I will be adding some sounds he wants to my recording schedule with the hope of letting him have the best sounding Beat-em up we've seen since Streets of Rage.

So with all that being said, I need to go out and try to record some sounds now. We'll see how that goes. I'll keep the blog posted with the latest updates on all of these projects. Expect to hear more about Ball on a Stick soon!

Ball on a Stick: 5/23/16 Progress by Dan Andre

So work has been ramping up quite a bit on Ball on a Stick over the last week or two. After some extensive testing, now we are revamping some elements of the game for a new monitization strategy.

Originally, we were just going to make Ball on a Stick a paid app, but now we intend to move it to a free-mium model. Now we are going to make some of the balls in the game unlockable through one of two means.

Either you can simply buy them through in-app purchase, or watch ads occationally during gameplay to unlock a random pack. This means that hypothetically, a player can play the entire game and unlock every ball without ever having to pay for anything.

This is something that I felt was important, because I feel that so many mobile apps use what I would consider to be somewhat slimey means to make money through skinnerbox gameplay mechanics that just seem so obviously designed exclusively to reward the developer rather than the player.

I am not against developers making money, me and Danielle need to pay our bills and hopefully build our company so we can make better, more ambitious games, but some of the techniques I've seen used make me uncomfortable, so I feel the way our system is designed is a fair compromise so that we can make money without putting important features behind a paywall. I hate pay-to-win gameplay mechanics and obvious money making skinnerboxes, those just equate to intentionally bad game design with perverse insentive for the developers, and offers nothing to the player in exchange.

If someone wants to play our game for free, it is truely free. Everything in the game can be unlocked without any money changing hands. That being said, if a player does want a spesific ball pack and don't want to wait to get it, and have the money they want to spend to get it, we give them that option as well. It presents the best of both worlds I feel for everyone.

Beyond this big transition, we have also taken a lot of time to balance the gameplay, and we feel now that the game is much easier to control and play effectively. We have tested with people from varying demographics and skill levels, and I feel now that we have reached something of a sweet spot in terms of controlability vs challenge.

In addition, as a result of our overhaul of the way balls are represented in the game, this has allowed us much greater levels of customization in terms of different effects we can apply to each ball.  This means each ball can now have it's own sounds associated with it, as well as new visual effects. These will be implemented soon.

We've also been working on livening up the actual gameplay space. Danielle is working on making some animated scenery assets that should allow for a much more lively scene around the ball and stick.

We hope to have the app out sometime next month. Unfortunately we have yet to get a functioning system for getting good pictures and video of gameplay to show you. As soon as we do, they will definitely add them to the updates.

The Rat Boy: The first Post Mortem by Dan Andre

It was exactly one year ago today that our team released The Rat Boy into "public alpha" (a rather optimistic way of putting it) for our graduation project for my game design degree.

I say it was optimistic because the game was far from finished. It was more of a prototype to be honest. I worked on it for another month or two after I graduated, but one night I came to a realization. The assets we made for the game were made almost entirely in the student version of Maya, and as a result, none of them could be used commertially, so no matter what I did, I couldn't sell the game in it's current state, and I would have to inevitably rebuild the entire game with new models before I could sell it. So at that point I put the game into what I call an " extended hiatus" and moved onto my current projects.

So what went well on this project? Despite what the final product looks like, I'd say many things.

First off, I think everyone in the class got lucky to be matched up together.  It started as a class of 4 people, then 5, then 3 (technically). As anyone who has ever gone to Montgomery County Community College knows, especially if you attended their game design program, the herd thins out quickly. When a class starts, especially one of the basic classes like the first game design class, you start with maybe 25-30 people. By the end, you are usually left with about half of that number statistically, but usually less in the game classes.

As you move further on in the program, the number of students gets smaller and smaller. By the time you get to the 4th and 5th game classes, which are basically the same class because it's a 2 part capstone course, only the best and most dedicated have made it.

When Game 4 started, it had 4 students including myself. About a week into the course, another joined, bringing the number to 5

Luckily for us, the class couldn't have possibly been better rounded out for the task of making a game. We had a designer, a few programmers, and an artist. we had basically everything we needed to make a good game. And if you've seen final projects from previous years like I have, you know that not every project is so lucky. Either the game has a bunch of programmers and someone on the team who can design, but the art is a mess with glitched out textures, or you have a good artist and some good programmers, but theres no actual gameplay because no one has any design sense.

If your team doesn't have at least one of everything like we had, you end up with some critical deficiency.

At the beginning of the class, we all had to come up with a proposal for what kind of game the team would make. I had an idea for a game I did previously in one of the other game classes, except adapting it to be bigger. I've been toying with and tweaking this idea for years, and just put it out there in a reletively disasterous presentation where my powerpoint completely fell apart. Despite that, people thought the idea was cool, with a core mechanic of using seemingly random objects in the enviornment as tools and weapons.

Laurence presented a MOBA, which....was pretty unrealistic given our resources. But the thing you need to know about Laurence is he is more than likely the best programmer I've ever met. He just has such a natural aptitude towards this sort of thing, I always say he has a mind of metal and wheels. Watching him program is what it must have been like to watch Mozart conduct music or watching Leonardo Di Vinci paint. So if he had the right direction, I'm sure he could probably figure out a MOBA by himself. I feel like one day he will be the second coming of Satori Iwata.

The only thing that matches his programming talent is possibly his tenacity and dedication. He actually wasn't enroled for the second semester of the capstone course, because by some strange miracle at the enrolement office, despite being a computer science major, he somehow made it into the game design capstone course. A miracle I am grateful for, as this project would have been completely boned on multiple fronts without him. But he showed up to our class anyway. He scheduled the classes he was supposed to take around our class, just so he could join us and help with the project. That is the kind of dedication I will always respect. I still talk to Laurence to this day.

Mitch presented an idea for something of a mutant sidescroller. The character would mutate between human and animal forms. This kinda speaks to his own set of skills. Mitch was a pure artist. He was in his element when he was alone with a pencil and his notebook of sketches. He loved werewolves and shapeshifters and things like this. He had a notebook full of drawings of all kinds of different things, but above all else, animals and mutants. And I loved his art, it was truely great, he had such a good eye for detail when he was drawing.

His one weakness however was anything more complicated than a pencil and paper. If Laurence has the mind of metal and wheels, Mitch was pretty much a wood elf, completely the opposite. If you sat him in front of a computer, it would just stop working. Both of his computers were broken at one point during the project. He just didn't have a mind for code. Which was entirely OK for what we were doing, since we needed him more as an artist than we did as a programmer, since our programming was pretty well covered. It was my own mistake that put him in a difficult position towards the end of the semester. The last time I saw Mitch was on the last day of class. He couldn't even make it to the final release of the game.

Joseph's presentation was.......interesting. He had his recorded...and it was rather interesting to say the least... He wanted to do a game about a dark maze. He also wanted to do one about an old involved drawing rather....graphic stick figures...It was rather eye opening

Joe was the one who joined the class late. But he worked more than hard enough to make up for it. He was also a programmer, who we kinda assigned to more specialized programming tasks before we finally decided to have him be our AI specialist. His work ethic was something else. While he was taking the game classes, he also took something like 16 credits worth of classes, and also had a job, and was also in the Marines. I heard him once described as always moving at about a hundred miles an hour. It was a pretty accurate analogy, because nothing could stop this guy. I still hear from Joe from time to time, he's trying to start his own game company. I hope that one day he can be the Insomniac Games to my Naughty Dog.

Dustin was actually only in the first class due to the fact that he essencially took the two classes out of order due to complications in his scheduling. He got accepted to DigiPen part way through the semester and is probably still there now, which is pretty interesting.

After everyone gave their presentations, we had to decide what we wanted to make. This was the point where I was able to work some teamwork magic. I looked at what everyone wanted, and found a way to completely rework my idea to include what everyone else wanted. Laurence wanted a programming challenge, Mitch wanted to make mutants,  and Joe wanted a dark setting, and I wanted my game mechanic with using common junk to solve puzzles.  We gradually made compromises until we ended up with the concept that we called Mutant Brothers.

Originally, we wanted to build a whole city, and have both Rat Boy and his big brother to be playable characters. Rat Boy would have had his stealth gameplay and puzzle solving, while Big Brother would have been more combat oriented gameplay. Something along the lines of the early Resident Evils where you had two different characters with different sets of skills working through the same areas except slightly differently.

But even early on we realized that we really needed to tone down the scope of the game, and had to decide which story we would go with, and toned it back the size of the world until it was just limited to a single warehouse. We ended up going with Rat Boy as the main character because we believed that out of the two, Rat Boy represented a far more interesting challenge for the player. I've always been more fond of the stealth genre anyway.

The first semester was dedicated to a bunch of smaller prototypes that demonstrated some of the smaller mechanics in a more isolated way. This was where I effectively taught myself the basics of Unity, building the first prototype from cubes. It included basic code for movement, the camera system, and enemy patrols. We also had prototypes for an early iteration of the inventory system, which Laurence was in charge of. It was more like the inventory system from Diablo or Resident Evil 4 than what we ended up with in the end. We then made a second prototype that actually included a lot of features that we ended up cutting from the final version, such as a flashlight, physics based barrels, and a pretty buggy ladder (which I really wish we could have figured out for the final version)

The second semester was where our work truely began. We pretty much scrapped all the old prototypes and started again, this time using custom assets rather than Unity primitives.

This is where we ran into our first real problem. When we imported all of our 3D assets, we didn't know that for whatever reason, Unity imports 3D models at .01 scale. And by the time we discovered the problem, it was already too late and half the levels were already built. This caused countless strange errors with the physics engine, raycasts, and moving things around in general, because everything was so small. The floating point rounding errors would throw off just about everything, and cause things to fall through terrain, or get stuck in it. It really was the biggest problem that plagued the project.

By this point, we had all really fallen into our roles. I was lead designer, pretty much keeping the entire project on track as best as I could. But I had taken on way more jobs than that in the process. I was pretty much responsible for all of the enviornmental models, all of the level designs, all of the programming on the character controller, all of the 2D UI assets, and all of the sound design for the game. This might have been a mistake on my part, which I'll get to.

Laurence meanwhile was the lead programmer. For most of the project his main task was the inventory system, which included a lot of data management tasks which were WAY above my skill level in programming at the time. He also handled all of the saving features, such as preserving room state and the item economy. In retrospect, these were all massive challenges that were probably a bit huge for a game we were trying to build as a college project. But Laurence took care of it like a boss.

I put Mitch in the position of technical artist. He had already drawn up all the characters, which all looked really awesome. I then gave him the duty of modeling out those characters and rigging them. This was probably another big mistake I made. We spent a lot of time waiting on those models, because Mitch probably wasn't prepared to handle this kind of thing. He was great at drawing, and he was a decent modeler, but he had trouble beyond that. This was something I should have been aware of and adapted to much more quickly than I did. When I saw how much trouble he had exporting a single model, I should have moved him to making enviornmental assets and taken over the characters.

Joe was in charge of the enemy AI. The goal was to produce a system that worked similar to the MGS paradigm, where the enemies worked on a state machine that determined their state based on their awareness of the player. This was another fault with my design. When Hideo Kojima made MGS5, he had an 80 million dollar budget. While I did spend money on this project despite knowing it would never make money, my budget was no where near 80 million, but instead like less than $100. And while Kojima had probably over 100 people working on his game, mine had 4. My expectation that I could do nuanced stealth with these restrictions was possibly unrealistic. Alternatively, perhaps when Joe was having trouble, I should have perhaps had Laurence shift from the inventory system to the AI and them work together sooner than I eventually did.

I think all of the shortcomings I see in this project may have come down to a problem I had at the time that truthfully I occationally still struggle with. As team leader, I always seem to want to take on more tasks than I can handle at once, because I just wanna do all the things, but in exchange it hinders my ability to focus on the management part of leading the team.

Part of this comes from my philosophy of trying my best to not ask anything of anyone on my team that I couldn't do myself. Often, people who I would look up to as leaders lead by example, and with the ambitious goals I like to set on projects, I want my team to feel confident that I am dedicated to the project, and they know I'm not asking them to do something unreasonable that I couldn't do myself. 

But at the same time, this ends up causing me to take on more and more parts of the project, until, to put it into computer terms, my processor is pegged and my ram is full and I just can't fuction efficently anymore.

This has happened to me before on previous projects like this, and this time I was aware of it, so I tried to put a little more trust into my team, since I knew I was in good hands. Unfortunately, this idea sometimes left my sight and I would occationally get wrapped up in more and more responsibilities.

There was a point in this process where I was approaching critical mass and my ability to stay focused was almost completely gone. Luckily Laurence came in clutch and helped take some of those responsibilities off of my shoulders and helped me re-delegate tasks across the team at a critical moment. That really helped us get out of a particular dulldrum we were in.

By the last few weeks of the process, I had pretty much resigned to the fact that the grand vision would not be realized in it's entirety. Not this time anyway. So instead, I focused on building a few discreet challenges into the game as a sort of proof of concept. Each room presented different challenges that represented the different modes of play I wanted the game to have. The main hub room was going to be more dedicated to the stealth elements, which, right up until the last day of development, didn't work, we only really got it working, to at least a satisfactory level on the last day of development. The Northeast Passage was going to be dedicated to exploration challenges, such as using the crowbar to remove vent covers, platforming (something I worked hard to get working the way I wanted to, but could never really get exactly perfect), and a vent maze. The Southeast Passage was dedicated to a puzzle solving room, which was based off of a concept drawing that Mitch did early on that I wanted to make sure was included in the final "alpha".

One of the new stipulations that was added to our course, which was literally the first time it had ever been done in this college's game program, was that we needed to release the game onto an app store. It could be any app store, as long as it was published. It was a goal set for us by a professor who we really were privlidged to get a chance to work with, who during the one semester he taught at our college, he had to leave during because he got hired by Telltale Games to work on The Walking Dead game. This should give you an idea of how good he was. Well, we originally slated this game for release on the Windows Store, but on the last night, no one could really figure out the publishing process, because the only one of us who had Windows 8 on their machine was unavilable when we were gonna publish our official release build.

I emailed that professor that night, as just a cry for help into the void, expecting no response, and he showed us, which allowed us to publish pretty much however we wanted, which was really nice. That last 48 hour crunch was some of the craziest time in my life. I was pretty much awake during all of it, at any one time having at least one member of the team on Google Hangout. It didn't help that the day before the final class and the presentation my car had been vandalized and wasn't running, so I had to do everything remote, until a friend of mine literally just handed me his car keys and said "here, don't crash it." so I could drive to the final presentation of the game. I'm glad he trusted me despite the fact that I was very obviously suffering from intense sleep deprivation.

I'd say the final product came out well given my final goal once I realized the game was too big for a 6 month development cycle. The game is playable, and, as noted by those in attendance for our final presentation, "Unlike projects from previous years, theres, you know, actually stuff to do".

I'd call that a positive review. It wasn't the game I wanted it to be, but hey, there was stuff to do.

Regardless of what the final product turned out to be, the biggest take away I got was just the massive amount of stuff I learned about game design in such a short time. It was the best Crash Course through Unity 3d money could buy, thats for sure. And it was pretty much my first real foray into leading a team. I had done so previously, but not with the amount of success we all had with this group. As I said, I'm still in touch with most of these guys, and I suspect Rat Boy won't be the last game we make together.

So why did I call this the first Post Mortem? Because I'm still not done with this idea. I doubt it'll look anything like it does currently, but one day I will do this project the justice it deserves. This isn't the last you've heard about Rat Boy. Just the last you'll hear until I can afford a Maya licence and the ability to pay a much larger team. When that day comes, Rat Boy will be back.


Technology: A Meaningless Word by Dan Andre

So this will be the first post I do on here that isn't explicitly related to a particular game or games in general. And it's about something that as I get older drives me crazy.

Back in college, I did some scriptwriting courses, because A, they were more interesting than generic "creative writing", and B, I liked the professor who taught the course, because I had had him previously.

That professor was clearly a very intelegent man. He sorta reminded me of Toby Ziegler from The West Wing. He was slightly essentric and very few people actually understood him most of the time, and even I didn't even always understand. But I stuck around because I'd know that I would. I occationally even got into heated arguments with him, that ended in me hours later realizing that he was totally right and I was just being pigheaded and it would end up making my work significantly better.

Anyway, one day, someone was giving a script pitch in class one day, about some generic sci-fi whatever, and they used the word technology. He stopped them right away and told them to avoid using the word "technology". The student asked him why, and he responded "Because 'technology'  is a word that I consider meaningless. There are many words like this, and 'technology' is one I really hate."

At first, being someone getting a game design degree which is made of heavily of computer science and media production course, both of which heavily dependent on "technology", I objected to the idea that the word was meaningless.

But as I thought about it, I realized that, once again, he was totally right I tried to define the word in my own mind, and I could think of nothing that wasn't so vague that it was entirely meaningless. This was really driven home later as I would listen to people use the word on the news or in TV shows, movies, and even games. I'd realize that the word was basically just filler and served just to fill time more than anything else.

In the news in particular, it feels almost exclusively like a scare tactic anymore, which just annoys me to no end. When I read headlines like "Are Teenagers addicted to Technology!?" and know that these stories can just be filed under the"remember old people, be scared of everything" portion of the 5:00 news, it drives me crazy. Are young people addicted technology? Only in the same way young people were in the 50s when all these new fangled gadgets like automobiles and refridgerators and washing machines and big scary televisions were. Or the way the british were during the industrial revolution, or the way cave men where when they figured out how to make fire and clothes and how to put a sharp rock on the end of a stick to stab things with were.

All of these things are technology. The only difference is....well....nothing. Basically nothing. They are all technology. Just different and new and therefore scary, even though they make work easier and people more efficient.

What these people are actually afraid of is new things. Did the advent of the power drill make carpenters lazy? No, it made them more efficient. And this is the same with all of this "technology" that people are so afraid of. They see a thing, and throw a word at it. And now the word "Technology" has all this baggage, and has an entirely different meaning depending on who you say it to.  So therefore, it has so many meanings that it has looped all the way back around to being completely meaningless. It terrifies some people and excites others, but to me, it just like when you say a word so many times that it does even feel like a word anymore. Annoying.