Category: Uncategorized

I recently participated in an online discussion where the OP asked if people use Agile or Waterfall in their game development methodology. I usually sit these things out, but this one piqued my interest, and I was expecting the OP to get flamed for asking something that sounded a lot like “What needs to get added to powdered water to make it drinkable?” I watched the replies come in for a few days, then finally started asking questions to see how these fellas were defining “Agile” and “Waterfall.”

Having worked and learned from industry gurus that literally wrote the book on software development processes, and having advised software development companies on their dev processes, asking this question was somewhat unfair on my part.

Most of the responses to the original poster were a variation of “I use a combination of both; agile during this phase of a project, waterfall during that phase of a project.” Whoah, Nellie! That would be like having a mixed-race kid, like me, telling you that I was white from ages zero to 15, then black from ages 16 to 30, and I’m thinking of being white again for the next two years. Unless you are a pop star, it doesn’t work that way.

I was curious that so many respondents seemed to think that they’re using a combination of both styles of development management, when they’re unaware that they’re using neither. It became apparent that no one really knew what either method really is. I asked the forum to explain what their interpretations of “Agile” and “Waterfall” were. The explanations went like this:

Waterfall is:
1. A project is in pre-production. A lot of great creative discussions happen. The designers design and may produce a GDD or may not; the artists come up with some incredible concept art, and the engineers do some proof of concept work and set up the pipeline or fix the game engine as needed.
2. A milestone schedule is produced. Every period, say every 8 weeks, a milestone is reached after a crunch period.
3. The game goes through QA and submission.
4. The game ships.

Most of us are familiar with this method as this is how most game projects run, but it isn’t waterfall. Rather, it’s a sequence of events that you are calling waterfall, or pseudo-waterfall. It is somewhat-managed chaos. Like pseudoscience and pseudo-medicine, it’s relation to waterfall is in the name only. Like pseudo-medicine, it is as effective as snake oil, and the game ships because of individual heroics instead of solid management practices. Pointing this out is not a way to make yourself popular.

I think Waterfall actually looks like this:

 

 

Requirements — Design — Development — QA — Implementation –Maintenance

Although 99% of game projects run this way with some prototyping thrown in, it’s a bastardization of waterfall methodology because our industry “sort of” creates requirements (GDD) and “sort of” does design – I say that because in 11 years of game development, beyond maybe one good GDD out of all my projects, I’ve never seen high-level, low-level, horizontal or vertical design docs, let alone a software design doc, architecture design, database design or ERD. Asking for these has been fruitless. Maybe pointless too – I dunno. Every designer I’ve interacted with questions the need to write an extensive GDD, and to be honest, I don’t know who is correct on this one. Some studios can do a rudimentary design on paper, jump right into a playable prototype, and make a title that sells a bajillion copies.

Things got hairier when I asked how the posters defined Agile development, and I admit, I stirred the pot a little because frankly, I’ve seen many job postings our industry asking for experience in Agile and Scrum, when no one knows what Agile and Scrum really are.

Finding out just what people know of Agile development methodology is eye-opening. The responses I received when I asked the forum what they thought Agile development comprised of went as follows:

Q: Who is your customer rep is in the bullpen?
A: That’s always the lead engineer leading the scrum team.

Q: How do you implement iterative acceptance testing?
A: We send it to QA, sometimes before Alpha but definitely at Alpha.

Q: How is your information radiator managed?
A: We send out notes of the dailies to everyone by email.

I wish I could say that I was kidding about the responses. So, I pointed out that if the PMs out there are working to a milestone schedule, they’re doing pseudo-waterfall chaos. Picking and choosing items from Agile methodology, like daily stand-up meetings/scrums, might qualify as pseudo-Light Agile Development, but it’s that’s where the resemblance to Agile ends. You’re still doing pseudo-waterfall development, but you believe you’re being “Agile.” I was nice about it, but the result was a lot of forum posters getting negatively excited.

