I’m just expunging that last of the Line World game ideas as I restart another project of mine. Hopefully somebody implements one of these ideas:
Stuntman Lives
A stuntman is fired from a cannon into the air, but needs your help to reach the final safety net where a pot of money awaits.
Goals:
- Reach safety net at far end
- Get money from violent collisions
Mechanics:
- Draw physics objects like walls, trampolines, fiery rings, pyramid of boxes, etc.
Stuntman moon shot
Goals:
- Get the stuntman high into the air
Mechanics:
- Draw physics objects like trampolines and springs to bounce the stuntman up.
- Use predictive drawing to guess where the stuntman will be in the next second or two.
Squish all humans!
Squish those pesky humans that stand in your glorious way to supreme rulation of the the universe. MUWAHAHA,
Goals:
- Crush all ragdoll humans in a city with giant dung ball
Mechanics:
- Draw physics objects like lines and springs to navigate ball towards humans
- Hit buildings to tumble them into humans
The fantastic death of stickdude
Depressed man, stickdude, wants to go out with a bang and in public!
Goals:
- Create the most elaborate death that involves blowing up cars, destroying buildings, and finally killing stickdude
Mechanics:
- Draw physics objects in a city. Stickdude starts at the top of a building.
The incredible light bulb screwer
Screw in a light bulb by building a contraption that does it using the most objects possible, but does not damage the bulb.
Goals:
- Screw in light bulb.
Mechanics:
- Draw/drop objects like levers, pulleys, cogs, chairs, balls, anvils, wheels, etc. into the world
- A fixed number of objects per challenge. i.e 10 then 20 then 30, etc.
Ladder of stuff
Stack random objects as high as possible – chairs, tables, balls, humans, cars, etc.
Goals:
- None. The sky is the limit.
Mechanics:
- Stack objects on top of each other.
- Objects are randomly chosen.
- Fallen objects start fire, so keep the ladder of stuff from burning up.
The Traveling Gnome
Help the floating gnome get home through the use of air currents.
Goals:
- Get the gnome home in front of his favourite lawn.
Mechanics:
- Draw wind currents.
- Drop objects to trigger rube goldberg devices that remove barriers like trees + walls + buildings.
- Drop objects on birds that dare attack.
Sledding (ala Line Rider)
Goals:
- None, just create the longest track .
Mechanics:
- Draw lines
- Drop sledder
Wrecking Ball
Goals:
- Smash boxes into the void (create most damage)
- Do it before the timer finishes
Mechanics:
- Draw ground lines
- Drop wrecking ball
As I demonstrated to my students the Box2d editor and the sample box stacking game, a few of them got addicted to the physics gameplay which led to me to think about fun vs. addiction.
In psychology, addiction can be “triggered” by rewarding the player at infrequent intervals. We’ve all experienced addiction in games. Games we played, not for enjoyment, but to “finish it.” In fact, I can list many console and DS titles like that. Fun + addictive is rare.
Mr. BigPants referred me to a one-button Flash game called Tower Bloxx that uses a variation of stacking mechanic (swinging crane, 3 box limitless realistic physics – overall more hardcore). It’s pretty slick and has a full progression system (you build a city). It’s dark chocolate while Peggle is crack cocaine.
So we know the box stacking mechanic can be addictive but does that make it fun? I’m not sure about that. We’ll need to dress up the pig with more than lipstick…
What can make it fun is getting rid of the “stacking high to reach a goal” mechanic and replace it with something deeper and more fulfilling to the player. i.e turn it into a puzzle…
Crayon Physics does this very well by letting you think up shapes to draw in order to reach the stars (goal objects).
There was also a toy block game that required you to build a specific structure using a collection of wooden pieces.
Puzzle Quest takes the match-3 mechanic and puts it into the context of a RPG. It’s pretty fun also.
The fantastic Bridge Builder allows for multiple solutions – some just insane.
Bridge Builder proves you don’t need fancy graphics and sound to have a fun + addictive game. Tower Bloxx went the route of covering up a weak game mechanic with fancy graphics and sounds. For casual game / portal market this is necessary, so I don’t blame them.
This mini-game spawned the Box2dEditor. A true game designer could “go to town” using the wrecking ball + physics game mechanic. The possibilities are endless. I just ran out of time + patience. It will be great learning material for students (hint, hint – mine) for sure.
Ever notice artists always doodling? They experiment and experiment and experiment… programmers read and read and read, but not too many go out and create something.
Well, I’m going to continue with my little 2D / physics experiments for a while and treat it like artists sketching – crap but a skill-building exercise.
A couple of things worry me about my current project. My characters have large number of polygons and a large number of bones…. added to the fact I have large scale environments.
Last time, I discussed the “people bottleneck” in the 3D pipeline (aka getting 3D art into the game). This is a MAJOR problem in the game development process. How does one get a level + character + animations into a game AND have everything interact properly? Well, let’s look at an example.
I have the following things in a 3D fighting game:
Office room
Door
Table
Two chairs
Policeman
Robber
I need to:
Model room, door, table, chairs
Model policeman + robber
Texture room, door, table, chairs
Texture policeman + robber
Light room, door, table, chairs with policeman + robber
Rig/weight policeman + robber
Animate policeman + robber
Name animation cycles and record metadata of animations (i.e stride length)
Build collision meshes for room, door, table, chairs
Build collision meshes for policeman + robber
Build pathfinding mesh (probably not need in this case – just go with me)
Add collision metadata properties like “wood” or “metal” to shaders or objects for use by sound code
Add collision metadata properties like density, friction, etc. for use by physics code
Add collision metadata properties like mud, concrete, quicksand, etc for use by game/AI code
Layout door, table, chairs + characters into the room
Add locators/triggers/bounds for use by game code
Export all the above into a format for the game engine
It would be utterly foolish to go into a production without any tools. Stupid, stupid, stupid.
A game engine is only half the battle. Art tools provide you with the rest, but even with the greatest tools getting art into the engine is problematic because of the sheer amount of data and complexity.
Better training and experience improves the end results. Sadly, many artists in the game business have less than 2 years experience and can’t be relied on understand all the complexities of exporter(nor should they). And in the future, this problem will get worse because of increased specialization and the enlargement of dev teams. Artists shouldn’t need to understand their entire exporting process either – why does animator need to know non-planar polygons are bad or that NURBS aren’t supported and that’s why his animations aren’t exporting?
So tools are not the answer to all our game development woes (but they are your friends – look at the friendly tools above. I worked on that show). They are a starting point…
How do we make game development smoother by reducing the bottleneck in getting art into a game?
The answer: Process (often called art pipeline or pipeline)
Programmers will hate me.
Artists will hate me.
Managers will hate me.
Producers will like me.
A process is NOT a MS Project schedule. That’s just a schedule. A process defines the workflow between artists, coders, art directors, lead programmers, etc. This is why I think SCRUM is getting popular in the game industry. The game industry doesn’t have well-defined processes in place so it compensates by having regular meetings and ad hoc processes.
The process :
Divide work into assignable chunks.
For each chunk find dependencies and create a dependency/workflow graph.
Insert approval checks between major chunks.
Design and write tools that export/process data between major chunks.
Assign chunks to people.
Simple, eh?
Let’s revisit our original example and start with just the room + props
Modeler #1 – Model room, door, table, chairs
Modeler #1 – posts models to webpage or common area for approval
Art director – approves or rejects room, door, table, chairs
Art director – makes comments on webpage/e-mail
Modeler #1 makes changes
Modeler #1 – posts models to webpage or common area for approval
Art director – approves or rejects room, door, table, chairs
Art director – makes comments on webpage/e-mail
Texture artist #1 – Texture room, door, table, chairs
Texture artist #1 – posts models with textures to webpage or common area for approval
Art director – approves or rejects room, door, table, chairs
Art director – makes comments on webpage/e-mail
Texture artist #1 makes changes
Texture artist #1 – posts models with textures to webpage or common area for approval
Art director – approves or rejects room, door, table, chairs
Modeler #1 – posts meshes to webpage or common area for approval
Lead TD or programmer accepts or rejects collision meshes
Lead TD or programmer – makes comments on webpage/e-mail
Modeler #1 – Build pathfinding mesh (probably not need in this case – just go with me)
Lead TD or programmer accepts or rejects pathfinding meshes
Now imagine there are 10 modelers. That’s a lot of communication (and models) flying back and forth. Many models will be in varying approval states…
i.e The door might be fully approved and just textured, but the table might be back at shape revisions. Do you really want a manager/producer/co-ordinator to babysit all of this? Every human in the process that isn’t doing the work is just another bottleneck and a potential for miscommunication.
Tools like exporters and previewers assist the process by reducing the workload of the art director and lead TD/programmer. 10 modelers verifying their work is MUCH BETTER than one art director trying to export the models himself/herself and then having to perform “art direction” duties also.
So tools are core to the game development process. We use them to:
1) Automate exporting art and metadata into a game (i.e exporters)
2) Facilitate communication (between mostly artists).
E-mail is TERRIBLE way to manage and track a production. Sure you could track art progress/progression in an Excel spreadsheet, but it won’t be usable by others (art directors + artists) simultaneously. I’ve tried the common webpage method and the Excel method. I think the Excel method is for small studios only. If a studio thinks they can manage a team of 20 using a single Excel file to track art progression – RUN!
So then the answer must be – “we’ll hire more associate producers and coordinators!” Unfortunately that’s a band-aid solution and a complete waste of resources. They are overhead. They don’t produce any content. They suck up budget. One producer, a couple of leads, and well-defined process is all is required in game development. Micro-managing content is a waste of time for everybody and the seed of miscommunication. The core problem is the shear of amount of data pass around to a small number of people – art directors, lead programmers, producers, etc.
If a process is mature enough, i.e Halo 7, then parts of it can be automated. Automation is the end goal. The fewer the number of people that need to be involved in creation of a single asset (i.e model) the fewer the errors. We all understand how error prone humans are.
What are the downsides of a process as demonstrated in my 3d fighting game?
As we tried to remove management by automating the process and setting up a common communication system, we created a little inflexibility into the system. To get a character changed would require repeating all previous approval steps. No longer can you just assign the work to a modeler and merely mark the entire thing as “done” when it comes back. Textures artists and lighters will probably need to look at the modified character briefly before approving it.
In real life, we have laws and bylaws on how humans should operate, but it’s up to the police and judges to enforce them. In our process we are defining how art progresses from an idea into a finished product in a game. Our enforcement is partially done by computer-based tools and partially by humans. Any time there is “an exception” that breaks our laws, tools need to give the exception a pass. A human can deal with exceptions, but poorly designed tools hate them. Tools should not be so rigid as to reject even the slightest of errors. Sometimes bad assets are usable… (like non-planar polygons) . The cost to fix the bad asset is not worth the reward. Tools should only flag problems, but not halt productions.
So why aren’t studios doing this? They ARE! At least the big ones with experience. Many of the job ads I’ve seen are for tool programmers and the salaries are quite high tool. And a few studios are hiring a small armies of pipeline engineers to assist in developing pipeline/process tools…
Too bad people will lump this game in with Brain Age – which it isn’t. Good marketing will be needed to overcome this ignorance. Actually, being associated with Brain Age wouldn’t be a bad thing, even though the game itself has completely different goals.
Congrats to MindHabits! I hope to see this on the shelf one day!
I revisited the box-stacking game today. I know I not a great game designer and it’s not for a lack of ideas. I lack that “perfect-gameplay-from-the-user’s-perspective” mode.
I can see how box stacking could be fun. Stacking a common game mechanic used in Jenga and McDonald birthday parties (remember those environment destroying Styrofoam boxes?!!). To make a game fun, it’s all about the HOW – the design and playbalancing / tuning aspect.
Here’s how I think box stacking can be “fun”:
1) Instead of random generating box sizes, I decided to create a predefined box list. There will always be a way to win and the path to winning won’t be horribly lopsided or next to impossible. With random box sizes, some games become trivial while others become frustrating.
Catan, a board game, uses dice. With dice, the number distribution resembles a bell curve but the game is highly dependent on chance. The game can also be very frustrating or incredibly easy depending on the dice rolls. Do I like this methodology? I’ll answer that by telling how often I play Catan on XBLA these days: ZERO. There is an option for “dice drawn from a list” that makes the game more fair and skill-based.
2) Skill-based progression. Even with 5 meager levels, I slowly increase the difficulty by raising the goal height and providing more boxes of slightly larger sizes. Regardless, stacking becomes more difficult, but is achievable with enough skill…. This brings about the debate: Chance vs. Skill.
Games like Blackjack are all about chance. The only proven method of beating blackjack is through card counting a fixed number of decks (no random shuffle). Certain games provide the ILLUSION of skill, but are mostly based on chance.
I don’t think video games should be based on chance… board games + card games can be due to their social / competitive nature. Video games are often played solo and need some skill element. What I don’t want is old-school retro pixel-accurate difficulty.
So is the box-stacking game any fun? Not really. The first level is challenging and provides a few sweaty palm moments, but after that it becomes REPETITIVE.
The repetitive nature of the gameplay is why I gave up Catan and still play Carcassonne which is deeper and more complex (multiple paths to wins). Another analogy is to compare Risk (basic gameplay) to Advance Wars (one of the greatest turn-based games). Risk is about chance and some skill…. roll some dice and choose continents wisely. It’s social. It’s easy to play. It’s a pretty stupid game.
Advance Wars is highly refined and requires deeper thought once past the first two levels. It would make a TERRIBLE board game as it’s too complicated for any sort of social pick up and play mode, but it makes for a FANTASTIC single player experience.
I do think physics-based gameplay provides a deeper single player experience than many other mechanics, but in the context of box stacking it is used incorrectly.
-- Box 2d Editor export by Casually Hardcore Games Inc.
local box2d = Musicala.Box2dManager:getSingletonPtr()
local world = box2d:getWorld(0)
local box = b2BoxDef()
local circle = b2CircleDef()
local poly = b2PolyDef()
local bd = b2BodyDef()
box = b2BoxDef()
box.extents:Set(2.5,5)
box.density = 0
box.friction = 0.2
box.restitution = 0
bd:AddShape(box)
