Unreal Engine 4 has some awesome features and a whole bunch of stuff that makes life really easy. Lots of these are small, minor things that people often don’t pick up on, or can be hidden away a little, and the Unreal Engine blog is doing a great job of explaining some of these things.
One thing I’ve found is that often the posts don’t go quite far enough in showing an example of how to use something, which is the goal of this post, and hopefully more into the future.
This concerns the Input Axis feature, which is well explained in this blog post from Epic
But how can these input axis bindings get put to use?
It’s actually quite simple!
In this example, I’m working on a Shoot Em’ Up prototype purely in Blueprint
I’ve added a couple of simple InpuxAxis bindings as described in the Unreal Engine post.
If what you want to control is based off Character, then by default it has a CharacterMovementComponent which you can see in the Components tab.
If you have this, then there’s a very handy way to move your Character in Blueprint – the AddMovementInput node.
This accepts a Direction and a Scale Value. In the case of the Shoot Em Up. The Direction is simply the direction you want to move the Character in, and the ScaleValue is the scale that you get from the InputAxis.
As you can see here, I’m using Horizontal Axis and moving it along X.
If you’ve already got a setup and don’t want to use the InputAxis events, you can also get the axis values as variables
That’s all for this post!
I hardly consider myself any sort of authority on anything. I’m just another dude with an opinion who makes games and teaches people to make games. Thats why I generally avoid commenting outside of my area of expertise – generally I stick to talking about events I’ve been to, teaching things, some game design related stuff. Things I’ve done, screwed up and found solutions for.
This post will be a little different. This post is a piece of commentary, which I haven’t really done before.
This week was CES2014 – Consumer Electronics Show – and there’s always some great announcements. This year the one that has caught everyone’s eye is the announcement of the Tegra K1 – a 192-core mobile chip based on Nvidia’s Kepler desktop graphics architecture.
This announcement is big for a few reasons, not the least of which being accompanying videos showing Unreal Engine 4 running on a K1-powered device, and the reveal that it was a DirectX 11 chip.
Many websites have covered the announcement and tech specs of the processor, so there’s no point repeating all that. What I want to talk about are the potential implications for mobile game developers.
As developers we’ve had fairly powerful chips for a while. Granted, those chips aren’t anywhere near the power of the K1 but we’ve been able to make some pretty sexy looking games as it is. So what opportunities does one chip in a saturated marketplace offer to developers?
Despite a massive increase in power and the promise of coming close to matching PC quality graphics, I still believe there will be challenges developing for mobile devices in the forseeable future. While we do have DirectX 11 support on the K1, that will surely be limited to just Windows mobile devices which only make up a small percentage of the mobile market. Developers working with DirectX on PC will still need to work on dual rendering pipelines in order for games to run on mobile devices.
The proliferation of these chips is another potential concern. We are yet to see what else will come of the next generation to compete with the K1 for power, and without exclusive partnerships from hardware & device manufacturers I feel that developers would hesitate to design a game that focuses purely on the high-end, as its such a small marketplace.
Finally, the last challenge is that mobile devices are still inherently casual devices. 2D or small simple titles still totally dominate the mobile marketplace and given the lack of success by high-quality AAA-style 3D games on mobile devices in the past, you have to wonder where these style of games fit into the mobile economy.
We’re still probably a few years away from games being developed/ported to mobile in the same way that PC-to-console works right now. For developers who plan on using high-end engines like Unreal Engine 4 to take advantage of the better chips there are associated risks, given the majority of any target market will be in the mid-range of devices come next generation. But that doesn’t mean its not a risk worth taking – the payoff for a quality mobile title can still be huge.
Its going to be a hard for higher-end mobile developers to strike that balance. Perhaps a good first step is even some sort of asset sharing between systems. What I do believe is that this that Nvidia may have fired the first shot in what will be a long battle for mobile chip producers.
In 2012, I wrote and delivered a single subject at TAFE, replacing a teacher who was taking a semester off. The subject was a programming and in the past had focused on Java, but the TAFE was trying to bring Unreal into its curriculum more, so considered this subject as a trial of teaching UnrealScript.
The subject went reasonably well with some hiccups, but unfortunately the idea of teaching UnrealScript as one subject in the course didn’t take off, for a variety of reasons. It seems like a waste to do nothing with the content I had written, so I’m releasing them here.
It consists of a handful of PDFs going through some basics of UnrealScript as well as basic mutator creation, basic weapons and basic gametypes. There may be some gaps in the content as it was a mix of Powerpoint slides, documents and working in a classroom with students. You can download a zip of the PDFs here.
Every time I seem to make a pledge to blog more it never seems to actually work – at my current rate I write 3, maybe 4 blog posts a year which is definitely not enough.
I say it every year, but this year will be different. This time, I think I mean it. In the past year I’ve gone between several jobs, worked on contracts and prototypes at Pub Games that we couldn’t talk about. With a more stable job (teaching distance-ed full time) and involvement in Pub Games part-time working on a variety of projects this year.
One of the commitments that we tried making as a company when we first formed was to be open in the development process. When you look at a lot of the successful indies, they share a lot of things about their game as it progresses. Its part of the indie way of marketing – development blogs, progress screenshots and reports, and early access.
My challenge is managing what I talk about. What I work on is often technical, inside the guts of game mechanics or engine technology. Its solving problems that a lot of people have solved before, but just not in our context. That doesn’t necessarily make for interesting blogging, especially if I’m not showing code or anything like that.
Anyone who has read my blog in the past knows that I’m often long-winded and heavily opinionated. Writing these sorts of posts requires a lot of time, something really interesting to talk about, or something interesting I’ve read that I have an opinion on. This is one of the aspects I want to try to change – the occasional big opinion piece, but keeping the blog more regularly updated, even with small tech things, small discussions on what I’m working on, etc. It might not be the best opinion, or even an opinion at all. It might just be the way I’ve gone about solving a problem.
So that’s my New Years Resolution. To be a better, more regular blogger. Lets see if works out this year.
For those of you who weren’t aware, PAX came to Australia in 2013. Specifically to Melbourne. It was the first time such an event had been held in Australia. While we have events like EB Expo, it’s not the same scope or reputation as PAX. For the local industry, it was a fairly big deal that PAX was coming to Australia – it would give Aussie developers a chance to take part in a big event that gets lots of media coverage.
The expo itself was fantastic. The indie section is the best that we’d ever seen, attendance was good and we got to showcase our game to plenty of people. It did have its share of issues – for instance, the facilities left a bit to be desired, but that wasn’t unexpected due to the venue it was held at. While there was a bit of miscommunication during the organisation of the event, overall it was pretty successful and well run.
For Pub Games, this expo was something a bit special. We’re not strangers to exhibiting at all – we’ve been to both PAX events in the USA, as well as GDC and EB Expo. But not only was it being held in our home state, not 25 minutes from our office, but it was the first time that we got to showcase a released title. This meant that we could get far more information on the impact and success of the event in regards to download numbers, social media “likes” and website hits.
I’d like to mention that the Crabitron did a short analysis of how their sales changed during PAX. You can check it out on their website. In short, they did have a spike in sales during PAX weekend, as well as a decent increase in their rank on the App Store.
Unfortunately, the same can’t be said for BlastPoints. Our new installs per day during PAX pretty much stayed the same. Our social media “Likes” only increased when we ran a competition to win a MOGA Controller.
It is a fairly small sample size – one event, covered mostly by local media in a location that was awfully hard to try to get people to download the game on the spot. On reflection, we did some things wrong:
- We didn’t make it obvious that the game was free-to-play;
- Our signage with the Google Play and App Store logos was designed poorly in that the icons weren’t even visible due to monitors and a TV on our table;
- We didn’t have a flyer or card with information about the game.
These aren’t things that had really occured to us in the past because the game had never been released at any other stage, and they’re definitely things that we will be keeping in mind for the future. Its the first time any of us had shown a released product at an expo.
So what does this really mean?
Its difficult to say much based on just these numbers. The first question is “What do you aim to get from your marketing dollar?”. Companies such as Riot Games and Wargaming invested big amounts of money in their booths and swag at PAX Australia, and one suspects they wouldn’t recoup that money in direct sales in the week after the event. What it does get them is exposure in the media. From interviews to their booth being in photos shared across social media, its all about exposure rather than a direct return in sales and download numbers. PAX got us a few interviews with various media outlets, helped us further build relationships with companies and, most importantly, strengthen the Pub Games brand.
The second question is “Should you still attend these expos if you don’t make back what you spend?”. The answer to that question is absolutely – no direct spike in numbers doesn’t mean we cut our losses and stop attending exhibits. This information is just another tool for us to use in the future on how we can do better. We can now ask ourselves how we can try to get more people to get the game on the spot, and how we can better promote our game and the company. Crabitron got a spike by discounting their game to 99c. Other companies often give away vouchers for free in-game items. These are steps we can look at taking for future events to help get a better bang for our buck.
One of the best aspects about PAX is that it was the first time I’d helped exhibit a game at an expo. I can tell you for sure that I definitely did not expect it to be as tiring as it was. By the end of the first day, I’d lost my voice. By the end of the second day I was definitely sick and ended up taking the third day off. But its something thats a great experience – having people walk past and take an interest in what you’ve crafted. Having people genuinely interested in your story, how the game came about and where you plan to take it. In the end, as a developer, you want to see people enjoying what you’ve made. And while it was an exhausting experience, I’m genuinely excited about the next opportunity that we get to showcase what Pub Games is about.
It’s been a long time since I’ve actually made a post on this blog, and that’s been for very good reason. Frankly, I haven’t had much to talk about for a while. Real life interrupted, things happened, BlastPoints work kicked up, etc.
With BlastPoints now out the door (release is very soon), and prototyping of new projects underway (albeit things I still can’t talk publicly about too much), one of my goals is to start writing a bit more. I guess I have a bit of a varied life, between teaching, game development and possibly a software engineering job, so hopefully things will pop up more often that I can talk about from many perspectives.
The other issue I find with blogging is that often a lot of opinions I have are awfully strong and often contrary to other opinion. Some may view them as criticisms, rightly or wrongly, and often they don’t come across well.
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.
Steam Greenlight has been live for slighty over two weeks. In this time it has seen the submission of hundreds of games, a change from a free submission to a $100 paid submission, much public scrutiny about the discoverability of titles on Greenlight and discussion about whether its simply a popularity contest
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.
I only started my teaching career at the start of this year, fresh out of university, as a bit of extra income while trying to get Pub Games off the ground. Depsite the intention of it being stop-gap work, I’ve quite enjoyed the challenges that I’ve faced, and its been extremely rewarding to see some of the work thats come out of my students so far.
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.
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.
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.