I’ve implemented LAD to some degree in each team and studio I’ve worked in, but it’s only an adaptation to the milestone-based, pseudo- waterfall chaos method for a project that has an alpha, beta and final/submission phase, whether console, PC or mobile. Calling a development process “Agile” does not make it so. It’s time that we man up, admit to ourselves that our development management is chaotic and immature, then fix it. The software development industry did this 20 years ago with the creation of the Capability Maturity Model. Do we need to go that heavy on process? Probably not. But it would be kinda cool if we had a workable process model for our industry. Once our rock star hangover wears off, maybe we can do that.

There’s an elephant in the room in the games industry, and it’s QA.

QA isn’t the problem; it’s the symptom and a solid indicator that the games industry has a lot of growing up to do. Why? Our development process is broken. Badly.

QA is the bottom rung of the game development ladder, and is seen as an entry point for the hordes of avid gamers that want to get a foot in the door of game development. As such, it’s at the bottom of the pay scale, and QA is often treated as a necessary side trip on the road to producing a triple-A title. QA teams in large studios are often kept at arms length from the development team, and typically not brought in until pre-Alpha planning and submission deadlines are looming.

In my first producer role in the games industry 11 years ago, I received pushback when I pointed out that we hadn’t hired any QA in pre-production. I was summarily informed that QA is only needed in this industry as we approached Alpha.

Coming from a business software development background, this was surprising. Overriding my recommendation to hire professional software-dev QA, management opted for a tried-and-true formula of hourly wage gameplay testers. Did it work? Yes. Did it work at optimal efficiency? No. Why? People were working overtime to find and report bugs, then get them fixed.

The same view was the de rigeur standard in larger studios. My next gig was managing several game aspects of a development team for a triple-A title in a major studio. On the larger teams, we had up to five development directors, each responsible for the delivery of multiple game areas. I volunteered to work with QA, as I wanted to get an idea of what was going on in Testville.

What I found was that QA was indeed the very, very bottom rung of the studio ladder. As I was doing my due diligence on equipment, the QA team leads indicated that they didn’t get adequate numbers of console test kits or have their basic desktop systems repaired in a timely fashion by IT, because, well, they’re QA. They were also discouraged from spending time on the dev floor, and kept in a building across town.

I came from a Windows application and database development background, where QA is on par with all aspects of software engineering, including pay, for the sole reason of its importance in the development cycle.

Why isn’t this the case in game development? I can only surmise it’s due to old-school thinking from the wild west game development days: “We don’t need a process; we’re making money hand over fist so we’re doing things just fine, thank you.” Actually, you’re losing more money than you know – more about that in a bit.

Our industry development processes are where the software development industry was 30 years ago, before the non-profit Software Engineering Institute came up with the Capability Maturity Model. Game development is, for the most part, at CMM Level 1, known as Initial: Chaotic, ad hoc, and projects are completed through individual heroics. If you think that’s sustainable, look at how few triple-A games are out there compared to the old days.

I’ve heard the repeated mantra for justifying lack of process and questionable management approaches to QA: “We don’t make software, we’re more like making movies.” There is only one answer to that: No.

We make entertainment software, which is infinitely *more* complex than traditional software development due to the player changing the outcome through gameplay, not to mention online interaction.

What we need is an honest look at what is broken in the development processes, or lack thereof, in our industry, and a commitment to bring up the level of professionalism. There is no excuse for the 80-hour work week. The only reason for overtime is simple: bad planning.

Scrutiny of development processes also requires a re-vamp not only of how QA is staffed and managed, by hiring QA engineers right out of the software development field – engineers on par with any other engineer on the team – and integrating them with the development team from the first day of pre-production. If we did this, many of the testing requirements for our titles could be automated, and QA team sizes significantly smaller. This is perfect-world thinking, of course; feel free to disagree with me on this.

