Creating a game without a GDD

Howdy!

For about a month now I have been developing a game without a GDD. I have tried to write one, but I am just not a designer at heart. Is this bad practice? I mean, I have a vision of what I want, and I am working towards that, but will people take me seriously if I do not have a GDD?

Whenever I attempt to write a GDD, I just run out of things to say. Within the first page, I have described the games base mechanics and my vision for the game, and then I don't have much to talk about.

 

If you're working alone it's optional. I did write a GDD just so I don't forget things later. GDD is very important when working in a team though.
GDD is meant to pass the idea to others working on the project.

 

It may depend on what kind of game you're making also. If it's very simple or something you have done before, then you can get away without a GDD. If it is fairly complex I recommend some way of writing down your plan and a GDD is important. Even a basic checklist is better than nothing.

 

You have done a GDD. You have covered everything you feel you need to in 1 page, so it doesn't need to be any longer.

My background is as a game designer, and I have written some very long design documents. But several managers have said they are too short, yet they cannot find anything missing. The shorter a document is, the more likely someone will read it. A large part of the need for a design document is so that the entire team knows what needs doing and are working in the same direction towards the same target. If you are working on your own and do not need to share your vision, a GDD can be just a simple series of checklists.

 

It may depend on the game, but this sounds like you're running straight for a brick wall.

There isn't a game in this world that can be designed in one page (maybe Pong... maybe).

I've written dozens of design docs in my time, and while writing the details (that others may consider insignificant) every time, without fail, I have run into questions that I didn't have answers for.

The GDD is the first step in discovering these issues. The prototype is the second step.

If you think you've covered every detail of the game, you're most likely wrong. And halfway through coding this beast, you'll discover a situation you hadn't considered and you'll most likely have to backtrack over months of work to account for it.

 

If you are not in a team you don't need it. At least not formally. The idea behind it should be covered by something else, always. Either in your head, which is probably not the best solution. But I find it sufficient to write down a plan, what to create and where I wanna go. Also to measure progress but mainly to see if everything fits together and that I have thought about all major issues (technical) that may arise. YOu don't want to redesign from scratch when you find out at the end that something doesn't fit.

 

If you think you've covered every detail of the game in the GDD, you're most likely wrong. A GDD can be very useful, but if you someone (such as the original poster) who is struggling with creating one, then it may be better to just get stuck into making the game. A GDD will uncover details if you know what you are doing, but it can be more of a hindrance than a help if you are not comfortable making one.

I'm used to making a GDD up front on big projects, but I find when working on my own in Unity, I work best by creating a prototype with the basic game mechanics first, then look to document how I am going to structure the game.

 

Thanks for the input guys.

I've been working on this game for a month now, and I am working alone.

I guess I will attempt again to write a GDD.

 

Sometimes you just have to be in the right state of mind to sit down and make a GDD. Relax and ponder.

 

Don't try to write a GDD. Write a series of DD for the game, and then compile them into the GDD. Character DD, Story DD, World DD, etc, etc, etc. For some people, the GDD looms too large. It can be a big project, they can feel anxiety in writing it, and it's not long before the focus becomes the GDD rather than the game itself.

Yes, working on the parts individually can mean that there will be conflict as you go to compile/complete the GDD itself. Personally though, I'd rather have that conflict as I am putting the GDD together later than have it stall me during a linear process. Likewise, if I'm unsure about an aspect of a particular DD - I'll put it aside and come back to it later. I'll work on another DD. Again, it's about not wanting to find myself stalled on some linear process.

If you have a conflict between the Character, the Controls, and the World as you're compiling the GDD - you've still got the rest of the documents; it's not a case that you reached that point and stalled...never reaching the other info or reaching it in a diminished form because of stalling. It can be tiring, even boring, to work on a GDD. You do not want that to sap your strength or resolve.

I also find that having those pieces and putting them together, working as if you were doing a jigsaw puzzle, helps you recognize what's missing better than if you try to do it all from the start. One of those, oh snap - how'd I forget that? Well, it just did not seem as important when you started out. I believe you'd rather find things are missing while duct taping the GDD together than after you've started development.

Because, keep in mind - it's just you. You're not going to lunch with the guys and bouncing ideas around. There's nobody else around to have an epiphany - it's just you. There's nobody else to slap there forehead at how stupid something is...it's just you.

