The problem with this IDEALISTIC vision - is that you can put together flow diagrams and sequence diagrams about how the "design" is supposed to work - but it's all WORTHLESS until you actually make decisions on what to use. Why? Because in technology it's all about the "bell curve". Early Adopters vs. Late Adopters. And technology is a bit "touchy" like that. You may use a older, more mature 3D/2D library that's been around for 5 years. Or you may use a newer database that been around for a couple of years, etc. It's all those choices that will ultimately "restrict" how your "design" will operate. The real struggles are in the details of learning and knowing how to integrate each piece.
I understand you want to restrict your game to certain frameworks... Like you might not want TinyDB because it's a file-based database but doesn't have indexes (which mean slower transaction queries - but it doesn't have SQL). So if your plan is to design "SQL Scripts" ... well you can't use TinyDB... There are always restrictions to technologies.
Things like that. When I personally approach a project - I figure out how the architecture is supposed to work. If I don't want a multi-tiered environment with several servers - well then I would choose a language that is more "coupled" but simpler to use.
But I'm sure you already know WHICH components your "design" will work with. And that in one way is smart - because you work around LIMITATIONS.
Cheers.
Well, many years ago, I started doing board game design because I thought it would be easier and faster than programming a game. But I realised that it takes me more time to design a board game than design and program a video game.
And it's also more fun to design and program a video game than design a board game. It seems that the mechanics research, prototyping and playtesting that must be done in board games are boring to me. While playtesting video games are fun.
If you want to use TinyDB, no problem. Make a driver for it and you are ready to go. I had an idea recently for a real-time strategy game and was wondering if I could use the engine explained in this thread since it was real-time. One issue was if I was going to use a database during the game, or simply use pojo objects while playing and save the game in a DB. Or if I could load fixed data from a CSV or JSON file, it's all possible as long as there is a driver for it.
Yes, it is very different. There is no restriction of time and space, which prevent the need of abstracting your game. In board game design, you constantly need to compress and abstract your mechanics to make them fit into pieces, or make the game playable in reasonable amount of time.
Can't, python is not optimised for video games (too slow), I want to eventually deploy on android which requires Java, LibGDX is also coded in java. There could be multiple front ends, but for android development, Java is a necessity.
Maybe it could be possible to create a module that allows loading Python or Lua script for the game logic. But the core of the library must be in Java.