Hi there guys!

Same old story, I've had this idea for a game building up for a long time, and for a while now I've been learning Java. That's the language I'll be using, I'm set on this. I know that there some great software out there that I could use to learn about gaming development, but they would not let me have the game mechanics the way I want it, and I have almost all of the gameplay features already figured out. These are critical for what I want to experience and share, so I have to build my own game from the ground up.

But that's not really the point of the thread. What I really need help with is the game project. Let me clarify:

- It's gonna be a strategy-rpg, in the molds of GBA's Final Fantasy Tactics and Tactics Ogre, so it's gonna be story driven, and here comes the first point: how to separate what goes in the bulk of the game engine (java), and what can be done with a scripting language (Lua probably); I know already that sound, graphics and I/O will be done with the heavy coding in java, but how much of data management, story triggers/events and other critical stuff, like player progression and battles, could or should be done with it too?

- Also, and I really searched for this countless times: being written in java, it'll be object oriented, but what would be the basic classes that a game like this would need to have? If it's too broad of a question, feel free to not answer =]

- And finally: if I were to write this project down, like, to have some sort of guideline or a full description of what I'm doing, what would this document looks like? I think that's what one'd call a "game project", but it could have another fancy name that I'm not aware haha

That's it. Sorry for any mispelling or confusion of ideas, english isn't my first language. I'm open to all your guidance and thoughts.

Thanks in advance o/

- It's gonna be a strategy-rpg, in the molds of GBA's Final Fantasy Tactics and Tactics Ogre, so it's gonna be story driven, and here comes the first point: how to separate what goes in the bulk of the game engine (java), and what can be done with a scripting language (Lua probably); I know already that sound, graphics and I/O will be done with the heavy coding in java, but how much of data management, story triggers/events and other critical stuff, like player progression and battles, could or should be done with it too?

Scripting has the largest impact when it allows your not-really-programmers to define behavior. It's still useful even when used by the actual programmers but especially if you don't have much experience yet and you work alone anyway it might be a better plan to go without scripting. But also see below.

- Also, and I really searched for this countless times: being written in java, it'll be object oriented, but what would be the basic classes that a game like this would need to have? If it's too broad of a question, feel free to not answer =]

My honest answer is: if you have to ask, you are probably not ready for it. The vibe I'm getting from your post is that you really do not have much experience with programming. Pick smaller projects (much smaller) until you know your way around. You do not need 'millions in investment' for a decent indie RPG/strategy-RPG title but it's simply going to be one of the projects I definitely would advise against when you are still learning.

- And finally: if I were to write this project down, like, to have some sort of guideline or a full description of what I'm doing, what would this document looks like? I think that's what one'd call a "game project", but it could have another fancy name that I'm not aware haha

You mean like a game design document?

- Yes, I agree, but I'm talking about the good prospects for a serious project that will generate significant profits.

You are assuming the interest of the OP is 'significant profits'. For most hobbyists this is a faulty premise to begin with. I already have a well-paid job. When I spend time working on a project in my free time I want to work on something enjoyable, not something that is currently the Next Big Thing.

That said, even if actually making money is high tier goal I would advise (within reasonable limits) to stick with something personally enjoyable. First, the end product will reflect whether it's a work of love and passion or just a chore completed. Second, trying to get a piece of the (currently) biggest piece of cake is not always a good strategy.
Since so many people are working to push stuff out, your game is just part of a huge mass, probably unnoticed. It's probably not even any good at all since you made something completely outside your area of interest and don't have a good feeling what's important. You might not even finish before the Next Big Thing becomes the Bubble Which Just Burst.

Me, for example, I have paid quite a bit of money for various indie games over the last few years. Not a single cent went to any game in your statistics (nor will it in the future) because I have less than no interest in the "mobile games" market. You can just ignore me because I'm not mainstream enough or you can make a reasonable amount of profit in a niche not many people service.

A game developer technically isn't making a game, that's just an abstraction that we should put aside while coding. The developer simply makes a set of individual processes that emerge into a game experience. A great developer is someone how has a fine understanding of what processes fit together and have synergetic properties (i.e. features making eachother stronger, of which attack and move systems, or crafting and trade, are common examples). So think about it in terms of processes (or sub-processes rather, which makes up the main game process). Everything will emerge in due time. The only real difference between a AAA title and an indie title is the number of game elements (quantity) and how fleshed out each of them is (quality).

Reduce the scope of each task:

Create a long list of every single separate game element you want to have and then start designing the first few and very specific elements (usually the most general first and then the more specialized ones - main thread and screen updating/rendering, then basic move/offset logic, going on to sprite/model implementation (incl. player), then to interactions (of which collision, light maps and keybound interactions are derived (including combat and subwindows). I actually keep a sort of reference manual myself that looks more and more like some big Bradygames Game Guide. And later it may start looking like a flight manual.

At this point, you have a lot of choice for what you want to do next (combat actors/objects, non-combat actors/objects or non-combat activities like survival, creation, acrobatics, multiplayer chat, or more). Explicit story-telling is just another type of interaction (whereas implicit story-telling (the player's own story/experience) is just abstracted from the quality and style of other game elements, including the explicit story if any). What follows afterwards up until release are just looping through what I mentioned combined with testing, fixing and optimizing things as usual.

Also, I'm not sure you'd need Lua if you're also coding in Java (which is written superfast), but idk cause my experience with Lua is limited to Legend of Grimrock modding, only. My advice may also contain redundancies because I'm not sure if you want to make a game engine or use an existing engine (and which engine, if so).

- sorry, but in order to make a good RPG game, you need millions in investment.

That or time, productivity and patience.

As for Tablets, so that's a game style popularity Statistics for the year 2012.

(image)

Hello. Could you share the source or the author of that graphic?