The process for putting together a GDD for an individual cannot be the same as putting together one for a team...because the process simply is not the same. If you're trying to write it as if there is a group, a lead that has greater say, feedback from different technology teams, and all the other folks commonly involved in a project...and it's just you - well, I wish you luck. I prefer taking an approach that's more customized to my being a team of one and knowing how I work. It's similar to any project that I'm working on - whether I'm writing fiction, throwing together an audio track, or developing software.

 

I think if your working by yourself you might not need it. But if you cant fill 1 page how much of a game will you really have. With a document you can save yourself alot of time if you can write it out, you might be able to kill a bad idea before spending weeks prototyping it, the worst thing you can ever do is go half cocked on a half baked "concept" that sounds good but when you really think about it and flesh out the game it doesnt work.

 

That's a good idea

I will try this then.

 

What's the most likely things to occur?

1) You run out of enthusiasm.
2) The project gets too large.
3) You need X, Y X but fail to achieve it. [E.g. voice actor, license etc.]

So what'd put in a GDD is really quite simple:

[Basic details]
[Scope]
[Needed resources]

Now, I know that's a crappy GDD - and I missed out on a TON of important stuff - but I actually sat down and wrote that in 5 mins, and now have a *general* idea of how this project is going to work. I've got a 4 week target, I have to get my movement and weapons working, I can't waste time on Chat, MMO, multiple ships. While I want an artist, I know how to release my game on time if I can't get a reliable one etc. In 5 mins I've already saved myself dozens of hours and drastically increased my chances of success.

Now I'd spend a week or two fleshing that out in my spare time while I do others things [particularly R&D - so I know what I'm doing when I get to it]. Given that it's a small prototype and I'm working alone I don't want to make to too big or specific, but I do want to flesh out the general feel of it. Maybe draw some maps, whip up some storyboards [EXTREMELY USEFUL], work on a story/backstory etc.

 

My problem isn't that I don't have ideas, I have tons of ideas, and I know that I can implement them. For me, it's just the organization of the GDD. I don't want to talk about the server hosting where I talk about the character. I have organization problems.

 

I've started working on a GDD for my game here. While I am working on it, it would be great if people could offer criticism. This link should update every time I make a change to it. Currently, I have only written the Brief Overview section. Please let me know what you think.

https://docs.google.com/document/d/15BqVO9_Zlu14SwGo93wk5ab521A0ACHHVFpuKWKxBCg/edit

And that's about where I get up to. What do I talk about next? The characters? The leaderboards? The zombies?

 

That's something that I forget to do at times. I'll focus on what I'm going to include - but inevitably during development, feature creep sets in and something I should have known I shouldn't have included causes setbacks...meh.

 

Download this template.

It covers a lot of the areas you'll want to think about. Just go through it and fill your game into it.

 

I've taken a look at that before, and it seemed to help a bit. Right now I am using a GDD of a tutorial from digital tutors as a template.

 

This is a really good book on all aspects of game design. Humorous, not preachy, but chock full of creative juice. Sometimes a good read can jar loose stuff in your noggin...
http://www.amazon.com/dp/047068867X...&hvpone=&hvptwo=&hvqmt=&ref=asc_df_047068867X

 

Thanks!

I will see about purchasing this

 

Write a document if it will gain you something. If you are having trouble conveying your ideas to other people it might be useful. If you have a large team its probably useful. If you find you don't have a clear direction it might be useful. But it is NOT required.

From Super Meat Boy postmortem on Gamasutra:

"Super Meat Boy is Super Mario Bros. if Tommy and I made it. If we had made a design doc, it would have been as simple as that."

From interview with the creator of Braid in XBOX Magazine:

"Okay, I'm not walking in with a design doc and making it happen. I'm walking in with some initial ideas and I'm doing enough programming to make those ideas happen, but then I'm using the ideas to explore the space that's possible."

From Notch about Minecraft:

"I've got a few plans and visions, but my only true design decision is to keep it fun and accessible. There's no design doc, but there are two lists; one for bugs, and one for features I want to add but think I might forget."

Just a couple of examples from three very successful Indie games. That's five minutes of googling in which 3 of the first 4 games I checked (the other was Limbo) didn't have a design doc.

 

The stuff I do commercially has design and/or requirements docs, but that's due to commercial requirements. Customers need to understand what they're getting or what the solution you're selling will solve.

