Design Document Discussion

I've asked John Passfield and David Hewitt for some feedback, and you should get a response from David soon. John's heaps busy with his stuff at 3 Blokes Studio, but he's interested in providing feedback in other projects in the future. David's the Creative Director from Tantalus, and I'm sure you would of seen him in a few of the videos in our media section. He's in about 3 or 4 of them.

I actually had an interview with David about a year ago, so I've met and know a bit about him.

It's great that he's casting his eye over my work, but I'm scared :P

Great!!

This gives me somthing to work with. I should be able to have a little prototype up in a couple of weeks.

One design issue I see is, What happens when a filling doesnt have a bun underneath it? ... The filling will be stuck on the grid forever.

The only thing I don't agree with are the hours of gameplay required. I think a level shouldn't take long to complete, around 10 minutes. Also the time taken to complete the 'story' mode should be well under 20 hours.

The bun problem is something I've thought about (but only after putting up the design doc) and can think of four ways to deal with it:
1. Just leave it, if the player is careless/unlucky, then it's their problem.
2. Have a "flame" across the bottom, that destroys gems that stay too long on the bottom.
3. Be able to make burgers horizontally, which doesn't totally solve the problem, but makes it easier
4. Have a row of bun gems on the bottom that automatically replenish when used.

I think either 1 or 4 might be the best. But with 4, the size of the well might have to be adjusted...

The timing was just a very quick idea. I'm sure that David will have some comments on that. Also, I think how long one game should be once can only really be judged once the basic game is playable.

I'd like to read the document. =D Would you happen to have it in ye old .doc or .txt format? =D

I'll convert it to the old .doc format right now ;)

Edit: It's up

*Has a quick sqizz through the doc.*

Well. A few points from myself.

1 - Some diagrams to compliment the writing of your document would go a long, long way. As a more visual person myself I'm trying to visualise in my mind how grids, gems and burgers mix to make a compelling game play experience. You can better communicate the concept of the game play by having pictures, diagrams and animations/videos to compliment your writing.

Better yet a mock up of what you think the game would look like. Dev studios do this all the time when pitching game ideas before they even have an engine. Did you know that Bioshock was green lighted on presenting a 1 min video render of an underground nazi bunker? :)

2 - Don't use works like 'could' 'might' 'I Imagine..'

The reason I say this is because you’re presenting this document to people as a reference of design and fact. Not speculation. When explaining things in these GGD use words like "Will" "The way it works..."

Write like you have confidence in your design. :)

3 - Bullet points are your friend! Remember readability and ease of communication are key for a game design doc.

For instance...

Currently:
SINGLE-PLAYER GAME DETAILS:
Each level is based on a franchise location. To progress through to the next location, a player will need to serve a certain amount of customers. To make it easy for the player, the customers don’t care what burger they get. I imagine there will be around 50 levels for the player to progress through.

The player starts out only with the bun, beef and cheese gems. After every 5 levels/locations, a new gem is introduced to the player. This obviously continues until all the gems are introduced, after 15 levels.

In bullet Point:
Single-Player Game Details:
- Each level is based on a franchise location.
- Completion of level is based on serving 'X' amount of customers. [X being the number of customers per level]
- Customers don't care what kind of burger they get.
- There are a total of 50 levels.
- Game starts with only 3 gems available to the player.
- A new gem is introduced every 5 levels until all gems are available.

Anyway dude. I hope that helps!

I generally agree with the 2nd point of Mr watts above, have no real qualms about the 3rd point, however I'd have to disagree with number 1. As an initial game proposal, throwing images in is inconsequential. Though you're right in saying dev studios mock up and provide images for their proposals, this is usually when they have a large team working on just a simply proposal to get the publishers approval. Words on a page will still go a long way currently, though I admit I'm not "a more visual person" and have a rather vivid imagination.