One of the well-established practises in traditional software development is to have QA test the requirements and initial design documents of your system, before a single line of code is written. Why? The 80:1 return on investment. When I was working as a consultant to optimize the development processes of software companies, the cost differential between fixing a bug in design (i.e. on paper) versus fixing it in production software was 80:1. To put that in games industry terms, QA finding and fixing a bug in your GDD will cost you a buck. Fixing this at Beta will cost you 80 dollars. This is a 25-year old paradigm; more recently I’ve seen project managers put that at 120:1.

The big picture is that we need to rethink how we manage QA in game development. QA is at the tail end of our dev cycles, when it should be at the forefront of the next triple-A kickoff meeting. I don’t see the logic of trusting the last stop before a $20 million title hits the customer to entry-level employees. Empower them, train them, and treat them like software development professionals. They’re a highly motivated and ambitious employee group.

Ten years ago I was a producer working for a boutique studio, and Microsoft picked us up to work on some games for them. I was at a meeting in Redmond with our studio management and the Microsoft dudes, who were headed by Ed Fries at the time. I admit, I was a little over-awed. This was before the 360, and Sony was eating Microsoft’s lunch on console sales.

My boss asked Ed the big question about how they’re going to catch up, to which Ed answered, “We already own the office. Now we’re going to own the living room.” Followed by an all-knowing, friendly-yet-evil grin.

I was awed yet again. Microsoft did indeed own my office, and still does. And now they’re going to take over my effing house by the short and curlies!

That opening line again: “Ten years ago.” I heard several bloggers mention the same line in context to the Xbox Uno. Erm…their new console looks like a vintage VHS player. New launch excitement? Crickets, man.

But this blog is about and for managers, so HEY! WELCOME TO A TRANSITION YEAR, WOOT!

What does this mean for us, as game development managers?

o Emergency stress!
You’ll have to turn one or more of your 360 titles into Xbox One titles after E3. Your exec team thinks you need more titles because the competition has more titles than you. Too crazy? Get ready for it. Happened at the world’s biggest game maker in 2005 with the last console launch.

o Ballooning team sizes and a hiring blitz!
Watch programmer salaries skyrocket due to demand! And artist and designer salaries creep up from the area-of-effect damage from engineer salaries!

o Only Call of Duty will sell this holiday season on the new Xbox!
Why? Because that’s exactly what happened in 2005. The peeps that buy a new console have burned all their cash, so they’re only buying ONE title! So making those extra titles at the last minute makes even more sense!

o Engineering revolt!
Your engineers are all going to hanker for a shot at the new hardware, leaving you with your whole engineering team wanting to transfer to the Xbox One and PS4 teams. That is, if you get to keep them at all! As soon as your game is finished, your staff are making inquiries at other studios. Fact of life!

o Your pipeline will break!
A lot!

o The wasted effort!
No one will recall how realistic the dripping sweat looks on the athlete’s head! But you’ll spend months rendering and re-rendering it for marketing that you could have used building more animations or cut scenes!

Please don’t mistake my sense of humour for cynicism, as looking back, I have to chuckle at some of these events. I’d love to hear from you on what we need to be aware of with the new boxes!

 

Leadership: Part 1 covered “Forget your career, focus on your team”, and real-world examples of the first 5 of 10 leadership principles:

1. Achieve professional competence.
2. Appreciate your own strengths and limitations and pursue self-improvement.
3. Seek and accept responsibility.
4. Lead by example.
5. Make sure that your followers know your meaning and intent, then lead them to the accomplishment of the mission.

Here we start looking at the next five.

6. Know your team and promote their welfare.
This one is achieved from your regular 1:1 meetings with your team. Instead of sitting in a meeting room, go for a 10-minute walk outside the office. Let the team member drive the conversation. You can serve your team better when you know them as individuals, not as roles.

7. Develop the leadership potential of your followers.
Especially important when you want to take a vacation. Start by having your team leads run your daily Scrums.

