6 minutes ago, Ktullu said:
Rutin you've definitely got the idea, algorithms and RNG with text based results. I viewed some vidoes on Unity 3D and it does seem way more intense than what I think i need. That being said, I do want to start in something that is scaleable that way I don't need to "rewrite" the code (if I'm saying that correctly) in a new engine if I find out I'm limited.
When you program a game such as this, all your classes can be packed up and moved to another engine. The difficulty only comes from projects that use a lot of the engine's pre-made classes and functions within their own objects. You would have to replace those, or program them yourself if they're not available in the new engine. I wouldn't worry about transferring to another engine if you haven't even started with the game on the first engine. You're not going to be able to future proof technology, it simply doesn't work that way. All games have a life cycle, and at some point you will have to re-work the game.
If you're using a commercial engine that has internal features out of your control, they will usually have a way of converting old projects to their new system.
When you program all the code for your game, a lot of it can be moved to another engine using the same language, it will just require some tweaking depending on how intertwined your classes are with the engines functions. When talking about cross language, that's another topic in itself. I've programmed applications in C++, and converted the projects to C#, JAVA, and SWIFT without too much trouble. You just have to account for different syntax, language rules, and library usage. With experience, these problems are much minor, and are doable, it's just very time consuming.
At this stage it's more important to get started, not so much about getting it perfect on day one. It's your first project, you might end up re-doing it a few times. I remember re-programming a game a couple times over because when I was learning I didn't use very stream-lined approached, and made a nice spaghetti code mess (this was back in C, I wasn't using any form of OOP).
Based on my experience, most of the work is going to be gathering spreadsheet data for all the players, stats, and formulas (how you intend to calculate strike outs, wind variance, ect..), not so much the coding part. The programming part will be more about creating a user interface to display the data, track, and simulate based on your spreadsheets. Your application in a sense is more CPU heavy than anything. It's not bad to use Unity 3D to do this, overkill is better than using GameMaker and finding out you cannot simulate the data fast enough because the engine is too restricted. I'm more hardcore, I personally would just use C++ and SFML (library), but I'm not recommending this unless you're very devoted to learning to code your own game from scratch. This is why I suggested GameMaker so you can at least get a feel for the game creation process before investing more time, otherwise you might have to hire a coder.
