Game Development is great, you're the "higher power" you make your world, your characters, your objectives etc. However there are some thing's you probably won't learn until it's too late and becomes very hard to change...
From my own experience of creating games here's some thing's to keep in mind when you start creating a new game. I had to learn the hard way just like I'm sure other developers have. Well hopefully this helps.
#1: Settings When starting a new game you typically start with the mechanics and such. When you create the mechanics you typically create the Menu and UI. However when the time comes you need to add settings to your game, you now need to A. Create a settings system and B: Impliment that system throughout your game. You now want to press ALT F4 because doing this is such a hassle!.
What I do is I create a Settings system at the very start and I use it as I create the mechanics, menu, UI etc.
It makes thing's soooooooooooo much more fluid and easy. Less work means more motivation for other things. Like adding new, exciting features.
#2: Audio Just like Settings I create an Audio system at the very start, otherwise I have to create the system, go through the scripts... oh dear so many times I have had to do this until I learned my lesson.
My point from #1 and #2 is... THINK AHEAD. Think ahead of the mechanics, the menu etc. It might be hard to do sometimes, to predict systems you might need in the future, but it is worth it. Of course, if you're just making a prototype it isn't such a big issue.
#3: Primitive shapes are your best friends! Too many times I have tried to model specific thing's for a new game. The truth is, you might have a vision for this new game in your head right now... but half the time that vision can change!
Use the primitive shapes (cubes, spheres etc) to get the mechanics and gameplay down to the T!
Then you can model those freaking awesome looking models to bring your game to life.
4: If you don't like criticism, this is the wrong industry for you Let me say to start with, you will never please every person who plays your game. If you have friends who are willing to play your game before you release it, that is great!
Receiving feedback, wether it is bad or good, is still feedback. Feedback allows you to debug your game from other peoples eyes. Take what they say on board. Because if they say the movement mechanics are jittery and slow... in a public release, more than likely everyone else will say it too. Probably in a not very nice way....
Conclusion I hope this at least gives some form of help to someone. For other developers who may read this, if you have anything to add or comment on fire away. Nobody will tell you these thing's in tutorials and what not. Game Development is a trial and error industry. Don't take everything to heart.
Don't make a game for money, fame or to make other people happy. Make a game that you will enjoy playing. Your happiness is important too..
The #1 Settings sounds so familiar to me as I did this mistake. I am stuck over 3 years with no settings and just recently started implementing them. Let's say it's a lot of work for a seemingly simple system.
The #2 Audio is relatable as well as my game again has no real audio design yet. It'd be a long journey until I make all of those sounds and implement them in code.
The #3 Primitives are very important indeed and I like it how you say that your vision should change if gameplay doesn't prove entertaining in the primitive stage. However, may I add that leaving the real graphics for too long could also be degrading just like the audio system situation.
The #4 Criticism. Testing with your friends is the first vital step in taking feedback. To avoid unnecessary conflicts, both sides should give enough context to each other about game interests, previous experience and possible expectations. If that step is correctly applied the feedback would be more meaningful to both sides (basically the developer knows why, and the player knows why).
Make sure though that the feedback is genuine, as negatives could be easier to take in from a friend than a stranger (depends). In both cases disingenuous positive feedback leads to deceptive positive reception, leading to wrong decisions.
Unless your best friends are primitive shapes...
#3: Primitive shapes are your best friends!
Don't make a game for money, fame or to make other people happy. Make a game that you will enjoy playing. Your happiness is important too...
It's all about expectations and being self-aware of your expectations. Your goal could be to make other people happy. If that goal makes you happy, then I don't see what's wrong with that. However, mess that up and it becomes instantly apparent that something is wrong.
@tinsoldier, #1 #2, I partially agree, however you can't deny that in CB (when it used to be in active testing) it had been too long without any sort of settings or audio for the most part. Though you are right, systems are always in some way or another refactored, making your dummy code feel unnecessary to write in the first place.
i agree with tinsoldier, maybe it's because i use the same 3drad engine, but it makes no sense making a settings menu 1st as this is a global thing, which can later be added to each level easily as a global script, and has nothing to do with local levels which is where the focus should be. same goes for sound, they are both the finishing touches of a working project, where you should have a much better idea of what settings/sounds you even want in the 1st place.
...perhaps your advice is only relevant to the unity engine.
... or perhaps relevant to any other engine than 3D Rad. Even though the engine has nothing to do with whether you should have settings/graphics/sound go in parallel with everything else, but you somehow still manage to make it 3D Rad vs Unity thing.
In my opinion. I suggest also knowing what will be the stand-out feature of the experience you are putting together. If you are taking a path often travelled then there should be plenty of road maps to navigate things like , story, presentation, gameplay etc. If you are putting your own spin on an already existing formula, you should try emphasizing your added features through gameplay or story telling. You can engage players as well, through story as you can through gameplay. If you don't think so, then I would refer you to classic text based games and traditional desktop role-playing games. And even I will admit that shooters and racers are enjoyed based on gameplay mechanics. So its always good to research what type of game it is you want to make. For me, I enjoy story based games, but I admittedly love it when a game makes you enjoy grinding, like some rpgs, both eastern anc western.
If you are just starting out on your gamedev journey its nice to just play it safe and do unique but mostly safe and standardized game. And always remember to enjoy the process as much as the end result. It takes alot of effort and time even to make small demos, but as long as you enjoy the process of game dev, you always have energy to push yourself further with each project.
Thats my 2 cents, and yes, much of heat I said is common and well discussed on other forums and game dev sources. So I'm actually just passing on the 2 cents I got from elsewhere.
... or perhaps relevant to any other engine than 3D Rad. Even though the engine has nothing to do with whether you should have settings/sound go in parallel with everything else,
actually, there are only 2 engines where i think it is relevant: unity and maybe unreal. these both have a plethora of plugins for things like that, so if you use default settings for say controls, then switch to a plugin with better options later, you may have to rewrite the controls and all linked objects to be integrated with it. ......this is not the case for most other engines like cryengine, esenthel, godot that just like 3drad, use global scripting and/or ini files and do not have a ton of plugins, so it is no more work [usually less work] to add settings at the end of a project instead of the start.