I was on the road for six months, training clients and implementing software. I came back to the office to hear about one poorly-performing QA analyst that was chronically absent, and when present, was falling asleep at his desk. The team lead said, “I’m just trying to do my job, I don’t want to hear about this.” This told me it wasn’t a problem with the sleeping analyst, but with the team lead that needed some management training to deal with a problem employee.

8. Make sound and timely decisions.
I wish that “sound” and “timely” always meant “correct”, but this is not the reality in a fast-paced dev studio. You WILL make mistakes, and you WILL make decisions that you will need to adjust or scrap later – this is management life.

One manager I worked with demanded infinite detail before making a decision. Explorations. Research. PowerPoint decks and more meetings to explore the alternatives. This was make-busy work that frustrated her team, and a decision should have been made days or weeks before. You have to strike a balance between knowing enough (which will never be enough, so deal with it) and making a damned decision. You can always change it, if you need to, but make it!

9. Train your followers as a team, and employ them up to their capabilities.
If you ignore this one, it will solve itself. Resentment will brew in the team for perceived favouritism if you focus only on one or two people, and under-employed, unhappy-yet-valuable team members will leave. FYI, 90% of job resignations aren’t due to low pay or lack of advancement opportunities – 90% of the time, people quit a manager, not a company. That’s you.

10. Keep your followers informed of the mission, the changing situation and the overall picture.
Daily team meetings, period. It’s the basis of Scrum, after all, whether or not you use full Scrum methodology.

Every team that has never done dailies has complained to me about the inefficiency of yet another meeting. Keep it to 15 minutes max, and I mean MAX. If you ever miss a daily meeting due to other emergencies, watch how quickly people complain that the meeting was cancelled. This is because daily meetings create immense value.

Also, as a manager, when it comes to your turn to speak up about your tasks (I usually start or end with my tasks), it’s all right to say that you don’t know yet what your major tasks of the day are. Many managers do a lot of fire-fighting, so this is expected. Hearing a rendering programmer tell you that they don’t know what they’re going to be doing for several days in a row, however, tells you what you need to address.

Here’s a dirty little secret that they don’t teach you in Scrum training. The main benefit isn’t from the team sharing the information in the meeting. The meeting is too short to start collaborative discussions anyhow, and most people are thinking about what they’re going to say when their turn comes up. This means that they’re only subconsciously listening to the people that speak before them.

No, the biggest benefit of a daily Scrum doesn’t come from the meeting itself, but from the social interaction and offshoot, informal meetings that individuals have as they leave the meeting area. Result: better team communication all around.

That’s all 10 Principles of Leadership. Any thoughts? What works for you, and what can be added to the list? I’d love to hear from you.

How did you become a manager?

Were you an excellent artist, designer or engineer that was promoted to management? Or did you seek out a leadership position from the start, knowing that you wanted to be of service to others, or because it was a no-brainer to ambitiously climb the ladder?

I don’t expect anyone to answer the last question, as it’s totally unfair. Most western societies respect someone rising up the chain of command, regardless of the method. I’ll talk about psychopaths in a later post, as that’s a whole pile of hurt that affects us all.

A few years back, Scott Adams, the creator of Dilbert, ran a poll on his website to identify the biggest problem facing corporate America. The overwhelming response, which made international news coverage, was “Idiots being promoted to management.”

Hmm.

I was never a good developer. I only learned as much code as I needed to tinker with my first software company’s database in order to help clients meet their business needs and repair corrupted datasets. I learned the basics of HTML because, well, it’s kinda like typing, just add some brackets to do what you want. I’m certainly not a good artist. My drawings are amateurish, though I love making them and they crack me up. I’m a competent writer, and I love writing narrative, so I do a lot of that in my spare time.

However, I was groomed through time in the cadets and the army to be a leader/manager, whether I wanted to or not. I don’t consider myself to be a great leader, but I’m aspiring to be one some day. Regardless of your thoughts on the military, it taught me some good ideas on leadership that I’ve brought to every management position I’ve been in, albeit adjusted to do away with all the yelling, shooting and other non-essential military stuff.

