Game made platform specifically: When some developers are making their games, they can sometime rely on platform specific functions. While the game engine might be able to build the game for multiple platforms, the non-game specific code might make a Windows specific call that either doesn't exist on other platforms or would require ...
Engineering for Performance
Follow vendor recommendations.
Use the correct data structures.
Implement the correct usage patterns.
Don't do anything stupid.
When already written code is running slow, measure it, find out why, implement what is required to make it fast.
Make assumptions about what is fast or slow ...
I can certainly see why you would think that it would be hard to simulate those, but there are enough constraints on bullets (all projectiles, really) to make them easier.
They are generally simulated as a single point, instead of as something with volume. This makes collision detection significantly easier, as now I only need to do collisions against ...
Usually you should separate the logical state of your game environment from the visual representation.
The player might only see a small part of it on their screen, but you still keep the state of the whole level in memory and usually also calculate the game mechanics for the whole level. When your world is so huge that this would require too much ram and/...
Probably one of the most efficient ways to implement bullets is using what is known as hitscan. It is rather simple in its implementation - when you fire, you check to see what the gun is aiming at (possibly using a ray to find the closest entity/object/mesh), and then you 'hit' it, doing damage. If you want to make it seem more like an actual, fast moving ...
You are going at it backwards.
You start with the logical state of your game and model that. The whole logical state of the entire world will almost certainly be too much to be held in memory at once, so you break it down in smaller parts that can be loaded and saved independently. These parts are often referred to as chunks. These chunks can form a ...
Because being available doesn't mean being free & instant.
Supporting one more operating system, in its most simplistic form, means one more platform to provide technical support for.
The more platforms you support =
The more platforms you need to provide support for =
Spending more time on support =
Losing work time that could have spent improving ...
If you want to do optimization at the right times, have slow machines and use them. For a small shop, a good option is to use a slow laptop on the commute and a fast desktop in the office. As an additional benefit, if you're a one man shop this also forces you to properly back up the entire build environment.
By using a slow machine you'll know when you ...
You'll need to setup a test account and then publish your build as a draft application in order to successfully test purchases and the workflow as a normal user would. This is what Google has to say on the matter of test accounts:
The Google Play Developer Console lets you set up one or more test
accounts. A test account is a regular Google account that ...
There are good answers so far, but let's get to the bottom line.
According to Steam's June 2017 Hardware survey, 96.24% of users sampled used Windows. Of Windows users, 87.37% are either Windows 10 or 7, 64 or 32 bit. OSX variants represent 2.95% of users, and Linux variants total 0.72%.
Time is money. Unless your market is niche and targets OSX or ...
Consider using a framework, like MonoGame.
It is a kind of a middle ground between "nothing" and a full-blown engine like Unity or Unreal.
It saves you from the really finicky implementation details (3d games are especially math heavy, both for graphics and physics), without dictating too much how things should be done.
Adopt a modular system - this will ...
You should notice that game design is nothing that is necessarily related to programming. It also applies to board games, card games and every type of game, computer games being one of these. It's a different field and being a good programmer doesn't mean you're a good game designer. However being a programmer already can help you becoming a good game ...
I can't imagine designing a game without using object oriented programming, because my entire understanding of how to design a game-program is based on OOP.
Then it will probably be good for you to try writing some programs in non-OO style. Even if you discover that this is not pragmatic for you, you'll probably learn a lot along the way that will help you ...
You, of course, can use a third party solution. You can develop C# games with (in decreasing complexity) Unity, Godot, Monogame, OpenTK, among other solutions.
Making a game without a third party game engine is perfectly viable. You can work with a window toolkit library, a graphics library, and so on. You will have a lot of flexibility... Yet, it is a lot ...
The other answers here are good, but here is one that wasn't mentioned.
I'm having this problem right now - my team is about to release a game made in Unity for Windows/Mac. We've gotten lots of questions as to why our game isn't on mobile. There are 2 main answers:
1) Phones simply aren't powerful enough to keep up with the game. Maybe we can reduce ...
You need to write a game without an engine when you have a game with very unique technical challenges which are not sufficiently covered by general-purpose game engines.
General purpose game engines like Unreal, Unity or Godot are optimized for running any kind of game people can come up with. But a one-size-fits-all solution often has problems with handling ...
Here's my two cents:
No need for a central server: this makes it much cheaper, and more viable for low-budget indie games.
Scales very well (up to a certain point when the average client just can't handle the bandwidth).
Very good for data distribution: Suits games where user-created content is dynamically synced (e.g. torrents).
More Stable: ...
Any object-oriented program can be refactored to a procedural program by replacing all classes with structures and converting all member-functions into stand-alone function which take the object which would be this as an argument.
or when that function is trivial, you just do
They're called profilers. Visual Studio has both CPU and GPU profilers built in to recent versions. A profiler will give you an idea of how much time your app is taking and where that time is being spent. This won't entirely avert the problems of over-specced hardware, though; the app might peg a lesser CPU but only use 60% of your developer machine. They ...
Do you think you don't need more than one or do you think there must never be more than one?
The singleton pattern is mostly useful in situations where the existence of more than one instance of a certain class isn't just unnecessary but would actually cause bugs, so you want to avoid at all cost that there ever is a second instance of it.
Also consider ...
Have you looked into entity component systems and event messaging strategies?
Status effects should be components of some sort which can apply their persistent effects in an OnCreate() method, expire their effects in OnRemoved() and subscribe to game event messages to apply effects which occur as a reaction to something happening.
If the effect is ...
Create an engine module/folder/whatever, that contains everything that can be generalized and is 100% independent from the rest of the
game. This would include some code, but also generic assets that are
shared among games.
Put this engine in its own git repository, which will be included in the games as a git submodule
That's exactly what I do and ...
Gameplay programmers are responsible of the "game" part of the software. What this means is that they're usually responsible, depending on the type of game, for the 3Cs:
Character - the playable character
Camera - how the player sees the world
Controls - how the player interacts with the world
These tasks include a lot of dependencies with the engine, ...
RobStone is on the right track, but I wanted to elaborate since this is exactly what I did when I wrote Dungeon Ho!, a Roguelike that had a very complex effects system for weapons and spells.
Each card should have a set of effects attached to it, defined in such a way that it can indicate what the effect is, what it targets, how, and for how long. For ...
Implementing logic by threads is almost always a very bad idea. Multi-threaded programming is difficult! You will run into race conditions and deadlocks resulting in impossible to reproduce bugs.
There is usually only one justifiable reason to use multithreading, and that's performance: A program can sometimes be made faster by sharing work between CPU ...
Weapons are data. You shouldn't really ever keep data hardcoded. Your structs / classes should accommodate all necessary parameters to build a weapon's data from scratch, e.g.:
Input is hard. Most of the simple patterns you see frequently in game dev just don't work well for input, at least at the low level.
Typically, for any kind of GUI, you need to have some concepts of focus and possibly also bubbling. The HTML/DOM model here is a good resource.
In such a setup, there is a sorted queue of event listeners. For a GUI, this ...
I found the good old rpg maker quite good when I was at that age myself. It's not that powerful compared to the big name engines but for a plain game it is more than enough. And it focuses more on working with the engine rather than writing code.
You have to take as well into consideration how long it takes for your child to see a result. While I was ...
No, you don't have to check after every line because not every line is performance-relevant. It mostly depends on how often a line is executed. A code section which takes 1 ms to be executed is completely irrelevant when it is executed once at game startup, worth watching when executed every frame and must definitely be optimized if executed for every game ...