From the beginning, I had actually planned for a simple concept level (yet expansive in scope, once I sat down and went through it all) that would push what I knew about the toolset, though keeping those lessons simple. Little did I know that a lot of those simple ideas were far far beyond what I would ever be able to figure out on my own. Yet, I plugged away at it endlessly until I hit points that I just could not figure out: “Why is the lighting shifting when I add this pointlight here, but not here?!”, “How come this wall is transparent from this side, but not the other?!”(Normals where a new thing to me), “Why is it giving me errors when I try to spawn a bot?!”, the list goes on.

It was around this point that I decided to scrap the whole initial plan entirely, I needed to do something I understood right out of the gate, while keeping the learning end of it as simple as possible. What turned out was the 0.1 version of the level you currently see in the YouTube video I’ve posted. To put it simply, just about everything that is in the current version was in the 0.1, with some simple changes such as no proper grass material, no “god rays”, ect.

Now, as I moved on with the level, trying to implement some changes to make things much more believable became quite the problem. I hadn’t learned how to properly plan development, and as such the stability of my level fell through the floor; whenever I tried to add a new terrain material, change some figures in the lighting or an other major change, everything would crash. After a few days of trying and trying again only to have the same issue come up, it became clear I’d have to start over again. As such, I noted the locations and set-up of every mesh and terrain and started over from scratch.

It was around this time that I came across the 3DBuzz tutorials, these things would quickly teach me concepts that I never would have figured out on my own, as well as some strong development fundamentals, such as ordering what elements should be focused on first, which led to my final version.

To wrap it up, the learning experience with this project was very similar to the RedKnight: design within your own knowledge, know when something may be out of reach or beyond your skill level. And if you want to go that extra distance, take advantage of the resources before you dive head-first into the unknown. Should you feel you are unsure of your own skills, do as I just mentioned and take advantage of the resources you can and see how your knowledge compares to what they have to offer. Having this mindset from the get-go will save you a lot of wasted time and frustration.

Summary

What I did right

• Start development with what I knew, to keep the scope in focus.
• Taking advantage of the resources available to me. I can’t stress enough how much those tutorials helped me.
• Restarting from scratch. Though I ended up having to restart one too many times, I was still able to get something out of it in a reasonable amount of time.

What I did wrong

• Not tapping into the previously mentioned resources soon enough. Look up this info as soon as it comes into question, it’ll save tonnes of time.
• Not enough pre-planning. Much of the final level design I came up with as I went and found where my limitations are as a junior developer. This may have worked here, but it sure as hell will not for any future projects.
• Distractions. Since this was my first proper project I was jumping all over the place, deciding suddenly that I wanted this material here, that mesh there, and it made a jumble out of m development cycle, slowing it down considerably.

Flash has always been a strong suite for me. Even when I first started getting into the program 5 years ago, Flash was as pick-up-and-go as it could get for me. As such, it’s no surprise that my first real planned project using Actionscript 3 would turn out a success. 

Fly Smasher is one of the projects that came from my experience over at EDAC's Interaction Design and Game Level Development. The assignment was to develop a simple story driven game that is played through only one player input and that can be developed as quickly as humanly possible. Right out of the gate I had a project document detailing out the  of the game as well as a paper prototype.

Let it be known, if you can create a paper prototype of your game prior to actual development, do it! It’s the most effective way to get your idea across visually to both other people in your team as well as possible targets of your demographic. Had it not been for the paper prototype, many of the final ideas that went into Fly Smasher wouldn’t have come to the light of day. On top of that, a prototype should only take a few minutes to and hour at the most.

Development was interesting to say the least. At the time, Actionscript 3 was still rather new to me, with only a small chunk of Red Knight being the only previous experience with the script. As such I used what I knew to come up with an Alpha version quickly, but it was the polish that took it’s time. As I attempted to move on from that version I quickly hit brick walls; I had never really used aspects like XML and Flash, nor had I used AS3 to code priority in a mouse click over other MovieClip collisions. Suffice to say, I eventually got all of that sorted and quickly jumped onto getting as much testing as possible in.

As the walls fell, and the testers’ grins grew more and more, it became apparent I was on to something. When looking for proper art assets, Albert jumped onto that faster then you can say: “You have two weeks!” He had been rather excited about the project since I first brought it up, and was the first to jump in as a tester whenever he could.

In the end this was the big success of my college career. The scope stayed intact, it remained fun and simple, the story-while basic- is enough to get players interested and the art style Albert came up with was brilliant.

Summary

What I did right

• Paper Prototype, paper prototype, paper prototype
• Get some testing in whenever possible. This was a huge step into keeping the game interesting and consistent.
• Building the fundamentals before assets became a factor. This allowed for both the concept to be proven, as well as the assets to be designed around the game, not the other way around.
• Simple concept was the right scope for an junior developer like myself.

What I did wrong

• Not enough research into XML and Flash. Relying on PHP to transfer data between the two wasn’t a very elegant solution.
• Took too long trying to bash down the “brick walls” instead of changing focus and coming back to those barriers.