NOT ABOUT YOUR CAREER ANY MORE

The first concept I learned was to forget my own career, and focus on that of my team. This sounds completely counter-intuitive, but it actually serves to propel your career forward. The reason is simple. If a whole team looks good, so does their manager. Higher-ups notice this.

Second was to follow the 10 Principles of Leadership I learned at military school. Here are the first five, and some real-world applications.

PRINCIPLES OF LEADERSHIP

1. Achieve professional competence.
For me, this means constant learning about project management, people management, software design/game design/requirements design (UML FTW!) and learning the business model of every company I work with. I still think casual games and Android make no fiscal sense for game industry longevity, but I’m willing to admit I’m wrong. The jury is still out on those.

2. Appreciate your own strengths and weaknesses, and constantly pursue self-improvement.
Once you gain a big chunk of knowledge about one area, and people look up to you, overconfidence strikes and it’s hard not to think you’re an expert at everything.

You’re not.

New medical doctors, MBAs and Ph.Ds make this mistake a lot, and so do newly-promoted managers. It’s called the God complex. You assume that because you are an expert in one area, you are an expert in all areas.

Again, you’re not.

I made this mistake as a newly promoted manager. Did you? I also know that I’m a glutton for praise, but I’ve forced myself to re-direct that praise to the team, and I therefore don’t get a big head about it. Otherwise, my ego would simply piss people off, and I’d probably start making bad management decisions.

3. Seek and accept responsibility.
This means, “Seek and accept responsibility even when it’s really uncomfortable.”

One day after starting a development director job in a new studio, I was ordered to immediately fire a member of the audio team by multiple VP-level execs.

After a week of my own investigation, I made the decision to fire the individual, because it was the right decision for the team and the person, while arranging a good compensation package. The audio team veterans were livid, blaming the VPs for this action, and were about to start emailing up to the top of the company chain – a very big company chain – when I told them it was my choice, and my responsibility.

I admit, I was tempted to weasel out, and say that yes, senior management had made the decision before I got there, which was partly true. But then, my mental drill instructor would have kicked my ass into next Tuesday. I still stand by that decision.

4. Lead by example.
The most important one for me, it always annoyed me that this was number 4 on the CF’s list.

I heard a variation of this: “When others speak ill of you, live your life so that no one will believe them.” I can’t recall who said it, but it’s great. When you are in a leadership position, especially if it’s a public one, the petty and small-minded will take shots at you, mostly because they feel powerless in one or more aspects of their lives. Don’t shoot back; kill them with kindness.

There’s so much I can say about this, but it would detract from those three simple words – Lead by example.

5. Make sure your followers know your meaning and intent, then lead them to the accomplishment of the mission.
Ever have five people on your team give you five different ideas of what your game is supposed to be? Make sure everyone knows what your end goal is, and what the smaller goals are that get you there. Even better, let them come up with the necessary steps to get there, so that they own the direction of their game area.

Continued in Leadership Part 2.

When a high-profile violent act occurs, and a link is made between that act and, say, Mortal Kombat, GTA or Call of Duty, a big mess of squabbling erupts in the news media and in the game blogosphere about whether or not violent games cause violent behaviour.

The short answer is yes. So stop arguing already.

The long answer is also yes, but other factors also contribute. The same arguments were used before games looked so graphically real, when crusaders (correctly) identified violent movies, music lyrics and literature as contributors to violent behaviour. Games are just an easier target these days, but still just as guilty.

I’ll explain why in a moment, but first a personal anecdote.

A few years back, my boss and I played a lot of GTA Vice City. He and I had an interesting conversation one day about how GTA Vice City was affecting us. We were both game completionists, and probably still are. Our studio was situated in a building that housed a bank on the ground floor below us.

My manager stated that walking home from work one evening, he saw an armored car parked outside the bank, doing whatever armored cars do. He thought to himself, “I could just take that.” A few seconds later he shook his head and walked home, shocked at his thought process.

