But now onto the real purpose of this blog post. I was approached by Packt Publishing not long ago to review an UnrealScript book they had published. Quick disclaimer: I’m not being paid for this review or anything like that. This is just my honest opinion of the book.

The book is called “UnrealScript Game Programming Cookbook“. It’s important to note that this book doesn’t teach programming and syntax, but rather provides some practical applications of UnrealScript as well as explanations of the structure of things inside the engine – ie the relationship between Cameras, Controllers, and Pawns. I love this method of teaching, as you can learn the language and its constructs in a practical way that you can see results. Epic has provided some great documentation about the technical side of UnrealScript so more applied examples are always good.

The first couple of chapters don’t deal a lot in programming. They prepare the reader for some of the fundamental setup and prerequisite knowledge. Chapter 1 covers setup of a variety of IDEs. I’m glad to see is the suggestion to use Archetypes (covered in Chapter 2), as they’re a bit under-used by a lot of UnrealScript developers in favor of hard-coded data. Offloading changes to a system that doesn’t need to wait for compile and startup times is a great thing to do.

The topics that are covered throughout the book are Camera Systems, Pickups, AI & Navigation, Weapons, HUD, and a couple of miscellaneous recipes. I can’t help but feel a few of these re-tread well documented and sampled areas of UnrealScript already – for instance Camera system samples are already fairly well documented from both a practical and structural point of view on UDN.

The chapter on AI is by far the best and most valuable part of the book. While it probably doesn’t go into as much depth as it should, it’s as good of a starting point as I’ve seen for developing AI code and setting up navmeshes as appropriate. It covers the basics of pathfinding using both pathnodes and Navmeshes, which has been a headache for a lot of people I’ve known in the past. Unfortunately its also one of the areas that can go horribly wrong depending on your context, and very few of those issues are addressed in the book either.

The samples throughout the book are moderately well explained in a code sense and a structural sense. The samples look well constructed, but perhaps could have been more applicable to general development, or perhaps sequenced better to more gradually introduce people into the structure of the engine. Mutators aren’t covered at all, despite being a great introductory point for programmers starting with the engine. Gametypes could probably have been covered in more depth, as well as some more custom behaviour for Pawns and PlayerControllers. In my opinion, that sort of basic game structure are things that are more in demand and valuable for anyone looking to learn UDK.

I have two main criticisms of the book.
The first is simply the formatting and some of the way in which information is presented. There are many errors and typos throughout the book – I came across a variable declaration that looked like “var(Camera) constboolUseThirdPerson;”. While any experienced programmer will figure out exactly what this is meant to look like, it can still be confusing and just serves to confuse readers. Don’t get me wrong, this isn’t the first technical book to have typos and it won’t be the last, but most of those books have been (rightly) criticized for those issues.

