simple SPU ray length counting trick that everyone probably already knew

Original Author: Jaymin Kessler

This is a very early variation of part of the PixelJunk Shooter 2 lighting system. It can process up to 16 pixels at a time, and you can easily unroll to do many rays at once.  The version shown does 4 pixels at a time for simplicity

 

Consider this a crappy port of an old blog entry to video. It almost feels like a badly narrated audiobook read by a voice actor that only kinda knows what he is saying. Nothing new or interesting, and with no useful explanatory animations to simplify things.  Enjoy 😉

 


Losing your Objectivity: A Survival Guide

Original Author: Pete Collier

Alice tumbling down the rabbit hole

Game development can become an increasingly tricky proposition as it progresses and losing objectivity is often the culprit. It is a hazard of the job that dogs us all. As with any labour of love we get tangled up in detail and can lose sight of the bigger picture. Retaining objectivity is important because it helps keep your game steered in the right direction.

One of the functions of a game director, or whoever is in overall creative control of the project, is to retain objectivity. The best achieve this by avoiding getting bogged down in detail and effectively delegating. The very best, in addition, have a handle of every detail but only with a view to how it contributes to the bigger picture. They have an ability to zoom in and out without getting stuck.

Whatever your breadth of influence on the project having a handle on how the details of your specific contribution add up is crucial to keeping objectivity. This is why being given a clear brief is effective because it help you ask the right questions in the context of the overall project. Part of remaining objective is the ability to ask questions of what you’re doing.

So what other things can you do to help prevent losing your objectivity? Here is my guide:

  • Talk to others about your work – explaining what you’re doing to another person forces you to approach it from an outside perspective and with a more conclusive eye. Another person is objectivity, so use it.
  • Leave your work and then come back to it – the further down the rabbit hole you’ve tumbled the longer you should leave it before returning. It’s a simple and classic strategy but one of the most effective. However it takes self-awareness to recognise that you’ve lapsed and fallen into crazy-land. Taking action can sometimes just mean having a cup of tea or in more serious cases a longer break, like a vacation. The amount of times I’ve come back to my work and muttered “What was I thinking?!” is plenty. Artists; how many times have you overly tweaked detail that no one will ever notice but you? Coders; overly engineered a piece of code for its intended purpose? You get the picture.
  • Know your goals – It’s hard to look at things with an objective eye without an objective! Pretty simple, but I’m sure, like me, you’ve seen your fair share of developers, or even entire teams, getting caught up in needless details and tangents because their objectives weren’t clear.
  • How is your contribution relevant? Without a sense of purpose we can all stray. Refuse to take on work until you’re absolutely clear why what you’re doing is important and how it fits into the bigger picture. You can’t be expected to remain objective without knowing this. This ties a lot into effectively motivating your team.

  • Be passionate about your work, but leave your emotions at the door – emotional attachment prevents objectification. Any Pimp will tell you that one for free. We all need to be able to cut our losses and get rid if something isn’t fulfilling its purpose. Being sentimental, emotional and overly attached can be your biggest enemy here. So grab a flamboyant hat and a lovely big fur coat and your fellow developers will know you mean business.

  • Present your work to the team – A more extreme version of talking to just one person; this can be a really useful exercise. Fear of talking to a large group of people forces you to consider your audience and demonstrate a very clear grasp of your work. Succinctly summarising your work is impossible to do without looking at things objectively. Just simply out of respect for your audience you’re perspective has to be a wider one.

On the flip side to all of this, it shouldn’t be condemned as a wholly negative thing to lose objectivity and get lost in your work. It is the natural tendency of a curious mind to go off and explore. It should just always be tempered with an awareness of your end goal. It’s a skill to recognise when you’re straying too far and to redirect yourself. It’s a matter of self-awareness and discipline to maintain a firm grasp of the bigger picture. Good luck keeping that grip!

What other methods do you employ in keeping your objectivity? Have you any examples of how badly things have gone when objectivity was lost? I’d love to hear them.

This article was originally posted on my blog: Losing your Objectivity: A Survival Guide


