Ah, didn't know the scope of what you had to work with. Yeah that'd definitely be an ordeal to pursue.
Thanks for elaborating.
No problem
Than what "game designer" is stands for?
From Wikipedia:
"Video game design is the process of designing the content and rules of
You must be registered to see the links
in the
You must be registered to see the links
and designing the gameplay, environment, storyline and characters in the
You must be registered to see the links
. The designer of a game is very much like the director of a film in many ways; the designer is the visionary of the game and controls the artistic and technical elements of the game in fulfillment of their vision."
All three of us on the core team
equally share this role.
Also from Wikipedia, game design constitutes designing:
- Gameplay, which is the interaction between the player and the mechanics and systems
- Mechanics and systems, which are the rules and objects in the game
- Player experience, which is how users feel when they're playing the game
This is also why "programming" is listed separately.
While there are a chance that all 5 developers statements that their >9000+ years of experience was lie, I have a feeling that problem was not in their hard skills (i.e. how to code stuff) but in soft skills (socialization skills in general) or even team. I mean, five different programmers...with actual games...with, okay, some experience...in continuous sequence...that dont know how to code? Really?
It wasn't a lie.
The thing is, programming in the AAA industry is worlds different than doing it for a small indie team.
Programming for something like say, Grand Theft Auto V, requires the programmer
usually to only worry about
one single aspect of programming within the game, like say, the collision physics for objects, or the AI behavior for NPCs, or things like that.
For indie games though, Frouge has had to do the following, just off the top of my head:
- AI behavior for bosses and enemies
- 2D Lighting for lots of different objects / general lighting engine
- Collision between the player and other objects
- Gravity physics
- Hooking up voicework, sound effects, music to events
- Adding in and setting up proper animation cycles and effects for all visuals, parallax scrolling, enemies, etc.
- Powerup implementation/addressing conflicts between over 19,000 possible combinations
- The entire cutscene system / flag system
- Platforming physics
- The in-house editor for making levels
- Save data and flexibility with it
- Optimization and compression of all the above so the game runs well even on lower-powered systems
- Controller support and remappable controls
- Fixing all the bugs with the above that get found
And a whole host of other tasks he needs to do.
On an AAA game, the above tasks would be given to team of probably 10 or 15 different programmers.
On indie games like ours, it usually falls to just one person.
So, as a result, with your earlier example of planning for expanding the scope, that's just not something you usually do for indie games simply because you have to focus your efforts with the mentality of what's capable for a single person to do, as well as minimizing the time you need to spend on something while getting the most output/quality of gameplay for the player.
What I mean is:
they was unable to tell you, in such a way that you would be able to understand them, that implementing X not as easy as it looks;
I have a decent level of understanding in programming, audio design, game design, art, and everything else it takes to make a game, but I focus on what my strengths are. Because of this, I'm able to design individually catered game design documents that take into account just what is feasible for a programmer (or artist or audio person) to do.
But I'm not perfect: I still ask the programmer, after they've went over the sheet, if there's anything that's unfeasible. If there is, then I work with them to figure out a way to compromise to get something
close to what we were going for, while still making it feasible for the programmer to do. And if that's not possible, then we scrap the idea entirely and come up with something different together.
(This is why I always equally share game design roles with the core team: I'm not a pro programmer or artist, so I trust them to know better than I what would be best to do in those categories, just like they trust me with story and level design and all the other things I do.)
---------------------------------
Here's an example task I asked one of the other programmers to do for a different game (Internal Interrogation), with all art and audio already completed and provided to them per the programmer's own specifications, using the image below:
- The player starts the game at the bottom floor of this dungeon up above.
- We need the player to be able to single-click the big double doors on the left if they want to exit the game.
- We also want to have an arrow at the bottom of the screen (art was provided for this too), pointing downwards.
- If the player single-clicks on this, the screen should fade out.
- As the screen fades out over 2 seconds, the provided foot-step audio should play 4 times with an interval of 0.75 seconds between sounds.
- After 2 seconds of darkness, the screen should fade back in over 0.5 seconds to the "Jail Room".
- If the player clicks on the spiral staircase to the right, the first Dungeon should load.
The actual document I provided the two programmers working on this game goes into even further detail, linking to the files needed, showing a video mockup with audio and visual diagrams.
The above design instructions took two of those programmers working together three days to implement, and even then it never truly worked correctly.
There were numerous bugs, glitches, and other oddities, requiring multiple revisions to get it right at even a basic level.
---------------------------------
Feeling unsure of myself at this point, I showed the document and assets to a number of indie programmers who were working on other successful adult games at the time.
Every one of them said they'd be able to implement it within an hour tops, and that nothing in it was complex, hard to understand, or too demanding of a programmer.
And the programming for Internal Interrogation was
much, much simpler than even the most basic stuff in Future Fragments.
constant "how the progress on X?" ten times a day (are we there yet? not yet. are we there yet? not yet....are we there yet?);
I check in with my team about twice a week on average. I trust them to get their work done: they're adults.
If I check in more with them, or they check in more with me or other team members, it's because we're testing out things together to see how they feel when actually played, or we're hashing out game design choices we've made.
For the rest of the stuff you said, I'd be giving a similar response: people need to get stuff done, but I'm not going to police them over it. The last thing I want to do is to be "the boss" that "whips" people to get done: that kind of work environment helps no one. I'd rather have people on the team who are self-motivated and work of their own accord.
In general, I feel like this post is fairly cynical of both game development in general and interpersonal relationships within our own game. The post implies that the people on a team couldn't possibly enjoy working with one another, or be mature enough to behave like adults, or be able to actually treat each other like individual humans.
So honestly, while I appreciate your feedback, I'd like to actually keep the topic on-topic, and not keep going down the road of... well, all of this, because it's off-topic and it's clear you have a very different perception of what it's like to be on a game development team than what I've personally experienced, and it's unlikely we'll see eye to eye nor change either of our perceptions on things.