I told him about cycling home from the office at 1 a.m. This was many hours after everyone had left for the day, and I had enjoyed five or six hours of playing GTA Vice City. On my bike, I was invincible. I could hit any car, then it would crumple at my onslaught and catch fire, and I’d simply get up, hop on my bike and continue home. Good thing it was 1 a.m., or I probably wouldn’t be here to write this.

What surprised us most was that we could even think in the way that we were. We were both reasonably balanced, educated and socially adjusted men that had been professional managers for many years. How could one game make us think this way?

The study of psychology tells us a lot about this process. The news media often points to direct cause and affect, as it makes a great headline and sound bite, but tells a really skewed picture of reality.

Peer-reviewed psych textbooks will tell you there is no cause/effect solution to explain human behaviour, but that human behaviour is a result of interaction between three elements: Biological, Psychological and Social influences, so that behaviour and conditions are a bio-psycho-social phenomenon. All three areas can interact to produce the perfect storm of antisocial, violent behaviour. But it’s also situation-dependent.

Developmentally challenged with poor impulse control? May have a biological root, from a physical issue that damaged the brain, for example. Mildly autistic with a tendency to self-harm? May be a psychological disorder. Grew up in a house where violence was the solution for settling disputes? The social influence in your life indicates that this is an acceptable solution.

The above is an extreme example. But what if only one element of the three above was true? Throw in a lifetime of social ostracism, binge drinking, six hours of carnage playtime in a game that allows you to steal cars, hire prostitutes then beat them to death to get your money back, and you may have a recipe for a real-life shooting rampage.

So here’s the kicker: exposure to behaviours can often result in repeating those behaviours, especially in children and adults. Canadian psychologist Albert Bandura showed us this with the Bobo experiments. Children shown an adult beating the crap out of an inflatable doll almost always did exactly the same thing when left in the room with the doll later.

The kids were even more violent when shown the adult receiving some kind of reward after hitting the doll.

This is how human behaviour works. It is a bio-psycho-social phenomenon. We reward violent gameplay in our designs with mission progression, more abilities and bigger weapons. Arguing against that is simply obtuse. Why else would US, British and Canadian militaries use FPS custom maps to train soldiers? The USMC map for Doom was brilliant.

Then there’s the evolutionary psychology perspective, that says men evolved to throw a spear at a target, while women raised the young. Males, it’s argued, are hard-wired to hunt. Much of this behaviour has been transferred to watching sports and vanquishing a game-based enemy. Certainly, more males play shooters than females, and more females play The Sims – a game with no end-point.

What do you think? Should we keep believing the marketing speak that violent games don’t influence violent behaviour? Or should we just fess up and point to the ESRB label?

And what about the opposite, where pro-social behaviours and cooperation reward the player? I see a lot more of that in the MMO guilds I play in, than online buddies going on rampages. Just sayin’.

I’d love to hear from you.

I came from traditional software development, and the first dev company I worked for made all the classic mistakes of no process, projects finishing only based on individual heroics, finishing late and of poor quality.

There had to be a better way.

The company hired a process consultant. This fella came from a software development house that had a reputation for always delivering on time and on budget. We were dubious at first, but our software system was already two years late and 200% over budget.

Like a lot of software companies, our culture wasn’t ready to embrace the changes he proposed whole-heartedly. As a result, a mish-mash of processes were used that somewhat improved things, but not a lot.

Frustrated, I left that company to join another development firm at the opposite end of the spectrum: it was being crippled by process. They had process for no other reason than for the sake of process. Everyone, and I mean everyone, hated the process owner, a PMP who smugly wielded more power than the executive management team to decide whether or not a project was green-lit. Ultimately, this company’s software was late, over-budget and buggy, but the process was followed rigorously.

Eventually I hired on with a management consultancy, where I learned all about, and started teaching about, requirements (i.e. design), estimation, and risk assessment.

