Jump to content
  • Advertisement
Sign in to follow this  
Sidd

Best way to document gamedev progress

This topic is 972 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is it through blogging, Wiki's, updating the GDD with drafts or just writing notes about progress in the TODO list?

 

(When you are the only person working on the game, creating and configuring assets)

 

I'm trying to find a fast workflow for documenting progress, which is easily publishable. I'm currently stacking TODO's in Workflowy and once I'm done I usually don't document anything. However, I have documented progress in the form of reports before - which have become invaluable in later years when I come back to them for advice. 

 

Tools I'm currently experimenting with:

  • Workflowy: definietly fastest tool for TODOs when working alone - but not ideal as a GDD (IMO)
  • TiddlyWiki: A minimalistic GDD wiki. (Haven't experimented enough to gauge it's workflow speed)
  • MediaWiki: Fully fledged wiki? Haven't tried it yet. Seems like a overkill when working alone?
  • Google Docs: Don't find it challening enough... I find it more fun coding latex documents if the GDD has to be linear.
  • Blogs: Seems a little bit clunky but definietly wins on the argument of publishing. The pressure of publishing ensures high quality posts. 

I'm experimenting with the idea of creating a game design document in Wiki form where all the links lead to blog posts about asset creation... But I'm not sure if it's gonna be fast or practical enough.

 

GameDevWorkFlow.png

 

What is your view?

Edited by Sidd

Share this post


Link to post
Share on other sites
Advertisement

I use Workflowy as well to keep track of my progress and planning, but it's for a line-art tool that I try to keep as simple as possible. Here is the project's workflow. I document my progress simply by dragging items from the to-do list to the completed list. But I think you have to decide what exactly you want to document and why. For a one-man team, you have to be careful to balance your time between making actual progress and documenting that progress. I think a simple documentation approach like this is suitable for small and technical progress points, and make a monthly-or-so detailed and well-written blog post to go over what's been done during that month.

Share this post


Link to post
Share on other sites
I use the journals here on gamedev.net to document my games progress to the community.

They're free and you have an interested audience right there without needing to go out and promote the blog.

For issue tracking and project roadmap I prefer jira, it costs $10 as a one off fee if you host it on your own server.

Share this post


Link to post
Share on other sites

In the early stages of my project, I don't have enough specifics of my game to document a full GDD. I know I want to build a turn-based tactical dungeon crawler but that's about it This is the 50,000 foot view. I code some of the big pieces that I know I'll need and make sure they fit together and see what works. At this stage, I have a Notes.txt file that I check into source control where I jot down decisions, ideas, and bugs. Sometimes there are check lists, other times there's a need to do and a done section. And I journal about my progress every one to two weeks here at game dev. If the game looks like it could be fun, I keep going. If it's missing that spark, I switch ideas or revise my original. 
 
My rough workflow for individual features is:

  • figure out what needs to be done
  • Make it work (sometimes hacky)
  • Make it right (clean up the code, comment it, factor things out into funcitons and classes)
  • Make it fast (if performance is a problem)

I'll usually spend a couple of hours to an entire day per week cleaning up my code and making sure I'm not coding myself into tons of technical debt.
 
In my current project A Voxel Adventure, I'm moving into the middle stage. Here I start getting a clearer picture on what I'm building. I take some time to document my decisions in Google document(s) and decide on the scope of the project. I write down all the features I think I'll need and assign a complexity value to each task.

  • 1 = < a day
  • 2 a few days
  • 3 about a week
  • 4 a few weeks
  • 5 Ugh, I need to break this down into smaller tasks