I'm not going to comment on the game mechanics or ideas, but like watts above I'll give some thoughts on what you've put down.
1) Some of the wording is not standard, and though that's fine, questions as headings can easily lead to confusion. Example: "What is the main focus?" I would have replaced with "Player Motivation" since the main focus could be construed from the view of a player in playing the game or the developer in making the game.
2) "What's different" should probably also make mention of some competition (or games with similar elements), if only to make the rest of the team more aware of both what the game may be comparable to and what they should not try to copy too much of at the same time.
3) "Design Goals" are something I've picked up as useful in early proposals. I use this heading to state a few key concepts that, no matter how much I might change the game from the initial proposal, I should keep throughout design and development. A design goal of this may be something like "Time-stressed puzzle" or "Childish and Cartoon-style".

I probably have other things to expand on, but this is v.01 and a GDD for a short casual game only. So far so good I would say though.

In follow up about Point 1.

From my experience in the game dev scene. Pictures and movies compliment presentations. You can definitely keep an audience attentive to your explanation of a game feature if you have visual presentations to back them up.

But as this is about the early stages of a game design document lets put that to the side.

As it stands with the current state of the document. While there's no need for videos or detailed concept art. I think what would really help reinforce the core gameplay concepts prose would be a simple 2D diagram that shows a visual representation of the grid and the gems that reside inside it. This could be something easily sketched up within a few minutes. This diagram builds a image that I as a reader don't need to conjure up. Which leaves my mind open to contemplate other aspects of the game design.

As designers we need to illustrate our points as clearly as possible because you'll have all sorts reading it. If my brain ends up visualising what's been written incorrectly then there's a problem. Effective writing is rightfully so No:1 but inserting other forms of communication where it's in logical context only helps to strengthen the design. :)

Thanks for the feedback, I've only ever done one full GDD before and that was as part of some study.
The only other GDD I've worked on was to do with some RPG systems and how they would work with an already designed and prototyped puzzle game.

Version 0.02 is going to be so awesome now ;)

Now that the demo is up we should concentrate on the key gameplay and try and make it as fun as possible.

My first issue with the gameplay is that the grid fills up too quickly. Completing a burger hardly slows down the rate that the grid fills. Perhaps designing some sort of reward/bonus/power-up system could help. An example of a reward might be converting the bottom row into buns ...

Note: I you can get the demo from the Burger Time Demo thread.

Alrighty. I gave the demo a go. Here are my musings. =D

- Small point: Being a grid based game it would great if, like in tetris the gems fall down per square row in a timed interval. This actually affects gameplay as it's a way for people to judge and time their movements on the grid. Additionally it’s visually jarring to have an object smoothly scroll down rows of a grid.

- Big point: I understand this is a bare-bones implementation of the game. But as an end-user playing it. I had no idea what to do. This is because of two reasons:

1: I don't know what the aim of the game is. For this early in the prototype stage all you need to do is have a screen before the game begins that tells me in words and/or pictures what this game is about and that I need to align gems to create a burger.

2: Now that I know the game rules. I didn't know what coloured blocks represent what gems/ingredients. What colour are the buns?

You can solve the second issue by placing a small diagram next to the puzzle that displays what colours represent what gems/ingredients. Also a diagram under it just showing show creating a burger works. Which needs to be no more complicated then showing two yellow gems and a few gems between them.

- Big point: About the gems themselves. From a glance it looks like your gems/ingredients are being randomly generated. And it's simply the case that the yellow/bun gem isn't appearing often enough to let the player clear the screen. As it's the core gem it needs to spawn more often then it is now.

If you're using random generation perhaps adding a higher percentage of yellow block generation chance will help this issue. Play around with this percentage as well. Experiment.

Additionally. Adding a few rules to your block generation will help out, like making sure there's never more then one yellow block per drop. [So it doesn't just despawn upon landing.] Other gems/ingredients are fine to double up on.

Hope you guys find this useful. :)

I like the prototype, it's given me some ideas for improvements to the design doc.

I agree to the movement being limited to the grid. The smooth falling seems to be wrong, I think this is mainly because other games of this type do it that way :P