Feedback in Production

Original Author: Claire Blackshaw

As game developers we know the importance of Feedback in our games for players, but so often we forget the importance of feedback for ourselves. Implementing good feedback loops in your production cycle can be just as important.

Two stories highlight this for me. The first is personal, a team for a game I was working on was having the critical bug count communicated to them daily in scrums, and key issues pinned to the wall. The engagement with the lists was low, until one programmer asked for a graph. Since the coloured stack graph went up enjoyment is much higher and conversations happen around the graph (and supporting lists).

Edit: Found Source for this article“You Wouldn’t Like Me When I’m Angry” by Nick Waanders

In an article I read a programmer spoke about a game they were working on and the artists not paying attention to the frame rate. The number just didn’t matter to them. So he replaced the fps counter with a series of photos of his face: Happy, content, angry. The improvement was immediate, because the information was visual and the granularity reduced for clearer communication.

General Rule: For every role in the production cycle question what information is critical or a good performance indicator and try to expose feedback in the most appropriate format and make the feedback loop as short as possible.

Claire 🙂

Below are just some quick ideas and areas to try hit

Programmers

  • Compile or Pack times: The length of this feedback loop directly impacts the productivity of your team.
  • Code Reviews: Not only for quality of code but is the individual receiving adequate feedback on their work. A mentor system or pair programming system can help here, don’t try dump it all on your leads, they won’t have time. Resulting in a breakdown on the feedback loop.
  • Feedback on Failure: Are your error messages consistent throughout the business? Can you implement a dump system, or display a call-stack. In the case of failure are you providing the coder with enough quality information to solve the issue? In larger companies, does the error communicate which area of responsibility the error is occurring in?
  • Live Analytics: In the case of your programmers working on live systems do they have access to realtime easy to process visual data on player patterns, which functions are performance heavy or what areas of suffering above average load?

Artists

  • Immediate Preview: As an artist can I, without support from others, quickly view my assets in-game.
  • Assets Streaming: Can an artist update an asset without rebooting the game, removing the need to navigate menus and get to the point of the game where they can see the asset.
  • Performance Data: Do I get understandable visual feedback on texel to pixel ratio, overdraw density or other technical data in a fashion that is accessible to me?

Designers

  • Real-time Variables: Can a designer alter values in game on the fly to see how they feel?
  • Stats Data: Can I receive feedback from any play-through of the game done by QA, Focus Testers, or coders in the form of visual reports or recorded numbers?
  • Live Analytics: Do they have access to real-time easy to process visual data on player patterns, purchases of items, drop of rates and general user flow?
  • UI Heatmap: Can the game generate a heat-map of cursor flow?

QA

  • Build Dates: Can I quickly visual identify the build number and date?
  • Bug Feedback: When a bug is returned to QA am I provided with enough information to reassess the bug and is the communication clear?

Production Staff

  • Work Done: Does a report quickly identify work done and work remaining at present?
  • Visible Build: Can I access a recent working version of the game?
  • Time Spent: Can I identify areas of the work which have a higher than expected cost, or large investment in them.
  • Graphs: It sounds cliché, but a picture is worth a 1000 words. Live graphs prefably on a web system internally will make you life so much easier.
  • Team Time: Is there a frequent structured process for me to receive feedback from the team and provide them with feedback?

Board, CEO, VP, and other Stake Holders

  • Visible Progress: Am I able to see visible progress in an easy visual format?
  • Team Issues: Are HR items (such as sickness), morale, rework to content, areas of uncertainty communicated with progress reports?
  • Target visibility: Am I aware of the big goals for the next development target(s) and able to assign a confidence level to delivery?

A Quick rant on product keys

Original Author: Matt Dalby

I’m sick of typing in product keys using a console gamepad, sick to the back teeth of it. Fumbling about with some arcane consonant usage for five minutes, only to find you transposed a Q and a W in the first quintet of alpha numeric pain.

