My goal is to write a top-down 2D RPG(Similar to runescape classic, but much simpler) in Java using LibGdx. My main question is how I should structure my game? I've made a previous thread asking about Component-Entity Systems and that seems like a good option, but I want to explore my choices.

I want to be able to have a few XML or Json files with most of the game content in it, and I could read all the data into my game and have it create the required game objects.

So back to my main question, how should I be structuring this game? I would really appreciate any help or advice anyone can give me.

Thanks.

Everyone works differently but I can tell you that any game that I have actually finished has started with a design. The design does not need to be incredibly detailed, but you need something that outlines what you are building and provides a structure so that you can begin the coding process.

You would not start randomly building a house without at least some form of a plan. You might not have every square inch designed, but I think you would at least know how many square feet you wanted it to be, what you were using for the foundation, where your going to put the bathroom, ect.

Create a basic plan and use that plan to dictate how you develop the structure of your game. For a beginner there is usually no "right" answer. Yes it is highly likely that your code will turn to spaghetti and that you will say years down the road "I really wish I had done THIS!" but at that point you will know how to structure your next project (and you can then make a whole new round of mistakes!).

Some guidelines that I can think of off the top of my head:

1. Make an attempt to separate your game's data from the game logic. You mention XML/JSON and this is a good idea.

2. Favor composition over inheritance. Deep class hierarchies can make for deep headaches. Having to duplicate code from one class to another because you have forks in your inheritance tree but can't afford to put stuff in base classes can make for some ugly code.

3. Avoid making kitchen sink classes. Classes in general should accomplish only one "thing". In real life I have broken this rule more times then I can count, but don't go out of your way to write bad code (trust me, it will happen naturally).

4. If you find your methods becoming hundreds of lines of code, chances are you should refactor into smaller methods.

5. Avoid threads unless absolutely unavoidable. Threads add lots of complication and make problems harder to debug and solve. There are some situations where threads can be a good idea, but don't go overboard and use them very sparingly.

6. Finite state machines can help you implement your NPCs.

7. Scripting may be helpful for quests.

8. COMMENT YOUR CODE. You will look back on code months after you write it and have absolutely no clue why you wrote code a particular way. Future you will likely look and not understand why it was written a certain way. Usually I find that code is fairly readable on its merits, but the motivation BEHIND the code is what I need comments for. I might not know why I decided to use a particular approach if I don't have a comment to remind me why another approach wouldn't work or why the code looks hacky because there is a some reason for it.

9. If possible unit tests are a good way to ensure that your code is working appropriately. I must admit that my old games did not do unit tests, but the latest software design practices have been touting the advantages of unit testing code to find defects. It can be helpful to have some form of verification that your objects are doing what you expect them to be doing and it can help to verify that a change that you have made did not break the entire world. Java has JUnit for example.

Mainly you write code, refactor code, write more code, refactor more code, and repeat until your fingers are numb and your eyes bleed. When you run out of patience, money, time, or publishers are threatening to murder you if you do not release by the end of the week then you will be "done".

Everyone works differently but I can tell you that any game that I have actually finished has started with a design. The design does not need to be incredibly detailed, but you need something that outlines what you are building and provides a structure so that you can begin the coding process.

You would not start randomly building a house without at least some form of a plan. You might not have every square inch designed, but I think you would at least know how many square feet you wanted it to be, what you were using for the foundation, where your going to put the bathroom, ect.

Create a basic plan and use that plan to dictate how you develop the structure of your game. For a beginner there is usually no "right" answer. Yes it is highly likely that your code will turn to spaghetti and that you will say years down the road "I really wish I had done THIS!" but at that point you will know how to structure your next project (and you can then make a whole new round of mistakes!).

Some guidelines that I can think of off the top of my head:

1. Make an attempt to separate your game's data from the game logic. You mention XML/JSON and this is a good idea.

2. Favor composition over inheritance. Deep class hierarchies can make for deep headaches. Having to duplicate code from one class to another because you have forks in your inheritance tree but can't afford to put stuff in base classes can make for some ugly code.

3. Avoid making kitchen sink classes. Classes in general should accomplish only one "thing". In real life I have broken this rule more times then I can count, but don't go out of your way to write bad code (trust me, it will happen naturally).

4. If you find your methods becoming hundreds of lines of code, chances are you should refactor into smaller methods.

5. Avoid threads unless absolutely unavoidable. Threads add lots of complication and make problems harder to debug and solve. There are some situations where threads can be a good idea, but don't go overboard and use them very sparingly.

6. Finite state machines can help you implement your NPCs.

7. Scripting may be helpful for quests.