Also, a guide to the gems to the right would be nice for now.

Lastly, having weighted options for each of the gems would be great.
That'll be one of the next things I write in to the design document, with some preliminary values.

^^ that's me.

The new version is on the Burger Time Demo thread. I've also updated my post with a bit of a description for each of the xml elements in the settings file.

Demo-003 changes:
+ added settings file (settings.xml). Now you can have a play around with different settings.
+ added gem weights (they can be modified from the settings file).
+ added the option to stop multiple bun gems from spawning (again modify from the settings file).

Next Release:
+ implement dropping by cell.
+ If someone sends me an image which acts as a guide for the player, I can throw that in. The image will stay on screen the entire game with dimensions 200x600 (the background should also be transparent).

I can do a simple guide to start with. Also, can you provide some specs for the artists to work with? What resolution would they need for background pics, title screen, gem icons etc?

That was a very quick response time. Well done on getting these changes done so fast!

Some new points:
[Although please note these are always directed at the team which includes the programmers, designers and artists. Additionally my feedback should be always reviewed by the project lead so he can evaluate the feedback.

In less words: Don't do what I point out unless the project lead wants it done.]

- ingredient build up. Now that buns are more abundant and I'm able to string burgers together I start to notice just how quickly the ingredients at the bottom build up. This issue needs an elegant design solution.

I would suggest that a way must be created that both clears the bottom but also effects the player adversely due to his sloppy job. take for example:

Timed ingredient burner:
Every 10 seconds [or more/less] the bottom row of gems are cleared from the grid via incineration. For every ingredient gem that's incinerated deducts 10 points [or other value] off the players score. Buns are exempt from both incineration and score deduction. This will lead to buns eventually falling to the bottom grid and staying there until a burger is made in that column. So while incineration clears rows of unusable ingredients and sifts bun gems to the bottom row it also penalises the players score.

- Implement scoring and a goal:
Now that you have editable values. It would do well to experiment with different weight combinations and seeing what works and what doesn't. [hint: ingredients that carry a bigger score should spawn less.] And getting a scoring system up and running will help you as well. Attaching a score based goal as well so as you're playing the game you have something to work towards. Once that goal is reached you can simply reset the demo.

It falls to everyone on the team to test the game as much as possible. get some solid weight and score values for the gems, burger combinations, possible score multipliers and a score based goal. :)

Cheers!

Again it's on the Burger Time Demo thread.

Demo-004
+ Added the option to drop per cell
+ Added options to remove old gems

I'll throw the descision for resolutions over to the designers and artists. At this stage it's a matter of what works/looks best. My 2 cents anyway is 800x600 running in a window (which is what is running in the demo). I don't know about gem sizes as it really depends on the screen layout and what grid dimensions works best. Since the gems are all going to be created as 3D models (?) it might be more important to determine the width to height ratio for a gem ( perhaps 2:1), as it will be simple to render them to any screen dimension we choose (?).