This gives me a rough idea of the amount of work remaining and shows me the types of assets I'm going to need (art, sound, etc.). At this stage, it's good to start looking at the tools you might need for yourself and content creators to make their lives easier (see my journal posts on Unity's Content Pipeline and Editor Extensions). Once it starts looking cool, it's also time to start marketing. Don't make the mistake that you can predict your release date at this point. As you continue working you'll say to yourself, "Oh wow. Wouldn't it be cool if it could do X" or "Holy cow, this feature isn't going to be fun at all, so I'll scrap X, Y, and Z".  In this stage the scope of my game will fluctuate (usually by growing). If the game isn't fun, time to go back to phase 1.
 
I chip away at this growing list until I finally start knocking out more features than I'm adding. In the later stages any kind of awesome new ideas get recorded for version 2 or another game. The release date stops wiggling around so much and you can start to really polish your game. In an ideal world, everything gets documented and you have a nice little audience of people waiting to buy your game ready to pay for it when you finally do release it.
 
Then I sell it and continue living the rock-star lifestyle of the indie-game developer with all the fast cars, loud music, and screaming fangirls. This is my current plan at least. smile.png
- Eck
 

Edited by Eck

Share this post


Link to post
Share on other sites
 

I use Workflowy as well to keep track of my progress and planning, but it's for a line-art tool that I try to keep as simple as possible. Here is the project's workflow. I document my progress simply by dragging items from the to-do list to the completed list. But I think you have to decide what exactly you want to document and why. For a one-man team, you have to be careful to balance your time between making actual progress and documenting that progress. I think a simple documentation approach like this is suitable for small and technical progress points, and make a monthly-or-so detailed and well-written blog post to go over what's been done during that month.

 

Exactly, I guess one has to set up some well defined constraints for the documentation process in order to keep it balanced. Posting a weekly/monthly summarization is indeed the key, it kinda forces you to pick out the most important parts instead of documenting everything. 

 

Share this post


Link to post
Share on other sites

I use the journals here on gamedev.net to document my games progress to the community.

They're free and you have an interested audience right there without needing to go out and promote the blog.

For issue tracking and project roadmap I prefer jira, it costs $10 as a one off fee if you host it on your own server.

 

Journals seems perfect, I had no idea it existed until now! 

Share this post


Link to post
Share on other sites
 

In the early stages of my project, I don't have enough specifics of my game to document a full GDD. I know I want to build a turn-based tactical dungeon crawler but that's about it This is the 50,000 foot view. I code some of the big pieces that I know I'll need and make sure they fit together and see what works. At this stage, I have a Notes.txt file that I check into source control where I jot down decisions, ideas, and bugs. Sometimes there are check lists, other times there's a need to do and a done section. And I journal about my progress every one to two weeks here at game dev. If the game looks like it could be fun, I keep going. If it's missing that spark, I switch ideas or revise my original. 
 
My rough workflow for individual features is:

  • figure out what needs to be done
  • Make it work (sometimes hacky)
  • Make it right (clean up the code, comment it, factor things out into funcitons and classes)
  • Make it fast (if performance is a problem)

I'll usually spend a couple of hours to an entire day per week cleaning up my code and making sure I'm not coding myself into tons of technical debt.
 
In my current project A Voxel Adventure, I'm moving into the middle stage. Here I start getting a clearer picture on what I'm building. I take some time to document my decisions in Google document(s) and decide on the scope of the project. I write down all the features I think I'll need and assign a complexity value to each task.

  • 1 = < a day
  • 2 a few days
  • 3 about a week
  • 4 a few weeks
  • 5 Ugh, I need to break this down into smaller tasks

This gives me a rough idea of the amount of work remaining and shows me the types of assets I'm going to need (art, sound, etc.). At this stage, it's good to start looking at the tools you might need for yourself and content creators to make their lives easier (see my journal posts on Unity's Content Pipeline and Editor Extensions). Once it starts looking cool, it's also time to start marketing. Don't make the mistake that you can predict your release date at this point. As you continue working you'll say to yourself, "Oh wow. Wouldn't it be cool if it could do X" or "Holy cow, this feature isn't going to be fun at all, so I'll scrap X, Y, and Z".  In this stage the scope of my game will fluctuate (usually by growing). If the game isn't fun, time to go back to phase 1.
 
I chip away at this growing list until I finally start knocking out more features than I'm adding. In the later stages any kind of awesome new ideas get recorded for version 2 or another game. The release date stops wiggling around so much and you can start to really polish your game. In an ideal world, everything gets documented and you have a nice little audience of people waiting to buy your game ready to pay for it when you finally do release it.
 
Then I sell it and continue living the rock-star lifestyle of the indie-game developer with all the fast cars, loud music, and screaming fangirls. This is my current plan at least. smile.png
- Eck
 

 

I like your idea of the 50,000 foot view. I usually have some vague ideas, but they are often far to blurred to put into words in the beginning. The more humble approach of evaluating the core game mehanic for 1-2 weeks - prior to writing the gdd -  is definietly a time saver. 

 

Your journal on "Unity's content pipeline" is exactly the type of blog post I want to be making. A sort of a HOW-TO for the gamedev community, which also works as a showcasing for portfolio work. 

 

The picture you have of yourself, in your mind, will come true. Just keeping beliving in your vision Eck! Thanks for the advice :) 

Share this post


Link to post
Share on other sites

I prefer the Blog approach as a Design Log so It can be turned into a Game Concept Document.

Ex: Board Game Iteration to try out game balance.
Header: DATE-TIME - MECHANIC NAME - ITERATION #
Body:
Play Notes: What went right or wrong with this iteration;
Prioritized Next Steps: A list of the wrong things and if they are worth fixing;
Tasks Accomplished: If it went right  how did it affect the gameplay;
Experiments: What other innovations you may squeeze out of this iteration. 

And you keep bulding up other iterations or changes. My first post always is the game Concept or the main mechanic, you can break down the "blogs" for each mechanic.

This way you can allways check what was done and when it was done, why it worked or not and so on. If you do this on Evernote or Google Docs you can get team members inputs on each iteration. It can sub the TODO List also. 

Hope it helped. 

 

Regards.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!