8. COMMENT YOUR CODE. You will look back on code months after you write it and have absolutely no clue why you wrote code a particular way. Future you will likely look and not understand why it was written a certain way. Usually I find that code is fairly readable on its merits, but the motivation BEHIND the code is what I need comments for. I might not know why I decided to use a particular approach if I don't have a comment to remind me why another approach wouldn't work or why the code looks hacky because there is a some reason for it.

9. If possible unit tests are a good way to ensure that your code is working appropriately. I must admit that my old games did not do unit tests, but the latest software design practices have been touting the advantages of unit testing code to find defects. It can be helpful to have some form of verification that your objects are doing what you expect them to be doing and it can help to verify that a change that you have made did not break the entire world. Java has JUnit for example.

Mainly you write code, refactor code, write more code, refactor more code, and repeat until your fingers are numb and your eyes bleed. When you run out of patience, money, time, or publishers are threatening to murder you if you do not release by the end of the week then you will be "done".

Thanks for the detailed reply, it's much appreciated.

1. Which would you suggest I use? I'm more familiar with XML, but JSON seems pretty simple. Given my needs (what you can extract from this thread) which would you preference?

2. I've been doing a lot of research on Component-Entity based systems, I don't fully understand it yet but hopefully I can figure it out soon enough.

3. This is a trap I've fallen into before and knowing this really makes a world of difference.

4. Same as 3 :)

5. Never really saw the biggest use in threads for most things. I mean, sometimes I guess they could prove useful. Can you give me an example just so I'm more aware?

6. I truly have no idea what this is, I suppose I have some googleing to do in my spare time tomorrow. Will read all about these and see what I can find out. From a glance, looks pretty interesting though.

7. I've heard people say this hundreds of times but was never really sure how something like that would be implemented. Any ideas on this? Should I store my items and skills/spells inside scrips as well?(Not the actual in-game items, but definitions of items) Or is that better off stored inside of a XML/JSON file?

8. I'll need to work on that for sure, I've always been a lazy commenter.

9. Again, something I'll have to google. Sounds pretty useful though.

1. Either really. I have more experience with XML but I really like JSON. XML tends to have support for more/older tools so if that is a factor it may influence your decision. If I were to start a project right now I would lean more towards JSON then XML though. I am not sure how good the support for JSON is in Java/LibGDX

2. Here is something that may help.

7. That is up to you and it depends on your game design. Generally static game data such as stats and values should be stored in a JSON/XML file where as content such as the triggers that make up a quest, ect should be scripted.

My thoughts are that most RPG games have various triggers or events that cause something to occur. An example might be that when the player arrives at a certain area of the map, that a boss is spawned. When the boss is killed it drops some special quest item. When the quest item is used with another area then another event occurs, ect. Your quests are then a combination of triggers/events.

I would think that the boundary of the trigger could be stored as part of the level file (defined in a level editor), the action that occurs when the player activates the trigger would be defined through a script, and the stats of the quest item could be saved in JSON/XML.

Your graphics rendering, physics calculations, generic player movement code, inventory management screen, ect could all be part of the game's "engine" where as any of the games content is specified through a combination of scripts and data files.

Keep in mind that all of this is just my initial assessment and it really depends on the nature of your game. Without knowing your game I can only speak very generally and even so the above is stated without reference to any form of a plan or technical design so there may very well be things that don't work exactly as I described .

The goal in my mind is to reduce the number of times that you have to recompile the game engine, provide the ability for designers to help create game content (and potentially open up a modding community if desired), organize code through separation of concerns (IE the interface between the game engine and the scripting provides a sort of boundary between the potentially reusable and the game specific), keep hard coded values and game data outside of the code so that it is easy to change and tweak, and allow it to be possible to add significant content to the game without proportionally increasing the amount of code that needs to be written. Everything else is frosting. If these are your goals then use them to guide your design!

I'm not entirely sure on how to implement scripts into my game. I see now what I would use them for, but I'm still not sure how I would add them. Is there some sort of API that I'd need to download to embed them into my game?

Also, which scripting language should I choose? I've heard a lot of people using lua recently, is there any merit to this?

There are several choices. There is Scripting in Java ( a top google result) and things like LuaJava.

Lua is a perfectly capable scripting language. You might not even NEED scripting, but it can be helpful in some situations. Use the scripting language that provides the capabilities you need and that you like.

Choice of technologies is largely arbitrary until there is a project specific reason to pick one over another.

Different languages/technologies exist because a developer or developers looked at what was out there and did not like it or they needed it to do something different then what it does. When your needs correspond with the needs of the developers that wrote it or when your sensibilities correspond with the sensibilities of the developers that wrote that particular technology, that is when you pick it. That is why we can't really tell you what to use in every situation, because it depends on you and your project!