I completely disagree, its been my experience to see people have projects they could have completed in 6 months and are working on two years later because they kept constantly changing their architecture to something they thought was "more reusable, more pleasing to the eyes, more expandable." Structure becomes much more important the larger a project gets, or if the project is -planned- to be reused for multiple games, and also if the developer is working with others. Not saying it's always a complete waste of time but when you just throw a bunch of bullet points at someone "do this and that" it makes it sound like a golden rule.
There are no golden rules in coding, golden rules produce more bad code than good.
He wanted my critique, he got it. If he wanted reasoning he can ask for that as well. I never represented my bullet points as any golden rule.
That's personal preference then, I personally don't see the point of that. If i'm browsing for a header file I'd see it just as easily in one folder as having to have two open, header files are usually paired with source files anyway. I wouldn't understand why you think having them in a seperate folder makes them easy to locate but to each their own.
It's because one can see how things are interacting and working just by looking at header files, then you can look at implementation details later.
It's not the time to implement thats the thing, its that you're simply throwing suggestions at him he may not even use for anything. 10 minutes for who, you? Does he even know how he would implement it as a controller instead? It likely requires more code changes than just the class itself anyway.
If he doesn't know how he can ask, you know DishSoap can act on his own behalf right? Pong is incomplete without AI and it's safe for me to assume he is making pong.
A recompilation of a game his size is negligible at best, as would be a game of a much larger size(even having to recompile the entire game via having naive constants.) Again I'm not necessarily saying its wrong, simply that you don't even explain why. I find far too many people on these forums who seem to think there is one true way to do anything, even if it massively overcomplicates a project you could finish in a few days into a 6 month horror.
Constants are useful and can be mixed with settings loaded from files, the trick is knowing when to use either.
A config file is easier and faster to change than constants. You should add your suggestion about what he should make constants and what he should put in config files instead of complaining about my suggestions.
Yes yes I get the sarcasm.
Why would factories for everything be overengineering? To me that sounds like a rather curious design choice in general.
Actually.. seperate rendering and logic is something you should do in general typically, its rather trivial to seperate them and they never should have really been together in the first place.
Namespaces wouldn't take too long to add, but I agree, overengineering.
I actually saw someone with a github that had a cmake setup for.. what, three files? Ugh.
My main thing about seperating game and engine is that it usually complicates design more, and people do it for the sake of engine reusability. Early on in particular you really shouldn't be trying to reuse your engine.
Any kind of resource manager is a pain to make, especially one that works well, definitely agree there.
Library engines.. ugh.. to be honest I find that silly just in general, The only time that would be sensible is if you had completely different teams working on either one and needed to swap constantly, or the Engine needed to be very reusable. Unless you work at a large company this seems extremely unlikely.
Honestly implementing mappable hotkeys is probably one of the earlier upgrades he'll do if he makes future games, so that wouldn't be a huge waste of time to learn. But for simple games I agree, waste of time.
A C interface? What? Why?
Clearly we need user made extensibility for our huge userbase, this pong game must be modified to death. Although adding official plugins would already make it more advanced than Minecraft(hurr hurr.)
Player metrics.. that one caught me offguard. Touche.
Paddle -> PaddleFactory : Factory<Paddle>-> PaddleFactoryFactory<PaddleFactory>. Why? Because we want an agile solution with tightly packed memory allocations for EVERYTHING.
Changing world object to separate that would require fixing ball and paddle for no raisins.
CMake is faster to create a project than a visual studio wizard IMO, but maintaining premake and cmake is crazy, something wxWidgets almost did!
He already made re-usable parts, it's only logical to put them into their own module or library
We need maximum portability for major scalability and project redundancy. (Ogre3D, lol)
The mod API is for professional level scalability, we need to allow any and all changes to be made at any point in time by anyone. This increases synergy while promoting code re-usability, not to mention that we get Ultimate Synergy™.
Don't forget it's scalable for enterprise level usage!
We should probably stop derailing this topic though.
You have non-game specific code in your pong implementation please separate 'engine' code out into it's own module or library
Seems like a complete waste of time as well as overengineering for the sake of "ideal" correctness.
Separate your header and source files into different folders (include and source)
For a game? Why? He's not writing a library here, who is going to be including these headers besides the game itself?
A Paddle shouldn't handle it's input, take that out into a PaddleController class so you can easily add AI to your paddle.
Does he WANT to add AI?
Remove boiler plate code from main and turn it into a Game class, inherit from that when making Pong
While I agree about moving code out of main I don't really get where the assumption would be that he should make a game class and then inherit from it. He could just as easily have a "Game" class by itself.
Remove all magic number values from code and put them in json or xml files that describe things like game specific data (Paddle initial positions) and engine data (window size, title etc)
Removing magic numbers, sure. He could just as easily make them constants and should make that decision based on his usage, not simply throwing a bunch of random and possibly useless settings in an xml or json file and then getting library code together to load it and parse settings.
If theres one thing that wastes just as much time as bad code its overengineering code just because its the "pretty" thing to do.
Over engineering? It's simply making it easier for a reader to see what is actually game code and what isn't, seeing as he isn't the only person reading the code it isn't a complete waste of time. Good structure is rarely a waste of time, even in small projects.
For the same reason above, so people reading it can directly go to src or inc for whatever they want to look at. I didn't say he was writing a library. I don't know why you wouldn't do this 'for a game'.
Well, AI is just an example what if he wants to add a networked controller so another application could control a paddle via some port? It's all about SRP and makes it well designed, it is also maybe 10 minutes of work.
I was just following his other design patterns (i.e movable which things inherit from) and I think it fits.
Sure, constants would work, but require a recompilation every time, why aren't his shaders, materials etc constants as well? Again following what he already had in his game.
You want to see over-engineered?
Factories for everything, remove public constructors
Separate rendering and logic
Normalise all namespaces and add missing namespaces, make sure they have proper and long names.
Use premake or cmake (Preferably both) for agnostic compiler \ IDE project setup
Separate engine and game into different git repositories making use of sub-module
Add an asset database for handling resources (config files, materials, mesh etc)
Engine should definitely be it's own library(rather than just some code) and be seperated into core, math, render, physics, input, network, UI and game (WorldObject and Game class)
Input should be more generic and be loaded through a config file for ease of changing actions
Write a C interface for everything
Add a plugin system for mods (Allow use of hot-loaded dlls and scripts for at least 4 languages, make use of SWIG)
Capture metrics of players and send back to database using pig, hadoop and map reduce.