For my games, on the other hand, there's no design doc. My small team and I don't need one in order to keep a strong vision and direction, so we don't have one. But we're not a good example, because we haven't made any kind of public release yet, so there's no reason to take our word that our approach is working.

A better example is a group of my friends who just released a game (Animal Dash on iTunes - it rules). The team started as one artist with some character models and mock screenies made in 3DS Max. Those were good enough to get two programmers and an animator excited enough to get on board, and those along with the lead artist's head were all that were used. Aside from the obvious "running game" mechanic, pickups, caged animals and the visual style the mock screenies really didn't show much, but everything else was settled upon by the team as a whole experimenting and allowing the lead to make final decisions about what was and wasn't working. For a simple game with an experienced team that organic approach worked wonders.

 

Actually what I take from this is dont bit off more then you can chew . A small scale game you get done in 3 months feels far better then a game that takes 2 years( that you never even complete . )

 

Thanks for the info.

I think i will go ahead and make a design doc for this game, just to help convey the vision to other people, if I want to get some people on board later on. Does anybody have anything to say about my Work In Progress GDD?

https://docs.google.com/document/d/15BqVO9_Zlu14SwGo93wk5ab521A0ACHHVFpuKWKxBCg/edit

 

I was reading something on that link and I came across this:

Really? God of war had a scene where you have sex and all kinds of prolonged nudity and was only rated M, nobody took that off the shelves. OT I know, but I'm currently writing a GDD and one of the features is that you can cause this rich snob noblewoman to become a nude dancer in a tavern after you destroy her status. Oh well, I'll be selling digitally, people will find a way to get my game even if steam won't carry it.

 

Failure to plan, is planing to fail.

 

If you're planning to fail, you're planning so you are not failing to plan so you are not planning to fail, but then you're not planning AGAHAHHH!!!!!

 

There's a common misconception that all games require a formal design approach. This is not true.

Documentation serves one purpose, and one purpose only: to communicate your thoughts to others. If you're working alone, and can keep the entire project in your head—or even just make it up as you go along—that's fine.

Let me repeat that: if you're not working with other people, you do NOT need to write documentation for those non-existent people!

Premature documentation is a waste of time.

This is not to say that it's a bad idea to keep notes, a to-do list, or some other organisational or project management tool, but such tools are not substitutes for a full-blown Game Design Document anyway.

However...

If you plan on working on your game with other people, it is sensible to write down enough about your vision for the game so that those other people can all understand what it is you're trying to do.

A crucial factor here is that, if you're working with a team, your documentation should NOT dictate to individual members of that team exactly what they are expected to do. You can provide a list of assets, such as "A space-station; some spaceships; character models" and so on, but it's your artist's job to work out how they'll actually do their job. You wouldn't expect a programmer to dictate how a musician should play his guitar.

In fact, any non-trivial GDD is going to be a collection of technical documents written by multiple contributors. Your job, as the Keeper Of The Flame™ is to provide the overall vision—like a movie director—and leave the thrashing out of the details to those who have the necessary qualifications. This is what a team is for.

So, if you're working alone, you do NOT need a full-blown GDD. A single page synopsis can easily suffice. "A top-down zombie shooter" is more than sufficient. You can sketch out some level ideas, set-pieces, and perhaps an overall visual style, but you shouldn't feel the need to nail everything down to the last pixel.

Iterative design is a perfectly valid approach if your design style is more playful and experimental. It's basically an R&D method: researching what works and what doesn't, and expanding on those ideas that do work to create something fun. Most 8-bit and 16-bit games were designed like this: just throwing a bunch of ideas around and seeing what sticks.

Most people have creative ideas running through their head all the time. For me, I know when it's good, because I'll suddenly see all the details filling themselves in right before my mind's eye. When I get that "everything falling into place" result, I can just write it down. (I'm primarily a writer by trade. I haven't done much game design work professionally in over 10 years. But the same principles apply.)

*

