[angryredblock]

I don’t think it’s bad advice but having shipped multiple (really bad) games, I think it misses the two biggest/best pieces of advice I’ve gotten: 1. GDDs are probably a distraction if you’re a solo dev - prototyping and grayboxing a lot and looking for the fun mechanics without any art/music/story to get in the way or distract is essential 2. If you’re truly just starting (and don’t already have a sense of fun), absolute best way to start is to carbon-copy a game you find fun, then start adding/tweaking elements. This both builds the mindset required to make games, and helps you get into the “fun iteration” loop quickly without getting bogged down in writing a lot of interesting technical systems that don’t end up contributing to the game in a meaningful way.

[woko]

Regarding your second point, there is this talk by Petri Purho (Noita) about making a bland game feel fun to the user:

https://www.youtube.com/watch?v=Fy0aCDmgnxg

As for your first point, I would suggest aspiring devs to try to prepare themselves to take part in "game jams". The constraints (including a time constraint) help focus on important parts.

https://en.wikipedia.org/wiki/Game_jam

[yetihehe]

I would like to add one more, The art of screen shake:

https://www.youtube.com/watch?v=AJdEqssNZ-U

[TheHideout]

I've released over half a dozen games as a solo developer and 100% agree with this as well. Using off the shelf assets [0] to quickly MVF (Minimum Viable Fun) an idea really helps get up to cruising altitude.

[0] https://opengameart.org/

[Eyas]

I totally agree with you. I think there are two types of "Where do I start?" that folks wonder:

- Say, I know what I want to build exactly where do I start? a.k.a -- What's the equivalent to starting at the DAO / API layer and building the integration later, in the gamedev world?

- I know I'd like to make games, where do I start coding?

I focused a lot in the article about that first question (and only briefly alluded to prototyping, etc.) -- mostly because I was interested in the theoretical question of engineering practices.

[Terretta]

Doesn’t hurt to jump start that loop iteration by taking in some principles and interrogations.

Two little books that can help:

1. From A Theory of Fun book blurb:

“A Theory of Fun for Game Design is not your typical how-to book. It features a novel way of teaching interactive designers how to create and improve their designs to incorporate the highest degree of fun. As the book shows, designing for fun is all about making interactive products like games highly entertaining, engaging, and addictive.”

https://smile.amazon.com/gp/product/1932111972/

2. See also The Art of Game Design:

”Over 100 sets of questions, or different lenses, for viewing a game’s design. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again.“

https://smile.amazon.com/Art-Game-Design-Lenses-Third/dp/113...

[swimfar]

GDD=Game Design Document

[dusted]

I totally agree with you, find something you've liked and reimplement that, and you will soon find yourself tweaking and adding.. That's how SDL-Ball (DX-Ball) and Wizznic! (Puzznic!) came to be :)