As a general disclaimer and as DMGregory already stated it: The rules of ECS are not written in stone. Doing it on way has benefits, doing it another way has some others. So, you need to know, what either approach does for you.
So, as i don't know your code, i can only theorize what doing it one way would do compared to another. As you should remember, ...
You can use cryptography. But doing that in a way that actually prevents people from creating spells requires that you do not ship the private key to users, which implies either an internet server, or pre-signing all the spells.
To get a little more concrete, you can cryptographically sign the spells, which essentially means you append a signature to the ...
200ms of delay (between input and response) can be considered to be the point at which things get annoying. Sensitivity to the issue varies from person-to-person, of course, so it's not really possible to give a concrete number.
A delay of 50ms is well under that, and is probably not going to be that noticeable. It may be a problem if your event dispatch is ...
One goal of the ECS pattern is that each system has all its data closely together so that it doesn't get many cache misses when it iterates over the components it manages. So there is nothing wrong with systems having their own memory buffers for data only required by that system.
However, there is one thing in your architecture which is usually not what ...
You'd be hard pressed to find a mobile GPU that could use doubles even if you wanted to, so that part of the choice is pretty much made for you.
There are only a few places where you might benefit from switching from single-precision floats in your game:
recording a total elapsed time
representing an absolute position that could be several kilometers from ...
From my experience in game developing, when making a game for multiple platforms, its easier to organise everything in such a way that works for most of them.
In this case, using a SurfaceView is like telling to android "Give me a rectangular area on the screen, where I will draw custom graphics". This is very similar to how game development is being done ...
A typical game loop (the main loop of the application) looks like this:
There are a variety of software architecture patterns that could be used to implement the above, but the fundamental structure and resulting sequence of actions generally look the same. Input is collected and ...
Edit: The code does not need to be in one binary to allow people to host a multiplayer server from an offline experience. A player is never a server A player might be a host this means the server is hosted on their machine. (or a machine they control) They still connect as a client just they have admin credentials!!!!
This is a fundamental OOP concept known ...
My answer will be based on how dialogue and cutscene system worked in my top-down and platformer games.
Long story short:
Ini files for simple actions and dialogues, Lua scripts for more advanced logic.
My .ini files looked like that:
1 0=ifi val m3p3event 1 10 15 1
1 1=ifi val m3p3event 3 11 12 13
1 10=setb 100
1 11=setb 200
RPG elements in a home-brew game engine aren't difficult, but are hilariously complex to code. Look at the number of bugs in Skyrim, which still exist years after release.
Each npc entity has it's own dialogue when the player interacts with it, and that dialogue will very likely change when quests are completed, abandoned or failed. It may even change ...
As others have noted, how you store the story files is not that important: When you feel comfortable with Lua, it's an amazing tool to "remote control" your game engine to
block user input
move character models/sprites around
aka implement cut-scenes.
You can also encode all this in JSON files, as an array of action steps. Your game will ...
Firstly, I believe that there are some conditions needed for the car to appear on the field, and also i assume that you will want to have more than one car in the future.
I believe it's a bad idea to put all logic into the field objects, the only reason to do so would be performance reasons. But since you have a clear separation of concerns in your case, I ...
There is best, however, I would argue for separating the concerns of deciding what text to show and getting the text itself.
You can hard code the decisions, it is a finite state machine. And, I would argue for reading the text from a file (which you can replace when the time comes for translations).
Or not. The text can be hard-coded too... read from a ...