Helmut von Moltke the Elder's views on strategy apply very well to complex projects like games: his most famous (mis)quote is, "No plan ever survives contact with the enemy." Strictly speaking, this isn't an accurate translation of what he said. His point was that, although you can plan how you begin a campaign to a pretty high level, your options after the campaign begins are almost entirely dependent on the quality of your intelligence (in both senses of the word) and strategic skills. You may have thousands of variables to keep track of, and any one of them can make a formal battle plan worthless. Instead, he von Moltke advocated training officers in revising, and even replacing, battle plans in response to those variables, making them prepare for as many eventualities as possible. I.e. instead of carrying one plan into battle and trying to implement it, you train yourself to be able to switch plans as conditions dictate. (Most people get completely the wrong idea from that mangled quotation: they believe you cannot, or should not, plan at all.)

The same logic applies to Project Management of complex projects. A simple construction job might only have a few variables, but a highly complex project may have thousands of variables that you'll need to keep an eye on and react to. Game design and development is an almost textbook definition of a complex project. The bigger and more complicated your game is, the bigger and more complicated its development process will be, and the more skilled you will need to become in managing the project, and in rallying and commanding your troops of developers.


But if it's just you, in a room, hunched over a single laptop, you don't need to explain your strategies to anyone other than yourself. So don't waste time on things that aren't helping you reach your goal. Work on the game.

 

@stimarco I agree with everything you said under the condition we are talking about something simple like a top down zombie shooter. If however somebody else is making something complex, a GDD is important even if it's a solo project as you cannot expect somebody to manage thousands of concepts in their head and any coherent manner. Also, when under planning is such a common issue with so many developers, I hardly think it's useful to discourage any kind of planning.

 

Even with a simple top down zombie shooter... it would not take long before I would consider a GDD. Hell, I'd still probably start with one - I just can't picture not doing one.

If I was just doing a single "level" where the "hero" shot at zombies...perhaps not. I can't see myself doing that though. There would be multiple levels, there would be different kinds of zombies, I would have the art and audio, there would be some kind of story, etc, etc, etc... Am I going to have different kinds of weapons? Will there be knockback? Will there be a penalty for using certain weapons at close range? How will I handle switching weapons? Bam, bam, bam... yeah, I'd better do a GDD to cover everything that's going to come up even in what I would consider to be a simple zombie shooter.

Not every aspect of the GDD's going to require a comfortable chair and a stiff drink to get through - but there are so many things to take into consideration, I'm going to want to know where I'm going - I'm going to want to have a plan for it.

How does the player win? How does the player lose?

Does the player have multiple lives? If they die, do they automatically respawn or do they click to respawn? Do they respawn in place? Do they respawn at a respawn point? Does it reload the level? Do they lose any gear?

I...I just can't picture not doing a GDD, even for a simple game - because even a simple game's going to have enough for a GDD imo.

Even if it's a case of saying what you're not going to do, you're still going to have that so you can refer back to it during the time you're working on it...

 

This.

Also, never forget that a GDD is nothing but a tool to help you or your team remember what should be in your game. Yes there are templates and norms as to what a 'good' GDD is, but that's just templates and norms. The act of documenting in a manner that's convenient to you or your team is what truly matters.

For one person you don't need to be anywhere as formal as with a team. It can be as simple as a big to do list or putting your ideas down into words. This exercice will help you a lot because thoughts floating around in your head are changing all the time and vulnerable to mood swings. Once you write them down they have more substance and this alone will give you something critical to achieve your idea: a solid direction to follow.

Examples of a one-person GDD:
- To do list as a text or spreadsheet
- Blog or forum (this one immediately lets you test your ideas to potential players as well as get feedback and motivation. I highly recomend it.)

 

Yeah, I am making a GDD because I plan on getting people to help me out with the game at some point in the future. I'm just not a writer by trade so it's a bit difficult for me.

 

This might seem like it's coming out of left field, but have you considered any of the following options:

Something like Dragon Naturally Speaking? You can sit back and talk about your game, rather than stare at the screen and have to type about it. You could talk about it as if you were explaining it to somebody else...the different parts, etc - and bam...you'd have a chunk of that info you would have thrown together in a GDD.

Perhaps something similar with a digital voice recorder or even a microcassette recorder. I'll hit the voice recorder on my phone when I have an idea or a thought on something and no way to write it down.

Similarly, even doing something like a personal video blog - where you're either talking to a camcorder or into a webcam and recording it on your computer. A way for you to talk about your game - get it down in some way - so it's more than just a bunch of ideas/concepts floating around in your mind that you hope you'll remember as you're working on the project...