The now ubiquitous “online pass” means that when I sit down on my couch, excited about experiencing the newest, flashiest, shiniest piece of electronic entertainment that the world of game development has to offer I’m confronted with a wild text box, and it’s super effective at puncturing any sense of excitement! I would love to meet whoever designed the algorithm for product key generation. I’m convinced it’s a star trek fan trying to impose Klingon onto the unwitting masses. Either that or Cthulu.

So while walking home one afternoon, I happened to see an advertisement on a bus stop that was offering mobile phone users a free ringtone. All they had to do was take a photo of a small square barcode and then SMS it to the designated number.  “What a brilliant idea” I thought, and then it hit me.

Why don’t we use a similar system for product codes?

Imagine that instead of just having a product key, printed on the rear of the manual, there’s also a small QR (

Chaining Compute Shaders

Original Author: Nick Darnell

Bitchin-fast-3D-2000My new side-side project with DirectX 11 is something that has been bothering me for awhile.  Chaining compute shaders with variable length output.  Chaining compute shaders that output the same amount of work is trivial, in fact, you’d likely just merge the code into one uber compute shader.

One thing shader authors routinely take advantage of is the fact that they can do some simple work to filter out data points in the vertex shader by placing them outside the frustum.  Giving them a cheap and effective way to remove all that data that would otherwise go to the pixel shader or show up as a branch if this were all happening in a single shader.  By being able to have multiple stages the shader cores are all able to stay busy instead of several of them idling from a discard branch.

Which brings me to the main question of this blog post,

How can I chain compute shaders to consume variable amounts of data to duplicate this same staging capability?

So here is our scenario, you have a FilterComputeShader (FilterCS) and a HardWorkComputeShader (HardWorkCS).  The FilterCS will use the AppendStructuredBuffer to output some amount of data less than or equal to some incoming amount of data.  Now, you place one or more branch statements in your FilterCS that way by the time you get to the HardWorkCS you’ve got all your shader cores being utilized and no branching there (hopefully)

After appending some amount of data onto this buffer, how will we know how many threads or thread groups to spawn after the FilterCS runs?

ID3D11DeviceContext::CopyStructureCount

You can use it to copy the count from the buffer into some other buffer on the GPU.  Now you could then read back that value from the GPU and use it in another call to Dispatch, but forcing a sync point between the CPU and GPU isn’t a good idea.  Which is why there is this.

ID3D11DeviceContext::DispatchIndirect

You can pass that same buffer you just copied that size of the append buffer into as input into this function to subsequently spawn some number of thread groups.

For this to work, your compute shaders would all need to be defined with [numthreads(1, 1, 1)].  That way the number of threads matched the number of thread groups.

However, part of utilizing our shader cores effectively will be making sure we aren’t defining our compute shaders with [numthreads(1, 1, 1)].  Ideally the number of threads matches or is some multiple of the size of the GPU’s wavefront.  If you don’t do this you’ll be vastly underutilizing the GPU.

Crap…

So how do we get around this without adding a sync point between the CPU and the GPU?

Another compute shader! 😀

RWBuffer dispatchBuff : register(u0);
 
   
 
  [numthreads(1, 1, 1)]
 
  void UpdateIndirectDispatchBuffer()
 
  {
 
      dispatchBuff[0] = (uint)ceil(dispatchBuff[0] / NumThreadGroupSize);
 
  }

I know I said [numthreads(1, 1, 1)] was bad, but here it makes sense, we’re only going to spawn a single thread group and thread to do make this quick fixup to the buffer we’re going to use for DispatchIndrect so that instead of telling it the number of threads to dispatch, we tell it the number of thread groups to dispatch, based on the number of threads in our thread group for the x thread group dimension.

So now the code flow looks like this,

  • Dispatch(FilterCS);
  • CopyStructureCount():
  • Dispatch(UpdateIndirectDispatchBuffer);
  • DispatchIndirect(HardWorkCS);

I haven’t finished the side project this is part of so I don’t know if the overhead of using the AppendStructuredBuffer + 2 additional Dispatch calls is actually better than doing it all in a single compute shader with a branch.  My current assumption is that this method will be far superior in cases where you’re filtering.

If the branch were simply doing hard work X or hard work Y, there’s obviously no win.  But given the choice hard work X or no work.  Your best bet is to be able to handle each stage in a separate Dispatch, or so I think.  The performance results of the side project this is part of will probably make for a good post.

Chaining Compute Shaders @ nickdarnell.com


All the German I Know I Learned from the Demoscene

Original Author: Bob Koon

Demos are programs that encompass graphics, audio and coding techniques that display a short video in real-time. Generally speaking, everything you see is generated by the code (there are techniques used by some demos that have some elements re-rendered or regenerated and played-back, but by and large, they are considered real-time).

What makes demos so special, and part of the reason why I was enthralled by them when I first saw them on the Commodore 64 (many, many years ago), is that they are works of computer art and the heart and soul of programming efficiency.

They’re not just about programming though; the graphics and audio combine with the code to produce something (usually*) very inspiring. Indeed, it’s probably because of demos that I like goa and psy-trance music. (* I put usually in parenthesis because there are some (so-called “acid” and “kaos”) demos that to me are quite annoying.)

I think the main reason why I love demos is because they are a concentrated dose of inspiration. The graphics, music and the code combine together to make a production with a unique style and quality that really gets the creative juices flowing. Perhaps something you see in a demo triggers a thought or an idea that you might not of have thought of through traditional sources of inspiration.

However, because I am a programmer, I always go back to the code. There are demo parties in Europe such as here’s a list) that have competitions for the best demo. There are several categories for entries, mainly involving the program size, but there are other categories where size isn’t important. I’d like to focus on the size categories here though. Categories can be as high as 64KB, and even as small as 32 bytes.

