A person is hiring you for freelance game programming. Let’s say you are building the full game architecture, not only select parts.
They provide a design document. Which parts are you most interested in? Are there some areas that you commonly have to ask further info about? What would your ideal set of instructions look like?
More specifically, are you looking for a lot of theme, feel, character type stuff? Artwork to help you visualize end experience? DO you appreciate if someone has broken down gameplay ideas into logic chains? Does that help, or hinder?
In order of priority (most important first), I’d need to know:
You’ve taken care of the business side. You’ve secured adequate funding, won’t run into any IP licensing issues, have devkits if doing console work, etc.
You’ll be able to handle the management side. If you have publisher funding, you’re capable of negotiating with unreasonable publisher deadlines and surprise requirements. You’ll be able to effectively manage team members. You can get around in some kind of project management system such as hacknplan or Confluence.
You understand that development is an iterative process. You can work with me to establish milestones and are flexible enough to adjust them as necessary throughout the development cycle.
You have a treatment document, typically 1-2 pages, that identifies fundamental design aspects such as target platforms, genre, art style, and approximate scope and play length. I wouldn’t require a longer design document right away. In fact, that’s probably something that would be best to write after some initial discussion with me, and with the understanding that it’s a living document that will grow and change during development.
After that, gameplay flowcharts and artwork at different levels are extremely helpful. Detailed logic chains aren’t necessary; they’re something to iron out collaboratively with me.
Gameplay flowcharts include the big picture: the game starts, then this major thing happens, then that major thing happens, etc. But also writing low-level flowcharts as needed provides a concise way to make sure we’re on the same page for small things like how a single NPC should execute its activity cycle.
When implementing visuals and behavior, GIFs are invaluable. An animation is often worth more than a thousand words.
Also, if you can grab video clips of examples from existing games – such as Celeste’s run cycle, or Skyrim’s inventory management UI – they can provide a performance bar that I know I need to reach or exceed.
Admin stuff is the most important. Pay rate, timeline, Unity version, project repos. Its surprising how many times I have to ask about this stuff.
I like to have mock up screen shots of the game areas I’m working on. A screen shot is worth a thousand words. A series of annotated screen shots is worth ten thousand words. They don’t have to be fancy, even hand drawn sketches work.
After that I want to know design details. High level logic about the game loop. What is the player meant to be doing. Which parts of the design are core to the experience. I expect low level details to be worked out as we go.
I’m generally not concerned with artwork. As a programmer most of my interaction with art will be drag and drop.
Some of this stuff, I imagine, is probably meant to be discussed right? For instance, in my case, as designer/artist, I don’t care what version of unity so much. Of course I want to know what options the new render pipelines open up, so maybe I want the expert to do some research there or whatever.
So, I think as long as the person you are communicating with is aware that these are important factors and has some kind of plan, it’s cool right?