...heh, personally I wouldn't go near the video aspect. I'd feel too silly going back and watching how excited I'd probably look talking about the most ridiculous things...lol.

 

I remember reading in one of the 'Game Design Secrets of the Sages' books from about 1999 or 2000 or so. They have interviews with famous game designers and I remember a quote from one of them talking about them not needing a design doc for their highly anticipated upcoming game Duke Nukem Forever.

 

Unfortunately, they did have a series of developer documents for the game. In many cases, the excerpts of the docs were better than the game...meh.

 

The whole story of the development of that game is more entertaining than most games.

 

If you're working alone, or with 1 or 2 close partners, you don't need a formal GDD. It helps to have one, but you don't absolutely need it.

What you do need though, is a clear vision of where you want to take your game.

What I've found works best for small teams is actually to just write up a to-do list full of all the items you know you need to complete the project. You can add and remove things as you go, but having the list not only helps keep you on track, but it also lets you see how far you've come as you cross things off.

It also really helps if your to-do list system has a way for you to write notes about what each item is for. Some things are self-explanatory, and others can be confusing - you don't have to explain everything. Even if you just use sticky notes, you can put the title at the top and write a short description below - this also has the added benefit of getting to rip up the note when you've completed it =-D

 

Hmm... I have to strongly disagree with the idea that a to-do list is the same as any kind of design.

Designing is ultimately about decision making, where to-do lists are ultimately about performing tasks. A to-do list can be derived from a design, but a to-do list itself is not design documentation.

 

An Angrypenguin...I was going to be Angrywaffle.

If you don't have a crew and you feel you have to write something then do a to do list. Short, simple, to the point. Even if you have a crew and it's not a big ass RPG, you can still get by with a to do list.

I have so many ideas in my head for like 40 games that if I started writing GDDs I might be dead before I get the first one finished. Plus I still have to finish learning the Unity system before I can even start...might help.

 

If you were to put those 40 games down on paper, you might find that you do not have 40 games - you have the features needed to put out several good games. While they're just floating around as ideas though, they're not really doing anything.

Somebody linked the Baldwin template in this thread - even if you just do a quick pass with that of those 40 ideas, you might find that some look better on paper than before - some just do not work - yet, part of the idea might work...

GDDs are living documents. Give them some life... plant that seed on paper... nurture it. Don't let it get displaced because you laughed too hard at something Sheldon did....

 

I wasn't discouraging any kind of planning. Merely pointing out that different circumstances mean different requirements.

ZeroByteDNA says:

I have absolutely no problem holding complex ideas and concepts in my head, so a GDD for a simple top-down shooter wouldn't be overkill for me unless I was planning to hire other people to help me make it.

This isn't because I have a natural talent. It's because I was designing and programming games as far back as the early 1980s. Do anything often enough and it will eventually move out of your conscious mind and into your subconscious. By the late '80s, I could bash out a complete 2D game engine in assembly language entirely on autopilot.

I've also been a writer for so long that I don't write consciously at all any more. It usually streams directly out of my subconscious, through my fingers and onto the screen without touching the sides. My conscious self is just an editor, reading what my subconscious is typing as it comes out, and doing the odd bit of proofreading and editing.

On the other hand, I pretty much suck at art and animation now. I stopped doing graphics for games professionally in 1994 and have been mostly doing graphic design since then. About all I can do now is old-school 2D pixel art. Sit me in front of a 3D modelling package and I'll run screaming from the room.

If you find a GDD helpful even for small games, there's nothing wrong with that. But, if you're working on your own, there's also nothing wrong with covering a wall with Post-IT notes. Or, if your brain is up to it, just keeping it all in your head.

Use the right tool for the job. A game can be as simple as Tetris to something as complex as Grand Theft Auto. You don't need a 700-page dialogue script for a puzzle game like Tetris, but you will certainly need one for a FPS RPG like GTA IV.

 

Creating a game without a GDD is like deciding to drive cross-contry without a map or GPS. Sure, it's doable, but you will be stopping constantly asking for directions, and you WILL get lost. You may end up visiting Texas on your way from New York to Washington State.

Basically: it will take you much longer and you will be frustrated often. You also may never realize when are you "done" because you never defined an ending and your gut still tells you "well, would be now nice to add this, and this and this"