This is where things get really interesting (especially for programmers). Imagine doing a program on modern machinery in just 4KB, that includes audio, and has something interesting to look at. Don’t think it can be done? Take a look at this:

Elevated by RGBA and TBC

and this one:

Michigan by Loonies

Pretty impressive, right? (Yes, the 4K includes the audio.)

Why I’m including this in a blog post that game developers read is not just about programming efficiency, though that is a big part of it. It’s more about what you can do with these techniques in your own games. In fact, many demo coders (and coding groups) go on to have careers in the game industry (you might have heard of a game called Little Big Planet).

A game that we did for iOS called Polyhedra (and Polyhedra XL for the iPad) uses a demo effect called “plasma” (just one of many) for the background on menu screens. The result is a sort-of psychedelic lava lamp. It’s all math so there’s very little impact on the bundle size, which is a reason why we used it. Here is a screenshot of what it looks like. (It looks much better in motion…see below.)

Source Code

If you want to see how some of these effects are programmed, a guy did his NYU final project on the subject and released the source code.

And a video of the effects (with great music) is here:

Here’s a really cool thing. A programmer wrote a demo effect (in just 224 bytes) by creating an image. 🙂 He included the source code in his blog post.

Jolt of Inspiration

Whenever I need a shot of inspiration, or just want to watch some really great productions, I look through demos. I invite you to do the same! If you want to see the most impressive ones first, look at all the winners from a demo party such as Breakpoint or The Assembly.

Here are some of my favorites:

Mental Hangover by Scoopex

Iconoclast by ASD

Masagin by Farbrausch & Neuro

Matamorphosis by ASD

Here’s a practical example of how you can put these nosebleed efficiency skills to good use. Check out this video from David Crane’s Pitfall postmortem he gave at GDC2011.

Links

Scene.org Awards
Scene.org
MacScene
Pouet.net
Demoparty.net
Bitfellas
PAiN diskmag

(thank you, McFunkypants!)

A trip to Berlin

Original Author: Francesco Carucci 

I’ve been teaching game programming at the University of Darmstadt for a couple years now: as they say, teaching something helps you clarifying it in your head. They also say that who can do something does it, who can’t teaches it Smile

Last week I called two “volunteers” as usual to write some code at the main computer in front of the rest of the class, gave them some freedom to choose a solution for a little problem we were having in our XNA game. The solution they came up with was good and, then, they generalized it, writing some more code, and then some more code, and then a little bit more code.