Always having loved games, I jumped at the first opportunity to work in a game studio. I was in heaven, with the exception that process definition was where the software development industry was 30 years ago. Heroics, long hours, and missed deadlines. I started asking the questions about process, at every studio I worked at. And every time I heard a similar response:

“Ve make gaaaames, darlink, not softvare. Now vhere did my unicorn go? I have a brunch meeting at ze Lucas ranch. Zey looove me in San Rafael, you know.”

Um, that console disc contains…oh, never mind.

So here I am making games. And guess what? Many traditional software developers sneer at game developers because games can’t be taken seriously. I know this, as my co-workers and I used to be the sneering ones before I joined the games industry. I’ve since learned better. The irony is that game development is significantly more difficult to do than traditional software development.

Why? Well, you can check all the functional boxes off from your design, but that doesn’t cover “fun”. Nor does it account for emergent gameplay mechanics that come about due to an AI-based system.

But I was equally perplexed by the closed minds in the game industry when it came to implementing process, with the excuse that this is a creative industry and therefore process has no place. This is known as faulty logic. Dusting off your first year university logic textbook, the argument goes like this:

“We have to continue without process in order to be creative, or we will fall prey to our competitor.”

This is known as the Either/Or Fallacy, or False Dilemma, where the speaker implies that only one of two choices exist. It’s only one example of faulty logic that I’ve heard over the years to justify lack of process.

I’m not an advocate of process for process’ sake; I think that’s as crazy-making as no process at all.

What do you think? What’s the right balance of process to keep a game project moving in the right direction? How do you wrap the fun-factor into a documented dev process? I’d love to hear from you.

Before you read this, you should know I’m a bit of a curmudgeon. But I’m having a much better day than her. ^^ See, she works for a casual/social game studio.

I consider myself an old-school gamer, but I like new games too. I like games on PC and consoles that are complex, like RTS, MMOs, RPGs and shooters that a) make you think and that b) entertain you instead of the usual run-and-gun. I like that Chris Roberts wants to bring something of meaning to the PC again. And I get sheer joy coupled with the usual emotional highs and lows from sneaking or blasting in a shooter like the Borderlands series.

Our industry is leaving behind the players like me to chase its tail, and continues its wobble into casual, social and mobile. While waiting for a haircut, I recently tried an iPhone freemium car racing game that ripped off the night time, urban drag racing portion of a game I worked on a few years back. After six races, I had to either wait for 4 hours for gas to refill, or pay cash to buy gas to race again. I received great emotional reward for deleting this game from my iPhone. Did the marketing team really do their homework on this one, or am I simply a relic?

Wasn’t anyone around in the 1990s with the internet boom? The companies everyone gasped about were the dot-coms that a) made nothing, b) had no clients or revenue and c) got upwards of 80 to 100 million dollars in venture capital. Why? Market speculation and “CEOs” (quotes intended) that were useless business managers, but phenomenal talkers speakers that used their cult of personality to motivate otherwise smart people to stop thinking about P&L. Am I exaggerating? Possibly. The documentary film Startup.com may disagree with that.

Everyone talks about console taking a dive on the revenue side. Doesn’t this happen in the last period of every console cycle? I remember the last two console cycles. It’s just like now. Why is everyone panicking? Why is this considered news?

Casual/social is making big bucks in the short term, or rather, it was, but it is on the way to a quiet exit. A lot of good developers, from artists to engineers to managers, left traditional console and PC dev to join the social/casual game revolution, only to be marginally employed today, and those that are left are making mobile games because social’s dying.

Microtransactions are profitable in the long term, but only in a larger game that has deep gameplay. Market speculation is trumping numbers and common sense. The result is sweeping change in our industry, after which we’ll all settle back to making engaging console and PC games. The casual/social market will return to where it should be, a respectable sub-area in its own right, but not making the news and not a major player.

What say you? Is this curmudgeon/grump right, or out in left field? Bonus points for excellent arguments, big words and marketing-speak like ‘cloud’ instead of ‘internet’.