Secondly, a lot of pretty important concepts are brushed over, or mentioned in passing and never referenced again (and no references are provided for further reading  Despite its intention being to provide “recipes” to be quickly followed to get a result, theory on how you go about some of these things is important as well. A couple of examples spring to mind here. The use of Sockets is mentioned on one page and a screenshot of a character with sockets is shown. However, there is no further explanation on what Sockets are for, or even a link to documentation on how to access the Socket Editor. The other one relates to sub-objects, which are used all over the engine (and several times in the book) but never explained, at least not that I could see. These are just two of a few examples where a fairly important concept is mentioned but never expanded upon at all.

I’m going to be honest here. I haven’t read any other UnrealScript books, and the times I’ve taught it I’ve written my own subject material. It’s hard to compare the quality of this book to others, because I simply haven’t read them. This book hits some good notes (the general approach, Cameras despite them being a well-trodden area, AI/Navigation) and misses the point in a few areas. The typos and formatting issues are a huge problem, even as far as incorrect characters being used for important concepts (explaining the log macro used ‘ rather than `)
One of the upsides is that the book is available in digital format, which is always a great thing for programmers and programming books. If I had to give it a rating, it would be a generous 6/10.

Despite this, people are already jumping to conclusions about the sort of games that players are looking for in Greenlight after the announcement of the first batch of 10 games Valve will be releasing on Steam. Amongst the inclusions were perennial favorites such as Black Mesa, No More Room In Hell and Project Zomboid – titles that have huge community followings as it is.

The question I’d like to pose is why people are making judgements on what players are looking for based on 16 days of the service being available. 16 days that has been, at best, a mess of a launch. What we have are 10 games with existing community followings and a system that doesn’t encourage exploration or discoverability on the part of players. Not only that, but suggesting that designers take something away from this first 16 days is irresponsible.

As it stands, Valve doesn’t release any details about player habits and title/genre popularity on Steam, nor do we know or understand the correlation between these players and the players who vote and visit Greenlight. We simply don’t know which markets Steam is appealing to right now (as we have no sales figures) and what market is actually visiting Greenlight. To attempt to infer details about a market based on the small fraction of the 50 million players who use Steam is a poor approach.

What we have is a young system that’s the first of its kind to be made available to players and a set of already very popular games to get voted as the first 10. Anyone who didn’t expect the first games to be big-name titles is kidding themselves. Lets give Greenlight a chance to mature and see what other games get Greenlit before jumping to conclusions.

As a bit of background, I’ve been teaching level design and game design theory, and applying them practically using primarily UDK. My first class was a VET class, which is where a group of students from high school (mostly aged 15-16) come in one half-day a week. This is only the second year that games has been taught at this TAFE so there were some fairly unknown factors going into this year, but by and large its been fairly successful. Successful enough that the institute asked if I was interested in teaching an UnrealScript subject in another course, which I gladly accepted.

I’m only a few weeks into teaching this subject, but so far its a whole new and different challenge – certainly much different to what I expected it to be. These students have prior programming experience through a semester of Java. This part has been fairly beneficial, as syntactically and conceptually, UnrealScript is most similar to Java in its design.
Unreal does alot of things somewhat unconventionally. Theres alot of basic configuration required just to get code to compile, or to get a mutator appearing inside of its UI. Editing ini files, localization files and setting up package structure is something that is preferable to avoid, but in this case its necessary. I could have run with teaching Java games programing, XNA, or something similar. But the goal for this class was to produce something with tangible, fun results throughout the semester, and Unreal makes that fairly easy to do.

I expected that teaching the structure of Unreal – directory layouts, relevant files to keep in mind, etc – would be one of the more difficult things. I was spot on there. But the primary and most unexpected challenge that I’m facing is the lack of what I call “structured logic” – thinking about how to create and structure a function, class, application.

TAFE is primarily a hands-on approach, rather than the lecture-lab/tutorial split that University has. At TAFE, the goal is to get students actively involved and working for the duration of the class, rather than talking at them for a few hours, and then setting them on a task for two hours. For programming, this presents a huge issue with the sheer amount of theory that needs to be taught. Luckily, alot of basic concepts were taught during their semester of Java, which has gotten me off the hook there. However, being able to break up a problem or task in order to decompose it into a set of variables, functions and logical steps has been quite the challenge.
I’m fairly disappointed in myself for not expecting this, and even for taking two classes to realize it. For the UnrealScript subject, I set out with some assumptions – which I’ve found to be wrong – and aimed to create a fun creative semester getting the students to create fun mutators and crazy weapons. That being said, I think new teachers generally set out to teach too much and underestimate the amount of work that can be involved in conveying what they might see as simple concepts. Understanding how people learn, and figuring out different ways to explain the same concept until everyone understands it IS teaching at its very core.

I still haven’t figured out a good way to teach structured logic yet, however I have a good idea on where to start. To me, one of the most invaluable techniques that any programmer – especially beginner programmers – can learn is the Pseudocode Programming Process, or the PPP. The PPP is a process whereby you structure your class/routine using purely English-like statements, and then write code around those comments. I first read about it in Code Complete and there are some discussions about it online, notably none other than Jeff Atwood’s Coding Horror post. While I agree with Jeff for the most part – I personally don’t use the process and prefer to think in code – I think it can be a very valuable part of a teachers toolbox when approaching problem solving and structure.

The second challenge that I’ve found is something that I’ve always taken for granted, and thats general IT skills. Within the first few weeks of my VET class, I instructed my students to mount and run DOOM through DOSBOX. To my horror (although once again, I should have expected it) most of the students had no idea about how to use a command line! Similarly, alot of habits that seasoned developers get into like use of shortcut keys, information identification and even typing speed present issues that must be overcome in the process of teaching.

In the end not only are you teaching programmming, or level design, or game design. You’re also teaching alot of “soft” IT related skills that are crucial to being productive in this specific field. This relates back to the earlier point of underestimating the amount of work involved in teaching. If your sole goal is to teach programming, or level design, then I’m sure that much more content could be crammed into a subject. But what use is teaching that if the students lack other skills that can enhance their overall productivity and ability to learn in the future?

Theres a common and somewhat disrespectful saying that “those who cannot do, teach”. As someone who feels fairly competent in what they do for a job, I see two main purposes in teaching.
Primarily, its to spread your experience and knowledge from the real world. Alot of teachers, especially at universities, come from purely academic backgrounds and often lack real world perspective and experience. Having set up a studio, putting processes and infrastructure in place and running into real world roadblocks gives you so much more insight into the practical challenges that graduates will face from day one on the job.
As a secondary goal, there is alot of self-improvement to be made while teaching. I’ve found that I’ve become far more proficient with UDK as the year has gone. Not only that, but plenty of students are very creative and will challenge your own creativity and approaches to problem solving.

Several years ago if you told me that I’d be teaching and enjoying doing it, I would have laughed. But I now see myself enjoying some of the challenges and benefits of being a teacher. I’ve also started teaching an introductory programming subject at university, where I’ve encountered many of the same challenges. This shows that the issues discussed in this post are probably not isolated to just a few classes. Instead, perhaps we need to look at harder requirements and understanding of technology before students take on programming.

The main piece of advice I was given before I started teaching was “teach how you would like to be taught”. I genuinely believe that one of the great advantages I had as a student was the relationship and interaction I had with my teachers, especially outside of class. One lecturer in particular at university was almost like a mentor for me. His door was always open for a chat. This was my goal – to not only be a teacher, but to be a mentor. To be someone who was accessible to all of his students. Not just in those 5 hours a week of class time, but all week. Building a great relationship with your students seems to be a key factor to both your own improvement as a teacher, and getting the best out of every student you teach.

The Last Line
We’ve only been here a short time. Even though we have no comfortable beds, no clean water and very little food, it feels strangely like home. To all of us. But they think we should move – a factory is too much of an obvious hiding place. The Combine have sought us out time and time again, even when we went Underground. But we’re tired. Battle-weary. And we have some injured. We just can’t leave them here at the mercy of those animals. God only knows what they would do to them – I could never bear to experience something like that. So I keep us here a little longer. But each day we survive is one day closer to the day we die.
And today might be that day.
-John Dalton

Its been nearly 5 years since we officially ceased development of NightFall. Our trials and tribulations are well-documented, and our demise came as a combination of internal team issues and over-ambition.

I’ve talked a bit on this blog and in other places about management and ensuring that your creative processes are rock solid in order to have a chance of success. Its fairly obvious that our processes for NightFall were less than stellar, to say the least. So I’ve taken a bit of time to put together some statistics of how much work was actually put into NightFall over a few years before we ended development. This is based on the assets that I currently have, and I’m sure many others have been lost over time.

• A full blown stats system (similar to the Episode 2 stats page) was implemented using a Flash charting library, complete with artwork, as part of our website
• Hundreds of pages of writing and planning for our maps, story and script
• Hundreds of lines of dialogue
• An original story piece which included plans for an RPG-esque dialog system that determined the direction of key story points later in the game
• Several revise and refined story pieces
• A storyboard and some renders for a trailer we never released
• About 4 different websites through our years
• A design and prototype for a full-blown “player insanity effects” system
• Around 800 sound effects
• Over 400 lines of recorded dialog
• Several posters
• Half a dozen wallpapers & NightFall themed avatars
• Dozens of concept images
• Written “diaries” that would be used for promotional purposes and loading screens
• Approx 1700 VTFs (textures including normal maps, screen overlays, decals, particle sprites etc) imported into the game
• Approximately 1300 materials in the game
• 422 meshes in the game, including 7 character models (AS-189 Male/Female child workers, Combine Elite, Daltons Mother, Inert, Sangster), 4 enemy meshes (spineleech, suicide scanner, bullsquid, prototype strider), 1 vehicle (Mustang), 9 Rebel weapons, 11 normal weapons, 4 Combine weapons. This doesn’t include meshes created but not imported into the game, or meshes that were created for earlier versions of maps and thrown out.
• Various enemy reskins, gibs etc
• Concepts for 5 other enemies that were not included in Episode 1
• Buggy concept and mesh unused for Episode 1
• Alexei character model unused for Episode 1
• At least 5 weapon models unused for Episode 1 (including rocket launcher, dispersion cannon)
• A Rebel surival guide, detailing enemies found in the world and survival strategies (some pages of this were released during media releases)
• A full manual design
• Many thousands of lines of code.
• Dozens of custom entities

I know what you’re thinking. You’re wondering who I am. See this? *points to nametag*. My name is David Sangster. I’m an ex-commando from the US Rangers. I led the best damn squad in the entire country John. They were good men, and I betrayed them…
I guess I should give you the whole story. I was involved in the 7-hour war… a war against the Combine many years ago. You probably wouldn’t remember it… in fact, judging from what I’ve heard about you, you wouldn’t remember a shred of information about it. I was assigned a high profile mission. Dangerous, hard, and it put every one of us to the test. They massacred us. My best friend… *Sangsters voice should start to break up a little here*. his name was Lieutenant Miller. He was shot in front of me, John. Right in front of my eyes *sniffs*. They all were. And I ran John. I fucking ran like a coward. Ran from everything I believed in, from my friends, from my comrades, from my country. And from my honor. Its why I still wear this uniform. It reminds me every day that I betrayed my loyalty and honor, and was disgraced in the eyes of my country, my friends, and myself.
*pauses and regains his composure*

Have you heard of The Corporation, John? They are why I am still here. The Corporation helped me keep my sanity in knowing that one day, just one day… I can get back at them for what they did to my friends. We are… we are an agency that secretly deals the Rebels inside information to help bring down the Combine. Attack information, weapons, experiments. Everything.
I’m here on orders from them. You’re our last hope John. The secret weapon of the Rebels. We all know it, but you don’t. You and you alone can save us from all of this. As far as our intel indicates, YOU are the main priority of the Combine right now. If we want to have any chance at all, we need you alive.

Perhaps the part of NightFall that I was most proud of was some of our writing and design notes. Of particular note are:

• A text file containing Latin quotes and meanings that we would use throughout our marketing campaign to foreshadow the story
• Character Diaries to be shown during loading sequences with voiceovers.
• Demon and Christian symbology as related to our characters
• Dozens of commentary nodes to include through Source’s commentary system

The one document that stands out is the design document for Map1_RebelCompounds (the second map you play in the game, after the Asylum dream sequence introduction) While a majority of this was written by Tom Edwards, its a 10 page document for one single map and details narrative goals, the setting, past and present plot outlines, all character interactions with dialog, scripted sequences etc. At the stage we ceased development, we had only fleshed out a few other levels (Asylum, 3 pages; Map1a, 5 pages; Map2, 5 pages; Map3, 3 pages) but its not an insignificant amount of writing.

As you can see, we had heaps of assets and marketing material created for the mod. We had grand plans, story ideas, and things were coming together really well. Unfortunately, this was all too late in the grand scheme of things. Our original plan was a 50 map epic – an insane goal, especially when you consider a mod of similar scope (Black Mesa) still isn’t released after 8 years. As I said earlier, some stronger planning may have mitigated this issue and gotten us to a point where we could have very easily released a few episodes of the mod. And the reason for this is the fact that over our lifetime, we produced AT LEAST 30 levels. Of the 30 that we produced, only about six were “final release” – that is, we considered them good enough to include in Episode 1 of the mod. However, we must consider the fact that we re-designed, detailed and lit some of our levels up to 3 or 4 times – most notably the Rebel Compounds maps, which were 3 of the first 5 maps in the game. Its important to note that every iteration of the Rebel Compounds we did was also fully scripted and most were partially voiced and included all the relevant story bits. Had the effort gone into creation of 9 unique, better thought out levels, I have no doubt Episode 1, at the very least, would have been released.

What I Call Home
I can’t believe I’m still alive down here. Its been hard going for the past week, but The Corporation have kept me with a good supply of food and water.
We have some new intel for Dalton and his crew. It appears that the Combine are planning something. We don’t know what it is, but with the intel we’ve gained lately, its looking to be huge. Bigger than any of us could ever imagine. Theres not much we can give Dalton without the Combine knowing, but we can definitely give him the basic lo-down on the Combines agenda before the shit hits the fan.
Theres one thing thats disturbing me though. For some reason, The Boss wants Dalton brought back to HQ. Its a weird request, even for such a high-ranking Resistance member – we’ve always worked to make sure that our true intentions are never known by the Combine. Usually I would have debriefed him myself… Something smells fishy. I don’t know what it is yet, but its not right. Once I’ve dealt with Dalton, I’ll figure it out.
-David Sangster

Even now I look back through the NightFall content and find something that I forgot we even had. This time around I came across a video of a barnacle eating a rat, a Combine-ated Big Ben, a model for a Prototype Strider, a render of a Zombine well before they existed in a Half-Life game (our own idea and concept) and a diary piece I didn’t know we wrote.

I still get chills down my spine when I hear that opening John Dalton introduction speech. I actually finish writing this post somewhat sad and disappointed that such an amazing concept never came to fruition. That poor management rather than lack of talent was the primary reason for our failure. These are all lessons that we learned, albeit the hard way.
Despite the failure, its probably something I should stand proud of. At our peak, I was 17 and formally assigned to the roles Project Lead/Producer, Creative Lead and Lead Programmer. For a team that peaked at well over 20 people spread all over the world, this was no easy task. But sometimes failure can teach you far more success, and I still have to NightFall to thank where I am today – even if ths reflection does bring a small tear to my eye. I’m hoping that the future may hold some sort of release – or at least a showcase – of more of the work that we did.

All that is left for the victor is loneliness… But maybe in loneliness, a soul can finally find solitude.

Really think about the best way to get critical feedback on your mod from a large audience. The important things are always gameplay mechanics and story. Playing the same game over and over warps your view on what is good and what it bad – so get your mod to a releasable state, and release it to get public opinion. Take the feedback, improve, and release again. The great strength of mods is an incremental release model. Utilize it to make sure your product is the best that it can be.

Over the past few years gaining some experience in the indie game development space, I can definitely say that a lot of the original “Lessons Learned” can be applied to game development, not just mods. The key difference between the two is obviously that your aim with a commercial game is generally to sell it and make money, so very rarely can you release a base product and continue to iterate on it, and then expect people to pay money at the end (or expect good reviews when you didn’t have a good amount of content in your first release). The obvious exception to this rule is Minecraft, but it must be said that no one in the industry understands exactly why and how Minecraft has become such a phenomenal success.
Many games have attempted to follow the success of Minecraft recently, with Desura introducing an Alpha Funding initiative that allows developers to crowdfund games while getting access to an Alpha version of the product. Probably the two standouts from this crowd are Project Zomboid and Overgrowth, although both of these games seemed to have a strong following and community involvement before being involved with the Alpha Funding program. For the most part, I believe that sales numbers from the Alpha Funding program are probably only in the thousands.

So the question remains how indie developers can get good feedback and put good testing methodologies in place for their games in order to create a polished, usable product.

The lack of ability to release early public builds means that you need to make sure you stick to a fairly strict methodology and test often. But this must come with with the understanding that it can often take a while for a product vision to come to life. In recent times, we’ve loaded up our game and really enjoyed playing it. There was an aspect of “Oh, crap, our game is really fun! How did that happen?” about it. I get the feeling that this isn’t uncommon among indie devs – often it can take a while for the pieces to come together into a product that makes sense.

The first hurdle that many indies encouter is simply creation of a test build to send to people. Good processes, such as continuous integration, and use of services such as TestFlight can make this process far easier. You’ll be far more inclined to send out a build if you can do it in a few clicks, rather than spending valuable development time packaging and distributing builds. Even something as simple as being able to zip up your game, upload it to a FTP and email a bunch of people can be frustrating to do often, but extremely easy to automate through as little as a few hundred lines of code.

Secondly and more importantly is the availability of testers, and who you get to test your game. The most crucial aspect of choosing your testers is ensuring that you can cover two groups: new players, and return players.
Every iteration, you should bring in a set of new testers who don’t know the games mechanics and see how they react. You should also use your last group to get their reaction on the changes that have been made. Both sets of groups can give you unique and useful feedback for improvement. These people should mostly consist of your target market, but its not a bad idea to get people in from outside your target market. They can often provide some valuable insights into how you may be able to gain interest from other markets, or look at your product in a different light to what others can.

This makes trade shows a very interesting prospect for the indie developer. Unfortunately I’ve only been to one – E3, which is hardly a place for the indie dev – but what I’ve heard about the critical feedback from players at PAX and GDC has been outstanding. Just being able to watch someone play your product, see their facial expressions and physical reactions can tell you so much more about your game. Trade shows attract tens of thousands of people – developers, journalists and gamers – and even if only a small fraction get to see your game, the perspective that it can offer is invaluable.

Valve have done several excellent presentations and articles about the testing process for their games, especially Portal. They highlight the importance of being able to observe your testers rather than relying on written or vocal feedback. Playtesting for Portal commenced as soon as the gun was in-game and shooting portals right through to re-development of the final boss fight 3 or 4 times. The developers were able to identify some key issues in all stages of testing primarily through observation.

For those people working with a client, these processes, while solid from an engineering and design perspective, can often be at odds with client expectations. Working with clients or managers who don’t understand the importance of a solid methodology and testing regime can be difficult and often harm the end result and quality of the product. Making changes late in development is costly or expensive and, in the end, may result in either releasing a sub-par product or blowing your deadlines and budget.

While some people might push you, try to never waiver on your development methodologies. It can be extremely hard, especially when money or desperation starts to get involved, but don’t get pushed around. If possible, get people to test your game in real life. You can gather a lot of data about where users trip up, become confused or enjoy simply by watching them and taking notes. Questionnaires once a player has finished testing the game can be great supporting material for anything you missed. Bring these players back once you resolve issues to see their reactions once you resolve specific issues they were having.

Minecraft demonstrated that games, with a bit luck, can occasionally succeed by using the public as its test platform. However, many more games – Angry Birds and Team Fortress 2 come to mind – better demonstrate that the importance is in your core mechanics and quality. You must get these right as early as possible, otherwise you may be dooming yourself to failure.

ModDB launched back in June 2002 and has gone through several design changes to become the website we know and love today. Its grown from modding hub, to indie development website to providing a digital distribution service, Desura, for independent developers, and initiatives such as the Indie Royale Bundle.

I’ve been lucky enough over the years to have a small involvement at ModDB through being an administrator, assisting with migration and testing of the latest version of the website, as well as contributing articles, tutorials and opinions. Being an Australian built website, many of the contributors, writers and modders have been local to me, and I’ve been lucky enough to share several drinks with various people over the years at events such as Freeplay and IGDA Melbourne meets. Desura and ModDB are generally represented in some way at many Australian events, which is fantastic for the local industry and even better for the great community that has been built.

But the real success of ModDB has come from the tireless work of founder Scott Reismanis and long time contributors such as Dave Traeger and Mark Chandler, as well as all the past contributors who have moved onto other jobs. I’d like to truly thank them for giving me the opportunity to be involved with such a great website and community, and wish them all the best in the future with ModDB.