Highly recommend checking out some industry-related podcasts, such as the ExtraCredits one on youtube.
One big part you missed out of your skill list is all the management side of things. Making the assets for the game is only a small part of it. For example, QA/Testing time would likely exceed programming time by a big margin.
One thing you probably should definitely NOT do is jump right in and start coding your "dream game" with a long list of cool stuff you're going to add to it. These projects never get anywhere because you're constantly cramming stuff in and it will always look and feel like a mess that you can't show anyone.
Focus instead on scoping out small ideas for demos or small games. Have a
strict feature list and time frame. These should be written up as an elevator pitch (1-3 sentences describes the thing to make) along with a Game Design Document. (
https://en.wikipedia.org/wiki/Game_design_document) that's about a page or so outlining the feature set, target platform, time frame etc.
Then, making the thing and work out how long it actually took you and write up a game post-mortem.
http://lvictorino.com/blog/write-post-mortems.htmlA post mortem should be a short essay describing what you made, what went to plan, what didn't go to plan, and how you plan to improve things the next time. The goal of each game-design cycle is that you have a complete, small game that's ready to upload as a demo.
If the scope was too large (didn't finish a
playable game in the aloted time), make another one with less scope. Here, the concept "minimal viable product" is useful. The MVP is the smallest feature set that exhibits all the desired behavior. for example, if fighting and collecting loot is part of the design, you need exactly one enemy type and one loot type. The same concept can be applied to adding new content to an existing bigger game you're working on: treat each new addition as a mini-project, write up an elevator pitch and 1-page design-doc related to the new content and budget time to complete it, along with milestones etc, and do the post-mortem for it the same as you do for a complete game.
As for all the stuff you want to add to your game, consider studying something call the "gameplay loop".
https://gameanalytics.com/blog/how-to-perfect-your-games-core-loop.htmlGameplay loops are a concept about the cycle of actions that players must take while playing the game. Run, jump, shoot, kill, heal up is a rough outline of the gameplay loop for an FPS. However, there can be overlapping / nested / fractal gameplay loops. For example, killing enemies and collecting loot is one loop but you can have another loop of your weapon being damaged/repaired/upgraded along with high-level character goals being another loop (clearing stages/levels/area). Dwarf fortress's Fortress Mode gameplay loop probably alternates between "build structures" and "assign workers". By focusing on the "gameplay loop" as your core design principle you ensure you stay focused on
what the player is doing, rather than focus on "adding more stuff". e.g. if you decide "the game needs 7 types of bread for variety" then you can ask, how does this add new gameplay loops or improve existing ones? It doesn't, so don't add more types of bread.
Another important area is to study game theory if you want to be a designer. A "dominant strategy" is one that is always the best option. They are basically the death sentence for game design. If you add one of these inadvertently, they basically ruin your game design. This is why many units in games stick to a "rocks-paper-scissors" type of balance. If you have a "best" weapon, or "best" armor then this is a design problem. Why do any people have non-best armor then? Players will always ignore the other choices if there's one best one, so there will be no variety of builds or weapon/armor choice.
http://www.gametheory.net/dictionary/DominantStrategy.html
Author
Topic: What things do you consider when getting into game development? (Read 3608 times)