Stop being the Useless Designer
Part 1: Excel & Formulas
A bit to the left, No a bit to the right. Mmmm maybe if we make it blue?
Let’s face it, there is nothing more annoying than being bossed about by someone who is useless.?
So here are three simple rules.
- Work with them in the trenches.
- Everyone in the trenches has to be useful.
- Supplement don’t Replace?
So acquire some “Hard Skills” fast and be useful. This is a multi-part post for some places to start developing those “Hard Skills”.?
Though I encourage you to jump into your own tunnels of exploration. I hope this is the first of a multi-part post focusing on various tools or hard skills for designers. Introducing a tool or skill, then getting you interested.
THE BEST PLACE TO START IS YOUR IN-HOUSE TOOLS!!!
The Mechanics of Convention
Our profession develops, we form conventions and a toolbox of useful solutions. These tools make us faster, and more efficient. Conventions are not only developer driven but player driven as we define the language of games. The real question is when to break convention?
Originally written for AltDevBlogaDay
Before you know the answer, you must know the Question
Define the problem clearly with all parties, locate the true source problem and eliminate symptoms. Do you want a sticky goo gun which sticks to walls; or do you want an indirect weapon?
The most common mistake with a convention is to blindly apply it, without knowing the problems its designed to solve. You need to delve past the symptoms into the root causes and motivations. For example what may seem like an issue with your jumping dynamics may actually be a visual feedback issue.
Study not only the present state but the history of a Convention
Every day more people more intelligent than you are pouring collective hours into solving the problem you have just started thinking about. The convention you so readily reach for, or dismiss, did not pop into existence fully formed but instead grew through the years of gaming history from title to title.
Seeing the path of development allows you to better understand the components that build the convention, and the parts which were thrown away. Often choices were made, limitations imposed or situation demanded and the path of development was altered. Sometimes a convention might not be the best fit for your game, or even a good starting point but an earlier version of the convention could be ideal building block or tool to use.
Invention is Expensive
The key benefit of a convention is its a known element, with known quantities. In many cases with known relationships to other conventions. The development time is predictable and many of the edge cases are known.
Implementing a convention in an environment will introduce some new edge cases and relationships but they will be tiny in scope when compared to a new invention.
A new invention or variation must be explored for all edge cases, establish relationships with all other elements of your project, and be iterated upon to reach a stable state.
If you do not have the budget to invent a new convention, don’t start. Find an existing convention that roughly fits and use that instead. A loose fitting convention will be ten times better than a half baked idea.
A little invention goes a long way, but too much will Alienate
While some conventions are entirely developer facing, such as coding conventions, many design conventions are outwards facing to the customer. If a player buys your game which has been marketed as a first person action shooter, there are certain conventions they expect.
Altering convention or surprising your player will often pleasantly and enhance their experience, but only if your solution is clearly superior. Though too many surprises will frustrate or alienate your player, even if your conventions are better than those previously established.
When to break Convention?
Every artistic endeavour must seek to achieve something new, or improve upon the old. The question of when to break convention is simple.
You should always break at least one established convention, though the less you break the more likely you are to succeed. Break too many and failure is assured, break none and success will never be yours.
The Hidden Evil of the Micro Transaction
The Hidden Evil of the Micro Transaction
Over the last year a lot of time has been spent thinking, writing and developing my thoughts on social gaming and by extension micro transactions. The last few months of my professional life have involved some fairly complex and sometimes scary monetisation designs and discussions. Moving from consoles to social web games has been an interesting path to walk, with many lessons to be learned.
Micro-transactions are not Evil!
I prefer the Yummies
The classic line from Hamlet, “for there is nothing either good or bad, but thinking makes it so” is the one which applies here. MTX is a valid business model which, when used correctly, can enhance a game experience and bring a product to a wider audience.
A key barrier to entry for so many people is breaking open their wallet. For this reason I love Facebook games, but also XBLA games. The trial mode enforced by Microsoft does not get enough credit for upholding really good accessibility and up-sell standards. It enforces the “try before you buy” on developers and does some really intelligent things.
That being said poor monetisation design or a mismatched business model can destroy a product. Some quick examples:
- ESports != Game Affecting Micro transactions
- Experimental MMO != Upfront Cost + High Sub Cost
- Awareness Raising Serious Game != Fixed Cost Model
Greed is NOT Good
Many, not all, business and marketing characters I’ve met are so focused on the bottom line they cannot see the product. Now in some cases, this is just greed but more often they are not gamers, they do not partake in the craft nor enjoy its fruits.
Some quick numbers and explanations for you.
| ARPPU | Average Revenue Per Paying User is measured on a per month basis. | It varies a lot and is one of the less visible numbers in the industry. |
| LTV | Lifetime Value of a User | Varies MASSIVELY |
| Engagement | DAU / MAU | 20% Average |
| DAU | Daily Active Users | Top 40 all above 7 million |
| MAU | Monthly Active Users | Top 40 all above 1 million |
| Conversion Ratio | Monthly Conversion rate of Players to Payers | 2% Average |
| Organic Traffic | Amount of Traffic you get that isn’t due to Ads, Purchased Traffic or Partnerships. | Hard number to pin down and the real value is often hidden behind marketing dollars. |
First thing that your money people are going to focus on are those numbers, especially the ARPPU. As a game designer your key metric should be the Engagement, Lifetime value and some of the softer metrics.
Instead of gobbling the raw ingredients like a lazy fat child, put in some work to cook up a feast. Take some risks, aspire to improve the game so people want to play it rather than feel compelled to play it. Drive up the engagement, word of mouth buzz and reduce the churn (loss of players). In short, take the long view.
Grey Areas are Green-lit by Greed
The problem with all this is this it is an ambiguous, grey area. The real kicker is that grey areas are always green-lit by greed. In the interest of a “little more”, so much wrong has been done. So many ideas ruined, communities broken, and teams overstretched by wanting that little bit more. The old sustainable farming arguments come into play here.
The massive problem is that you as the Games Designer or other development members do not always have the final say, but you can still fight your corner. You can build your arguments and try to provide some strong research and data to help your money people see the long term view.
The problem is this Green lighting of Grey areas doesn’t only hit the money people can filter into your team. Money is a great excuse to put your toe over the line.
Strong Vision Holder
The saving grace is if your company founder, CEO or similar authority is a strong vision holder. Failing that, you can have a hard-headed idiotic bitch of a lead designer in heels with a baseball bat and a South African sized chip on her shoulder or your local equivalent, who is willing to fight your corner.
The design and vision has to remain consistent, lines must be drawn and values upheld. From this position you can try to innovate and develop. It’s scary and frightening and there is no guarantee you will get it right. Trust, Integrity and Values can be sold if you’re starving. They can never be bought if you’re fat and wealthy.
Girl’s gotta Eat
So all this being said we aren’t making games for free and we need to eat. I’ve never met anyone in the trenches of game development who wasn’t filled with passion for their craft. I’ve got a whole other blog post to write about: compromise, tips on winning people over and facing the harsh realities.
At this point, however, I will just recommend this brilliant, fiery rant of awesome.
GDC 2011: No Freakin’ Respect! Social Game Developers Rant Back by Brenda Brathwaite
Along with this counter point argument
Redesigning Wild Ones into Playdom's Top Game: A Social Game Design Reboot by Joshua Dallman
We do it because we love our games, not the money… but a girl’s gotta eat.
Respecting Design
Originally written for #AltDevBlogADay
I’ve got a question: “Do you respect your designers?”
Growing up I always wanted to make games, and gravitated to programming as the means to achieve this. I entered the industry as a programmer and had a blast, though I found myself more and more attracted to this strange thing called, “Games Design”. Eventually I made the very tough personal decision to switch from a programming role to a design role.
So often hopeful “designers” choose it as a path because they can’t be a programmer or artist, and not because they respect or understand the profession.
Now I still code, and try to stay current as a programmer because I haven’t ruled out the possibility of switching back. The hardest thing for me to deal with was the lack of respect design has as a profession. Truly proving to your non-design peers your profession requires study, diligence and commitment is a tough nut to crack. So where is the source of the problem?
Given enough time and resource a bad designer can make a good design
Accidental design, or advancing a design through experimentation, requires very little design skill but a lot of resource. Most people can tell if A feels better than B once implemented, so given the ability to try both options they can compare and then make a choice.
Now this is horribly in-optimal but is the root of the problem in many ways. In most respected professions a vast amount of research, basis of knowledge or method of thinking is required to advance in professional grade problems.
As a designer I respect once put it, your job description is to “Achieve the most with the least”.
No one will ever tell a programmer how to code, but everyone will tell you how to design
Once a design is implemented and tangible, most people can see if A is better than B. Now because of the above factor and the fact most design problems can be explained easily to a laymen because communication is a key design skill, well it means everyone can stick their nose in. Including senior members of the company who should know better.
Honestly, the biggest problem the lack of respect causes is this high level of interference from every Tom, Dick and Harry.
In most high skill professions the execution is the simple part, it’s the diagnosis and formulation of a solution which is the hard part. Now most people could inject medicine with a syringe, finding a vein is not that hard, but knowing when or what to inject is tough. Likewise, the result of a complex design problem seems trivial, and once explained obvious to all involved.
It should be pointed out that artists have this problem to a lesser extent as well. The advantage is that an artist executes the idea without needing to communicate, while most times a designer needs to communicate the solution. So the execution is removed from the diagnosis and formulation, meaning that it can be separated easily and appears trivial.
Proving a good design premise is like trying to convince someone a song is good only with sheet music
That being said, trying to convince someone without design knowledge of a complex problem and solution without implementation is tough. Though the onerous to convince people is on us as designers. Sadly many bad designers, instead of solving this, use this as camouflage to hide their incompetence.
Now I don’t know the perfect solution, but I would suggest as an industry we need to learn sheet music and conventions by which we can discuss problems. A process that is already happening but slowly. The problem is many poor designers keep rallying against these conventions or building of hard theory basis.
They keep rallying against conventions and theory, expressing their “individuality” or “creativity” or some other fluffy concept as a defense. It’s because “bad” designers, “lazy” designers who are not willing to put in the work, find it easier to have things fluffy. This fog and lack of clarity is the shield they use to hide behind and we need to rally behind the hard theory and science to gain respect as a profession.
I’ve met more bad designers than I would care to admit, and I’ve only ever once worked with a designer I strongly respected.
Do you respect your designers?
It all comes back to this question. As a programmer I could see my development, and my peers could see it. I could advance my career and have a clear skill progression path. As a designer I often feel lost, and fear most my “value” is from the trust I’ve earned from colleagues and is non-transferable to a new company. I study hard, work hard and know I’m a better designer today than I was yesterday but I struggle to communicate or measure this development.
Finally my question for my fellow designers, “How do we build up design as a profession?”
A Kiss is always harder than a Kill
Originally written for #AltDevBlog: Link to Original Post
Games let us craft interactive systems in which we can play and explore. We play with limited rule-sets, physics, combat, squad based AI, and a million other complex systems which give us a world to explore. Why then is one of the core human experiences, our social nature, all but missing from games?
[Delete several paragraphs explaining where we are and why – assume audience knowledge]
Jump to Nuts & Bolts discussion.
It all boils down to the fact in many ways the dialogue tree system we are so comfortable with is a local maxima in evolution of social interactions and needs to be discarded to make progress.
Let’s take a brutal approach to a social interaction with a game agent. Now if we look at the three stages we can separate them nicely. Currently Inputs are stupidly simple, the game-pad offers the emotional range Morse code, no wonder the agent has trouble interacting. I’m less concerned here because of Kinetic and the brilliant academic research being conducted in this field.
Our outputs however are extremely high quality with amazing voice acting, great visuals and delivery in our high end products. Though the methods we use aren’t scalable, and impractical for dynamic systems. Again there is great research in text-to-speech, automated lip syncing and similar technologies. So great strides being made in this area, but it will be the most painful transition to make as early version of this technology just can’t compete with the pre-baked polished deliveries we have at our disposal.
While challenging I think both of those areas are moving forward at a good pace and will be solved in the near future.
Then we get down to the gritty problem of the agent itself and the formulation of a response. Something we are getting very good at for say tactical combat simulation, where the inputs are better and the outputs rule governed. The dialogue tree however is at the end of the day a static graph (path manipulation through skill rolls or simple scripting doesn’t count) which creates a dumb but effective reflex agent.
How can we grow this agent into a more intelligent system which allows for play and exploration? Can we make an agent who processes and develops an opinion of our actions rather than simply reacting to them by a cast iron static reflex system?
Now while research is going on in this area its super fluffy and long range and does not get as much funding, mostly due to past developments in academia (see AI Winter). One of the trickiest areas with an intelligent response is it requires some degree of knowledge, and knowledge representation is a damn tricky problem in the AI world.
Nuts & Bolts
The key point to the entire problem is that the agent in a game-world, unlike an agent trying to exist in “reality”, lives in a world where we know everything. Using this we can seed them with knowledge they require and a basic relationship network. Through this they can perceive and understand any event which is within the scope of the game world as we have provided them with a working knowledge base from which to understand it.
This will allow us to make advances faster than our “reality” counter parts with quicker results as we have limited the scope of the problem space. Game developers like to cheat 
. It would also help if for the short term if we allow ourselves to use clunky or unappealing input or output systems which would not be acceptable in a commercial product 
Now I know this all sounds very fluffy and I sound like a crazy newbie who has discovered neural nets for the first time and has a naïve grin ear to ear. Though I do acknowledge the scope of this problem and I know the way forward is solving a lot of smaller problems to construct the tools to solve the larger. My dissertation which focussed on building a query/response framework along with the concept of 2nd degree authorship was the umpteenth step for me but the 1st solid piece of results.
2nd Degree authorship had to be proven because I know that at the end of the day we do still want to write and construct narratives, rather than pure random simulation situations. I proved this with a fairly simple rule-based modifier system, one possible solution to procedural authorship of social interactions.
Another requirement is data model which was generic enough to be expanded without being reworked. Again I manage to propose a fairly simple atomic model which would work for several game systems.
Finally I looked at building a query response model which could hold context and remain fairly generic. My research mostly hit dead ends until I considered representing a conversation as a tree, which provides context and a query as a path through that tree with null nodes. Response then could be sub-trees. XPath nicely fitted to this concept and I’m quite happy with the flexibility of the resulting system.
The full details up to this point can be read in my dissertation here.
The next step is build a system in which agents can observe a self-contained play session, discuss it with a player entity or another agent and have a personality persists over multiple sessions. I had two possible planned prototypes to explore this concept. This is the thing I was struggling over for the last week.
The detective prototype was appealing due to its lack of what we will call secondary work (not directly pertaining to the research). In this scenario we would use 2nd degree authorship aided by some procedural systems to generate a crime scenario. The player would then interrogate several agents to try build a picture of the truth. The agents would of course have a personal partial vision of the situation and be manipulating their responses to remove the appearance of guilt.
This is an appealing prototype firmly built on my previous work with little need for secondary work. The two key concerns however were that it strongly depended on the strength of my generation algorithm and would therefore possible reach a dead-end or be handicapped if that system were inferior. It also caters to a fairly narrow spectrum of games, not having many traditional games systems interaction with the social model.
So the second prototype is a tactical turn based shooter. A game I’ve been throwing around for the last year or so, in which the world is persistent but the missions are throw-away and players build reputation. The idea is that the agents (in this case infiltrating squad members, or defence agents) can debrief their controller after the mission about the events. These agents would be persistent over the game world getting hired, fired and killed.
The main point here is the social information is mostly being scraped from a “live” game session in which one side (the defender) is not actually present. The downtime between missions however can be used to de-brief and casually talk about items. This means the game itself is not reliant on the social system, making it easier to have multiple versions, swap out or rewrite the social component without altering the game itself.
Also the persistent nature of the agents mean if I leave a server running long enough distinct social ecosystems should hopefully evolve.
Well that’s the plan; I’ll discuss more details in future posts and as the project advances. If you have any interest in this field or my research please do contact me I’m always looking for people to bounce ideas off and just share my crazy dream to cut-down the dialogue tree and burn its pitiful remains in the fires of progress.
Further ramblings on the matter are on my site, FlammablePenguins.com
Feedback in Production
Originally written for #AltDevBlogADay
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?
The Beauty of Restriction
When I first started to enjoy games on my C64 alongside the board games and role-playing games one thing was king, limitations of the medium. Shortly afterwards I learnt BASIC then C, and started making my own games some on paper, and I fell in love with the grid.
Now originally working in mostly text or simple 2D systems the grid was a joy, and the games were so great. Some of my favourite games, such as X-Com, were on the grid. The reason as a programmer I loved the grid is it made things simple. Collision detection, map editing, path-finding all was made simpler by the grid.
Then as I advanced as a programmer, learning new languages and then writing my own game engines. Learning about BSP, Object Models, Raycasting, Vistor patterns... and entering the industry, well I noticed a trend. More and more of my hobby projects in high-school and later were going unfinished mostly due to frustrating technical barriers.
Now I should mention recently in a professional capacity I’ve moved from a programmer role to a design role, though I still code in my free time and do not dismiss the option of flowing back and forth. Well my biggest hobby project over the last year has been “reset” several times. Recently I had a flash of inspiration.
So many of my unfinished projects were grid based (or using some similar arbitrary restriction) but were built on more advanced tech. The trend of technical hair pulling had started when I started using more my more sophisticated engines, in which these technical shortcuts of old like grids were actually MUCH MUCH harder to implement because they went against the grain of the renderer, physics or similar system. I was kidding myself about the technical benefit of these old style short-cuts.
Now if you had actually sat me down at any point and asked me, “Is a grid system optimal in a modern 3D engine” well obviously I would have said NO! So why did I keep pursuing the grid, and similar systems. The truth is love of the Design.
Now I won’t go into a rant about the awesomeness of the grid and its effect on game design, but let us just say it makes a much more interesting game design in many cases. This can be said for many technical limitations, at the time they were done because they were optimal but what many people don’t appreciate is they have value and facets of complexity to be explored. The closest parallels that come to mind are Monochrome Photography or Mosaic Tiles.
Now the lesson I learnt was, “Know the why before addressing the how”. In the example of the grid system once I acknowledge that the only reason I wanted it in-game was the game design benefit and not a technical one, well then my approach completely changed.
My object model became clear and clean without the mess of grids and my render graph all the sudden lost all its mess and clutter. Maps no longer need to be tile based but can be built with geometry in the style of grids and then a “game grid” can be generated offline using a series of collision objects. My lighting system could be broken into an abstract high-level effect and well let’s just say the hair pulling stopped.
It took me around 8 years to realise why I loved the things I loved. Strange but true.
Written for AltDevBlogADay
Design Cheat Codes
Disclaimer: I’m not claiming games which use these mechanics are in any way lesser. I’m merely highlighting these as easy ways to sauce up a game. Think of it like add ketchup / mayo / vinegar to your chips
Originally Posted on AltDevBlogADay
Working on several projects which have been technically limited, or constrained by some unbreakable conditions I’ve come to appreciate these quick and simple ways to sauce up your game. Note that not all sauces work with all games.
Make it Kinematic
Movement is fun, controlling a kinetic object is juicy. Give items in your game mass and direct control.
Compare these two situations.
- Player selects a unit, then selects a destination, then confirms selection. Unit then moves along path.
- Player directly controls unit with key controls
- Player controls the unit acceleration and the unit has mass and inertia
I guarantee if you prototype those three cases in a sandbox and give 10 people controllers then 3 will get the most play time, followed by 2 then 1. The simple truth is players like the feeling of weight and kineticism. A simpler real world example is give a child 3 objects: a light foam ball, a baseball and a jelly ball.
Secondary Motion
Do all player actions cause secondary actions? So menu buttons have not only a hover and click state but an animation or action. When the player jumps, shoots or activates something in game they cause an action, then ensure that secondary actions happen around that action. For example if a gun fires, get some smoke, or bullet trail. A jump can have a nice animation on the avatar, dust at push off and landing. The activation of a button can press in then light up, the simple act of separating these makes the player more satisfied.
Particles and Shaders
Yes we have all seen particles, bloom and cheap shader effects done to death, the reason? They work! Do you have a well balanced aesthetic in a gorgeous game? Then do not heap it on top, it will bury your work. But feeling bit lack lustre? Well then particles and a few cheap effects like rim lighting will help.
Physics
Does your game need physics, no? That’s great news you can use physics to add secondary motion and sparkles. You don’t need to worry about syncing it up over a network or worries about minor glitches because all it’s doing is making things look better.
Leaderboards & Awards
Will they make your game better, probably not? Will they mean player’s play longer or are more likely to make a purchase, challenge friends or talk about your game... YES!
Read this article here about implementing leaderboards (thanks to David Czarnecki).
Brighter Colours
Well yes we like shiny things. Unless you’re producing a high quality well polished art style well then going for brighter bold colours, with clean lines will almost always increase eyeballs to player conversion.
Also bright bold, friendly cartoon colours have the broadest reach and appeal.
Remove Options
Okay this one is not so much sauce as just general good advice. I’m adding it here because it’s easy to do and almost always helps. Make a list of all you features, options, abilities ect... Measure the usage in play tests. Remove the bottom third of the options. A simple thing, and it feels like your subtracting, which you are, but your adding value.
Local Multiplayer
Okay if you planned it from day 1 and are confident you can deliver online multiplayer, then do it. It’s a great option but it’s not something you add to a project as sauce. Local Multiplayer however has none of those headaches. Whether hot-seat, simultaneous or asynchronous its’ all good.
If your AI is flaxy or your balance is weak, well the meta-game that evolves from multiplayer can often save you from that.
Conclusion
These are just some of the cheap sauces you can add to a game which will spice it up. They are not a substitute for a quality product which is well designed. They are good trusted spices and sauces to spike the dish with. Don’t believe me; look at PopCap, Zynga, Mini-Clip and all the other casual games performing well.