I asked why.

We might need it later

I replied.

So next weekend you want to go to Berlin, spring is finally coming, time to enjoy a bit of sun, it won’t last long here in Germany. You evaluate all the available options, you may take the train (even if they are so expensive here), or go by plane which is not much more expensive than the train and takes less time, or rent a car which would give more freedom but costs a bit more. You discuss it among yourselves for a while, weighing pros and cons against the cost of each option; the train will be around 200 euro per person, same as the a plane ticket, while renting a car would cost around 100 euro per day plus petrol. You finally choose and you buy a car for 5.000 euro. Why? You might need it later. Maybe you will like Berlin so much that you want to travel there every weekend, or you will need the car to go to Amsterdam instead, or even Or maybe you will not do anything like that, and you will spend ten times more now to go to Berlin than if you just hopped on a train…

 

here). In software we usually take the alternative route, we might need it later, we are willing to spend more now for something that more often than not we will not need later. We do it so often that we gave it a name: Over Engineering.

I believe that this peculiar behavior stems from the fact the cost associated to each line of code we write is not directly evident, it’s not money leaving our pockets. It’s also difficult to estimate precisely, which leads to the false perception that generalizing a solution will actually save time. It will not. Each line of code has a cost over time in terms of maintenance and added complexity, that is paid by the team day after day: if it doesn’t solve a problem that we have now, it’s a sunk cost. It requires a huge amount of experience to foresee that “we might need it later” is actually going to be true, and it also requires having gone through the same problem at least few times, which is not always the case in our Industry: we are on the bleeding edge of technology, uncharted territory, where things are complex by nature. Adding more complexity that is strictly needed is not going to help our cause.

Half jokingly with my students, I showed how they could solve the problem with half the number of lines of code, which will probably mean something like half the number of bugs at the end of the project if the idea is applied consistently.

You Aren’t Gonna Need It


Universal Undo, Copy and Paste

Original Author: Niklas Frykholm

(Crossposted to the BitSquid blog.)

Undo, Copy and Paste are the bane of any tools programmer. Especially when they are bolted on to an already existing program. But even when they are properly planned from the start, these small (but essential) features can consume a lot of development time and be the source of many bugs.

Wouldn’t it be nice if all that could be eliminated?

In an “inner platform”.

To quickly recap, here is the gist of the model:

  • The data consists of a set of objects-with-properties.
  • Each object is identified by a GUID.
  • Each property is identified by a string.
  • The property value can be null, a bool, a double, a vector3, a quaternion, a string, a data blob, a GUID or a set of GUIDs.
  • The data has a root object with GUID 0.

We need only five operations to manipulate data stored using this model:

create(guid)
creates the object with the specified GUID
destroy(guid)
destroys the object with the specified GUID
set_property(guid, key, value)
sets the specified property of the object to the value (set to nil to remove the property)
add_to_set(guid, key, item_guid)
adds the item to the GUID set property identified by the key
remove_from_set(guid, key, item_guid)
removes the item from the GUID set property identified by the key

The interesting thing about this model is that it is generic enough to represent almost any kind of data, yet restricted enough to make it possible to define and perform a variety of interesting operations on the data. For example, in the previous post we saw that it was possible to define a property-based merge operation on the data (which for content files is much more useful than the line-based merge used by most version control systems).

Other operations that are easy to perform on this data are:

  • referential integrity checks (check that all GUIDs used exist in the database)
  • checks for “dangling” objects
  • object replacement (replace all references to an object’s GUID with references to another object)

And, of course, the topic for the day: Undo, Copy and Paste.

Undo

To implement undo in this model, note that each of the five mutating operations we can perform on the data has a simple inverse:

Operation Inverse
create(guid) destroy(guid)
destroy(guid) create(guid)
set_property(guid, key, value) set_property(guid, key, old_value)
add_to_set(guid, key, item_guid) remove_from_set(guid, key, item_guid)
remove_from_set(guid, key, item_guid) add_to_set(guid, key, item_guid)

 

