Hey guys!
Years ago, I started a lot of projects that really went wrong because of no planning and lack of organization.
One month ago, me and a friend, wanted to start this journey of creating a new game. I want to use a great platform which can help me and my friend to work together to keep up with the development.
What do you use in this case? What do you think of a GDD? Maybe using Trello, Notion or something like that?
Your answer helps!
Thank you,
Juan
For larger projects, I use an A, B, C category To Do list:
A: Must get done immediately.
B: Will get done as soon as there is time.
C: Would be great, but can be sacrificed.
As items in A clear up, you move B items into A and break them down into individual tasks. If B is empty, you move C into B and break it down into chunks and then move these chunks one by one into A with a further breakdown.
C items would be something like dynamic weather system → B for dynamic weather system would be weather types and → A would be Rain, broken down into sound, visuals, functionality, etc. → Then snow, then wind, then sun etc.
For character movement, A would include user input, movement and animations. In the B, you would add things like climb, vault, swim. In C, it could be something like procedural interactions/animations. B items become faster to implement in A because it’s often just copy/paste work with some additional work. C items become easier to implement to B and then to A, because you have done the repetitive ground work so many times.
You can also add a D category for fancy incredible ideas that are absolutely unnecessary, aside from it being very cool. Once you have testers, a basic fanbase and the first players, you can let them vote on D items after the game has been published in the first version and bugs, errors and C items are completed.
The biggest difficulty for the solo/tiny team developer, IME, is getting spread too thin - brain drain, whatever you want to call it. Because there is too much work to do, even on simple projects.
So, when it comes to software, technicals, etc, my goal is always to keep it as simple as possible. Limit the amount of new stuff you have to learn so that majority of your time is spent developing and iterating on player experiences. If long periods of time are spent solving technical or organizational issues, you’ll lose momentum and development will become a test of your will rather than a journey of bliss and discovery :).
For daily/weekly/monthly checklist , Trello is the simplest solution, so that’s what I use. Don’t go overboard trying to plan everything though - I just keep a running tab of stuff doing right now, stuff coming up soon, and stuff to be done later. The goal is only to make sure I don’t forget things and can reassess my priorities each morning before starting work. Anything beyond that becomes a time sink, so I strongly recommend don’t get crazy over-engineering your organizationals.
Before I start any new task, I got in habit of saying out loud WHY I am doing it, and I review my priorities written down on Trello. I also define a backstop - something to let me know when I have satisfactorily reached the goal, so that I don’t go too far beyond it and waste time. All of this helps avoid time wasted noodling, which can become a form of procrastination.
For daily communications with your teammate, discord or google meetings is great. GITHUB desktop is a very user friendly app for version control.
Assuming you haven’t made a lot of games on your own already, I think it’s better to not try to plan beyond your capabilities. In other words, a plan depends on knowledge to be useful, but you don’t know everything yet, so your journey then is more about discovering unknown things. So don’t try to conform to a rigid plan, but rather develop a way of continually reassessing where you are, where you want to go, and have regular reassessments to reconsider priorities in light of new knowledge gained.
Completing and publishing a really bad game is much more noteworthy than almost completing the worlds greatest game. So for the first couple projects, I’d set highest priority on finishing, above all else.
Few years back Trelo was great, but now not sure.
For small team best tip is “make game adequately small to size of your small team”.
Yes i sound like broken record with this.
There are two reasons for small games (At least at beginning):
Also remember having “working code” that has all features in is usually half of the way to completed software product, and usually easier half.
Thank you @Nawrot, @BIGTIMEMASTER, @anon18065303. I’ll take notes of everything you said. Each one of you has a great way of management, so we’ll discuss with my friend which one we choose.
We’re just planning to develop a small game, but as you may know, game development takes a lot of time, and I want to make sure to have everything on track.
Thank you so much and have a great week,
Juan