Although everyone has its own programming style, I personally don't think you should start with the game logic of the game without getting any visual output.
I like to start setting up the core components in order to draw a screen, implement all input/visual/audio APIs in an easy to use manner, setting up a basic gamestate system, entity manager incl. messaging etc. etc. I think this is actually a good programming behaviour, start by making a planning and design of what you actually need for your game.
Absolutely. A game, even if you make it without using an 'engine' that's pre-made, has components in it that can be called an 'engine'. The term 'engine' is used very generically.
I'm in no way saying start making levels before your game can display the levels, nor am I recommending to just 'code it as you go'.
Yes, design and plan out the architecture of your game, which includes the structure that makes the game run. My point is, don't try to make that structure so generic that it'll fit any game. Make the structure specific to the one game you are currently focusing on. If you make a game, you make an engine that is custom-made and specific for that game, whether you intend to or not, whether you know about engines or not. Later, you can remove those 'engine' parts, make them more flexible, and use them for another game. This becomes your 'engine'.
But if you try to make a engine that is flexible from the get-go (without having lots of experience), without having previously made multiple games, and without having a specific game in mind, your engine becomes useless because it lacks a game to keep the engine's features and goals in-check.
I'm not arguing that your game shouldn't be planned out, and engineered skillfully, but rather that you should skillfully engineer the game and engine together, so the requirements of the game actually steer the development of the engine, lest you make an engine that serves no purpose and fits no game without heavy modification.
I got the same advice when I started: make a game not an engine. But after finishing a couple of games I felt like I realy couldn't re-use much of my code.
Mostly because I thought things weren't done efficiently or weren't easy to use. At that point I started doing things the way I described above, using carefull design and starting from the ground up and now I can just use this framework I made and start coding the game almost right away.
But the key there is "after finishing a couple of games". You already understand how games work, before you were able to make re-usable components that work with games. If your very first programming project is making a game engine, you won't know how to make the engine because you never made a game.
So to summarize my advice: spend some time making a good design, if you write a very good reusable piece of code it'll safe time in the end by avoiding having to recode everything again.
Definitely. This applies to all software programming. Reusable pieces of code should be created for everything from text editors, to websites, to games. Reusable pieces of code on their own don't become engines. 'Make games' doesn't mean, 'Code poorly' or 'Don't plan', it means (when starting out) 'focus on your current project (the game), not on your next few projects'. It means, don't write your code for imaginary projects down the line, but write it for your current project today. Definitely write it reusable, clean, and stable the first time - you'll be able to adapt it and use it when you get to those later projects, and overtime it'll become very flexible and even more stable. But trying to write it flexible the first time (when you're a beginner), results in not useful pieces of code even for your current project.
Writing code without having solid requirements in mind, results in code that doesn't really fit any purpose.
But don't try to implement all kinds of features you're not going to use in the current game, you can easily implement those features as soon as you write the game you'll need it in.
Yes, exactly! That's one of the primary points 'write games, not engines' is trying to get across. You phrased it alot better than I did.
I'm not at all trying to say, don't write clean code. All code should be clean, almost all the code should be reusable, self-contained, and stable. I'm trying to say to write functional code (whether it be an engine or a helper library or just a few functions), you must have a goal in mind to steer the requirements, or the code usually becomes too general to use without you having to write boilerplate over it to make it usable.
Almost all games have 'engines', and so 'write games, not engines' doesn't mean to make a game without making the parts that run the game - it means to make a game (including the parts that run the game), but don't try to make a super-flexible engine before you even have a game in mind - tailor the engine to the game, the engine is part of the game, so let the game drive the design of the engine.