To implement Undo, all we have to do is to make sure that whenever the user performs one of the mutating operations, we save the corresponding inverse operation to a stack. To undo the latest action, we pop that last action from the stack and perform it. (We also save its inverse operation to a redo queue, so the user can redo it.)

Since the Undo operation is implemented on the low-level data model, all high-level programs that use it will automatically get “Undo” for free.

In the high level program you typically want to group together all the mutations that resulted from a single user action as one “undo item”, so the user can undo them with a single operation. You can do that by recording “restore points” in the undo stack whenever your program is idle. To undo an action, you undo all operations up to the last restore point.

Copy

To copy a set of objects, create a new database that holds just the copied objects. Copy the objects with their keys and values to the new database. Also copy all the objects they reference. (Use a set to remember the GUIDs of the objects you have already copied.)

In the root object of the new database, store the GUIDs of all the copied objects under some suitable key (for example: “copied-models”).

Then serialize the database copy to the clipboard (using your standard method for serialization).

Paste

To paste data, first unserialize it from the clipboard to a new temporary database. Then rename all the objects (give them new GUIDs) to make sure they don’t collide with existing objects.

Renaming is simple, just generate a new GUID for every object in the database. Use a dictionary to record the mapping from an object’s old GUID to the new GUID. Then, using that dictionary, translate all the references in the object properties from the old GUIDs to the new ones.

Finally, copy the objects from the temporary database to your main database.

Again, since Copy and Paste were implemented on the underlying data model and don’t depend on the high level data (what kind of objects you actually store) you get them for free in all programs that use the data model.


The race to the bottom

Original Author: Jake Simpson

Recently, Mr. Mike Capps – CEO of Epic Games, makers of the Unreal Engine and Gears of War franchise – mentioned in an interview with Industry gamers that “99 cent games will be the death of the industry”. – you can find that interview (brief though it is) here – http://www.industrygamers.com/news/epic-99-cent-apps-are-killing-us/

Now Mr. Capps brings up an interesting question. How, exactly, did we get to the point where large (ish) games are being sold for $0.99 on the appstore? How did this come about?

I think it’s a truism to say that LOTS of the games / apps on the app store are made by one or two man companies – people working on the side to develop something because at the scale of what the mobile community expects and wants, this is a possible thing to do. You *aren’t* building $60 games, thus you can both charge a lot less and the actual work and scope are a lot less.

So basically, at this point, the reason we see a lot of $0.99 games is because the developers are doing it in their spare time and don’t value their time enough. It’s got nothing to do with what the market will bear – the market will bear a lot more than $0.99 games, that’s for sure, just look at the Nintendo DS – but because that’s what a lot of people have set their pricing to be – to be enticing, undercut competition or whatever – that’s now what the market is set at. We made our own beds here, lets be clear.

But the practical effect of this has been very interesting. The ripple effect is now that you *cannot* price a game correctly according to scope and effort, because so many games are *not* priced that way (or you can and just not see anyone buy it). For Epic, this is a very real problem. Infinity Blade was created as basically a giant Advertisement for Unreal on the iphone. It’s very pretty, it’s quite fun but lets also not forget that I think it’s a safe assumption that it’s got over $250k’s worth of development time of assets in there. Assets of that quality don’t come cheap.

So while it’s a great ad for Unreal, it’s effectively a loss leader, even being charged out at $6 a pop (I say it’s a loss leader, however it’s probable it *did* make a profit simply because of novelty value. It looks nice, Epic is shouting about it and it makes people feel good about spending so much money on a phone because “look what it can do”. What I mean by loss leader is that if it didn’t make a profit then oh well – it doesn’t matter because it would be worth the expenditure based on new engine business this would bring in.).

However, what Epic is running into is the same scope problem that everyone else does on IOS – the fact is that people are buying Infinity Blade based on visual acuity / novelty, but it cost a metric arm load to produce. As has been said, assets of that quality are expensive to produce – and in a market of $0.99 game expectations, who can actually front the amount of money to produce those high quality assets given the absolute uncertainty of revenue from the appstore? While Epic can put marketing behind a game they release, can anyone else?