Mind you, this does not mean a GDD has to be a huge bible-thick book. Sometimes a single page is enough. Just like a map that takes you to that new comedy club a city away will be shorter than the map that takes you from Florida to California.

Having a list of what your goals are is a good start. Expanding on those goals a bit is great followup.

 

The thing about making a game with no GDD is that you tend to have ideas to add to the game as you're working on it and before long you will come into a brickwall because you didn't think things out all the way. Game Design does not lend itself to linear development.

 

Now it's 41.
Not all are like full length games. Some one off stuff and all that.
Few short games.
Casual stuff.
Some that someone else could use...
Then the long killer RPG that never ends.

Either way. GDDs work for some and don't for others. I have the memory of an elephant so for me, I can probably recite stuff on cue but others may need a GDD. It's not a necessity but for some it works.

 

For that "simple top down zombie shooter" - I pictured at least 15 base levels, bonus levels, final boss level, continuous random play, various weapons introduced at different levels, levels where a min number of civilians must survive, levels where civilians have to be escorted, all the different types of zombie mobs - humanoid, animal, alien...chokepoints on various levels, the AI each of the different kinds of zombies would require, "leader" zombies improving the AI of lowly zombies, area of effect damage, melee and ranged weapons, power ups/health/etc, timers on certain levels, and the list goes on and on...

...and I would still just consider that a simple game.

Adding a perpetual inventory system, experience, skills/abilities, co-op play, multiplayer, death match, team death match, king of the hill, etc, etc - playing zombie mode, ability to select which zone to play so that it is not linear, repercussions for failure, ability to form a team, and this list goes on and on...

...and I would start to consider it no longer a simple game.

Adding in 3D art, ambient sounds, lighting for environmental effect, destructible environments, AI that learns, catering to different playstyles - ranged specialists, melee specialists, psychic/magic abilities, gun toting zombies, and well this list can go on and on..

...and things are really starting to rock - and - are well beyond anything I'm going to do.

Would I make a GDD for Pong? Nope. Would I do one for the simple zombie shooter? Er... yeah. What's the name of the level 6 sub-boss? What color are the main zombies in level 12? What new weapon is introduced with level 8? How long does the clone power-up last in the final stage? Does a perfect score unlock a bonus level at level 5? How many civilians do you have to rescue for level 11? The countless questions that could be asked - I would want detailed as part of the GDD.

 

Your idea of "simple" sure ain't anything like mine, though.

 

Something more in line with this:



That's a design flowchart for the starting XNA tutorial game - Shooter.

 

This ^. So what's common between Braid, Super Meat, and Minecraft? They focused on building a WORKING game. They didn't sit around and talk about it. They built something. They tweaked it. They released it.

@OP - Your premise is a recipe for failure. A server based game, built by yourself, and you're struggling with the GDD? Red-flags are waving at you! You're failing already! Go smaller. MUCH SMALLER. The smallest possible thing you can build. Simple mechanics. Simple idea. GDD of 1 page is fine. Build something in 10 weeks. Release it.

Developing games is like shampoo, repeat as desired. ... I need to make this an article.

Gigi.

PS - I'm no newbie re. networking - See my article in Game Engines Gems 2 (Believable Dead Reckoning for Networked Games).

 

I mentioned earlier, it's optional but you will take MUCH longer.

I have not heard much about Braid's development, but Minecraft has taken years to create and only recently was considered finished. They basically started taking money in an alpha stage.

Super Meat Boy, I recall reading, took way longer than expected. It took nearly 2 years to develop, and to be fair, the game is not that complex. Make that game with a GDD, a well outlined path, and you would have had that game ready in a year or less (experience is a factor, though, but the lack of a GDD is a sign of lack of experience off itself.)

Again: all possible but much more time consuming.

 

I think a GDD can be a good idea. For me though I failed at it because I really needed a GDDDD. ... a document that would keep me on track of designing the design document, lol

I would get the overview done, the elevator pitch, the basic design elements, etc.. maybe even get some short term goals planned out and even some very short term ones, which was okay while it lasted but then whenever I got to a point of feeling kinda done with what I'd designed so far I would get stuck and procrastinate. I think without having the entire document done `up front` more or less you could still just as easily veer off and be distracted. But it's hard to design an entire game on paper without seeing prototypes and playing with concepts and visual styles and letting it organically unfold/intuitively unfold as you go along.