What does being a Gameplay Programmer entail? Do you strictly only focus on like programming, or do you get to help design the actual gameplay of the game too? I ask this because I feel like I have some cool ideas for video games, but I want to be more focused on the programming aspect of creating video games, but I would also like to be able to voice my opinions and ideas. Is this a possible thing in a professional environment? Then, what does a gameplay programmer actually do, like I obviously know the standard things they do, but what else do they work on/do?

StrideUS said:
What does being a Gameplay Programmer entail?

https://sloperama.com/advice/lesson15.html​

StrideUS said:
Do you strictly only focus on like programming, or do you get to help design the actual gameplay of the game too?

The vast majority of your work is implementing the features. You start out as a junior developer mostly asking questions and being guided to do things, after a few years you implement more things and people will occasionally ask you about your opinion for implementation decisions.

The tiny implementation decisions made by programmers have an enormous impact on the final look and feel of the game, but programmers aren't designers. Mid-career and above will be involved in meetings discussing details of designs, bouncing ideas around and killing ideas based on cost, complexity, and other factors.

StrideUS said:
I feel like I have some cool ideas for video games, but I want to be more focused on the programming aspect of creating video games, but I would also like to be able to voice my opinions and ideas. Is this a possible thing in a professional environment?

Everyone in the studio is able to voice their ideas. Everyone also has good ideas about video games. Even non-gamers have ideas about video games. Ideas are common and almost valueless, good ideas are scarce, great ideas are extremely rare, and amazing ideas are called unicorns for a reason. Don't expect much to come from your ideas, but feel free to share them with your co-workers. Usually they'll be destroyed under scrutiny, but suggest them anyway.

StrideUS said:
Then, what does a gameplay programmer actually do, like I obviously know the standard things they do, but what else do they work on/do?

If you know why do you ask? About 1-3 hours per day of meetings, trying to figure out systems, and documenting things, about 5-7 hours per day of programming systems into the games.

Gameplay programming entails making toys for game designers that they then glue together into the actual game. frob already pointed this out, but the gameplay programmer ultimately controls the nature of those toys.

The main skill I see gameplay programmers needing on top of their actual programming skills is collaboration. Depending on team size, it's likely that the people who are making the decisions about what things are in the game and what their final tunings will be will not be the programmers (because tuning content is faster than tuning code, usually). Being able to develop a working relationship with designers is essential, because when you're iterating on gameplay you're going to be working with them constantly. Get good at talking to people who are not programmers and don't understand the constraints we are subject to. Get good at listening to people who are not programmers and may not use terminology or jargon in exactly the same way you do. And try not to be put off by “too many meetings.” If you're a gameplay programmer, then talking to designers is your job. Get used to it - it's how your voice is included in the game.

You'll also want to develop your debugging and testing skills. You'll likely be spending a lot of time doing that, because the kinds of bugs you get are likely to be of the form “when I do these three things in the game, in exactly this sequence, the game crashes.” You may need to be debugging remotely sometimes, because a gameplay bug only reproduces for the designer with the exact configuration of content they have, which takes both debugging skills and collaboration skills. You may be debugging crash dumps that people send you, with extremely vague repro steps ("load into level X and play the game naturally") and only the game state in the dump to tell you what may have gone wrong. Gameplay code also has a reputation for being difficult to test automatically, but it can be done and it can be helpful if done right. Every bit of automation you can add saves QA some testing time.

Some programmers also take morale hits when they write code and it gets thrown away or changed completely. In gameplay programming, though, writing scrappy prototypes and throwing them away when they aren't fun is par for the course. If you're prone to that kind of morale hit then you're going to need to develop some resilience to it. I think most people who stick with it will eventually develop that naturally, though, and good collaboration skills can help minimize the amount of time wasted on throwaway work, but you need to be at least sort of okay with writing disposable code to be a gameplay programmer.