To put it another way, the risk for development using a high power engine that a) requires you to hand over 25% of your profits, past the first $50k on an app store where b) the median price of a game is $0.99 (thereby requiring you to sell a lot of them to make any kind of profit at all) and where c) the market is so saturated and hard to be seen in, that marketing will cost $ as well, is now so great that the Unreal offering really isn’t that attractive to most smaller developers.

Granted, you don’t have to spend so much time and $ on creating awesome looking assets, but if that’s the case, why bother with Unreal at all? If you aren’t going to use the tools they provide to create great looking content, why let Epic take 25% of your potential profits? Why not just go Unity instead, spend $1500 up front and be done with it? Or, better still, roll your own engine?

To actually use Unreal as it’s intended to be used – to create the stunning visuals that gamers are now coming to expect from Unreal powered games – requires a huge investment of time and potential earnings for a market that is simply too cheap and risky to support it.

From the perspective of the indie developer, Epic is, in fact, doing us all a bit of a disservice with games like Infinity Blade because all they are really doing is educating the game purchaser that you _should_ be getting assets and scope of the value and quality of their offerings at a $6 price point, while basically putting everyone else who does this for a hobby – who cannot produce this level of quality – out of the running. It’s basically “We have the money to make this AAA quality and can afford to sell it for $6, shame you can’t”. Except it isn’t, because, as they are finding, actually making a profit on that level of quality given the way the appstore pricing expectations have been set is extremely difficult.

The bottom line is that Epic is offering a AAA solution into a market that is ill equipped to handle it. Epic is right though, $0.99 does tend to handicap everyone on the app store, – unless you are the statistical anomaly that is Angry Birds, – and we need to bring that lowest price point up (unlikely as that realistically is). But what a $0.99 price point also does is make the running harder for Epic to license their engine even more than it damages individual developers which is why they are complaining about it.

So what do we do about it? I don’t really know, and I don’t even know if we should be doing anything about it – the price is set now and while as an indie developer I’d definitely like to see each indie earning more from their individual sales, I’m not sure I really want to do that just to make the market wealthy enough for Epic to swoop in and gather up all developers using their UDK and have them make money out of us. They do enough of that in the AAA console development arena:)

I suspect that the reason we see Unreal on IOS at all basically because some of the devs at Epic wanted to see if they could do it – which is a laudable thing. Now it’s there though I’m not sure I see much of a real business niche for it in mobile – I’m not sure I believe that there is a AAA market for mobile devices, at least in the quantities to make it cost efficient to produce large scale budgeted games that Unreal excels at.

Still, time will tell and Epic has a way of making things work for themselves.


Stuck in a childish routine

Original Author: Werner-Nemetz

Stuck in a childish routine

Looking back at several decades of gaming and comparing the industry and the games now to back in the day shows a big evolution. Technology has become very powerful, the industry itself became professional and there are games like Heavy Rain that target a mature audience. But interestingly for an industry that tries to be taken seriously people don’t always behave that way. The console manufacturers are on top of that list. Best example recently Sony commenting on the DS as “a great babysitting tool”. One could fill a book with all those comments that where ever made to make the other console look bad. Who doesn’t remember the Sega Saturn anti PlayStation commercial? For anybody who doesn`t remember that one here is it 🙂

 

How serious can you take an industry where the console manufacturers always come out on the stage in their fancy and expensive suits and than come up with those cheap shots against each other? It can not be avoided to make sometimes comments about your direct opponent, but the frequency and the way it was always done by the console manufacturers was something I always considered very childish. Clearly they are not going to say they love the other console, but if you go out and attack the others come up with constructive criticism and correct facts. Of all the companies those manufacturers should lead by example. The developers and publishers are doing a much better job there with companies doing only occasionally and infrequent similar comments.

 

That is a part where I feel the industry didn’t change a lot over the years, but where it should have changed. Instead it is stuck in the childish routine that is more reminiscence of school yard fights than representing a huge corporation. In the end for me it just makes them look less professional than how they should be and support those needles fanboy wars.