The scoring could be based on making the customer happy where a customer has a random set of requirements for their perfect burger based on none or more of following attributes:
- Order of the gems.
- Whether the burger has (or doesn't have) a particular gem.
- Size of the burger.
So some customers would be easy to please (they might even be happy with two bits of bread) and other would be more fussy.

I don't really like the gems being cleaned up on a time basis (they do need to be cleaned up somehow). Maybe cleaning up the bottom row could be given as a reward for making a particular burger or by using some sort of power-up gem (?).

Sorry guys, the executable from Demo-003 was in the Demo-004 zip. This has now been fixed.

Ok, I know Charcoal is dreading/looking forward to this, so here's some awesome and very constructive feedback from David Hewitt!

----

Sorry I didn't get back to you sooner, Souri! It's been a slightly crazy time around these parts lately!

In any case, here are some quick thoughts on the document (I hoped I'd have more time for this, but my dance card has become very full in anticipation of GDC next week):

The intro needs to start with an executive summary. Tell me what platform it's for, who the audience is, what the expected rating is, and so on. This can just be a quick table, but it needs to be there.

Page numbers and chapter/section numbering is a must when you're working with a team. A nit-pick, but it's important.

Use active voice and present tense, where possible. There's also no need to keep referring to the player in this context - we know they're present. "While the player is playing" is redundant, for example.

The "features" described aren't really features at all. They're marketing speak. "A new twist on proven puzzle gameplay" isn't something a programmer can implement, or something that can be put on a list of deliverables. This needs to be broken down into entities and mechanics that will actually appear in the game, and need to be built.

When describing the different gem types, a table would be easier and clearer, and a quick sketch wouldn't hurt, either.

This is obviously early days, and the doc is very lean, but I'd look to include some more detail on the scoring system, a representative 5-minute gameplay example, some sketches and layouts for the menu screens and HUD, some details about any particle effects and animations required, any pop-up messages that'll be needed, the unlocking or reward schedule, the difficulty progression and how it is implemented, the save data requirements, etc.

There seems to be no plans for a multiplayer component, so referring to "single-player" in the various game modes is redundant and potentially misleading.

The design needs to be expressed in specific, definite language. Features need to be built and then tested against the design. "I imagine there will be around 50 levels" and "The player wins by setting up a franchise on the moon" aren't helpful. Say "there will be 50 levels", if that's what you think. If it's wrong... change it later! If the player finishes the 50th level successfully, and then a cut-scene is displayed and the credits roll, say that. If the final few levels are set on the moon, and a different set of art assets will be required - this needs to be specified. Bear in mind that a first-pass design document is used to determine a feature list (i.e. some things the programmers need to make happen), an asset list (i.e. some things the artists need to build) and the project scope (i.e. how long it'll take the programmers and artists to do all the things you've described). You know this will change, but have a crack at it - it needs to be looked at and measured.

I'd also recommend writing the design in terms of user stories, effectively describing the various things that the player can do in the game, and how the game responds in each case. This provides a more specific, user-centric look at the game, which helps the reader visualise it, and also helps the programmers and artists implement what you've imagined. A feature doesn't exist until it's exposed to the player - a combo system requires pop-up messages, audio feedback and other niceties on top of the underlying maths. Designing features in a way that's descriptive of the end-user experience helps ensure that all these things work together. It also helps with testing - these user stories should be written in a way that can be easily verified. When I press the action button when next to this thing, does the described action take place?

As for the design itself (without yet having played the demo):

The first thing that leaps out is that the game's length and scope is out of control. What you're describing sounds like an old-school score attack game. I love those, but they only take an hour or two to play through. Do you want to play this game for 35 hours before reaching the end? Do you need to have a large number of different settings that are functionally identical?

If the game's about a high score, make it short and make it hard, and most of all make sure there's some depth and complexity to the scoring system itself. The player needs to be tempted to take risks in order to pay off big, but risks that could be costly if not executed properly. The very first thing I'd want to see in a game design of this sort is a breakdown of the player's thought process as it relates to the game mechanics - specifically in terms of risk/reward. Tap into the player's greed and their ego - when they do well, they need to feel great about it (how does the game pat the player on the back?) and when they lose, they need to ask themselves "why they heck did I get so greedy there?".

The game obviously has some influences (Burger Time, Puyo Puyo, Columns, Diner Dash, etc.) - I'd analyse these in the design. What makes them work? What's their scoring system? What's their risk/reward equation? Then discover what you're taking from them (there's nothing wrong with this - we're all standing on the shoulders of giants!), and why, and what you're changing, and why.

The different locations are mentioned repeatedly, but sound functionally identical. Why not mix up customer types/requests? Or the assembly grid layout? How about some picky vegetarian customers, or meat lovers who demand multiple beef? Don't add complexity for the sake of it, however - if the game's about a simple, linear scaling up of a timing/dexterity challenge, then don't fuss with the locations. Keep it simple.

The biggest issue, in my opinion, is that around the scoring and risk/reward system. Every good puzzle game has this at its core, and it needs to be designed - it doesn't just happen. Going for a four-row "tetris" clear? Oh oh, there's nothing but Z-blocks, and your pile of junk is mounting up. Setting up a 5-chain? Oh oh, the opponent's garbage blocks covered up the trigger square. Give the player a reason to make their situation progressively more precarious, in the hope of paying off with a big combo. They should feel courageous and awesome when it comes good, and foolish and greedy when it doesn't.

Now, after having had a (very quick) look at the demo:

I love the fact that this is being prototyped very simply like this. Getting the core of the game sorted out before working on the window-dressing is exactly the right thing to do.

The next thing to implement is the scoring system. If the game really is about scoring, then this needs to go in early, so you can see if you're generating the right risk-taking behaviour in the player.

What happens to non-bun gems that don't have a bun under them? Are they gone for good? Is there a way of getting rid of them? They're unavoidable, in the current system.

Think about allowing the player to make burgers horizontally and diagonally, maybe? I can't see how you'd generate combos in the current system. How does clearing some gems by making one burger cause another burger to be made? Or perhaps you might want to explore making double- or triple-width buns a source of combos. Or maybe grouping multiples of a single type together "creates" a bun gem somehow?

How about a "bad" gem that you need to deal with? Perhaps if you get three of them together you can clear them, but if they go into a burger, they make a customer sick? Just a thought.

Why 3 gems together? How would 2 work out?

Some of the burger-making rules are a little complex (can't be higher than X gems, can't have more than Y of each type) - these will need to be clearly and visually communicated to the player. I'd look to simplify here, or just loosen things up.

I think I'll leave it there for now - sorry for the stream-of-consciousness rant, but it's the best I can do at present, in the midst of a busy patch. Let me know if you'd like to talk in some more detail about anything I've said here - I'm looking forward to seeing this thing progress and mature.

Oh, and I'm making burgers for dinner! (Seriously!)

David Hewitt

Creative Director
Tantalus
www.tantalus.com.au

I've read David's comments and have been playing around with the prototype. The prototype only brought up many, many problems with my initial design.

So, I now have a short video of where I think the game go.

Any updates on the revised design document?

Anyone know where he's been? He's disappeared since the Dissecta event. I sent him an email last week and haven't received a reply.

I did meet him at the Dissecta event, but I haven't seen him since then.

I know he was dismayed that there didn't seem to be much activity here, but I doubt he quit since he still seemed quite encouraged by it all...

In general guys, don't die. If Charcoal does not rear his head in the next couple of weeks, go on another hiring spree. Don't let this get too inactive, else it might be more than Charcoal that leaves.

The only reason I haven't replied in this thread is because I haven't heard back form either Souri or Squashed bug.

Also, I emailed you on the same day I emailed Souri...

I didn't think I needed to respond to it, I was just checking to see where you were. In any case, at the moment we're still waiting on the revised design document, and Squashed Bug's input on the game changes.

We'd also need Squashed Bug to give us some specs on screen sizes so we can think about the gui, menus, and background art.

The video is looking a bit identical to bejeweled and puzzle quest. It's going to need some addition mechanic that sets it apart. Any ideas?

As for screen sizes, 800x600 windowed is as good as any. These dimensions can easily be changed if the design of screen layout requires somewthing different.

If we discuss a bit more about the new gameplay, I can throw together another prototype.

^^ Thats me. ^^

In my mind the difference is more of a focus on creating cascades/multiple gems matching at the same time.

Also ,we can add people that are ordering specific burgers.
And have a bonus for getting the right burger.

Then later on, if that isn't enough we can wrap a management meta game around it.
With effects on the burger making game.

I think it's better if we can tie down and prototype the basic match-3 game first, then start adding the fluff that will make it a great game.

I can build a basic match-3 prototype. Probably won't have time until sunday night to make a start on it. I'm not doing much next week, so I should have somthing running before next weekend.