Jump to content
  • Advertisement
Sign in to follow this  

How to structure a 2d RPG?

This topic is 2168 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.



Share this post

Link to post
Share on other sites

I think you should start writing code at this point. Planning is good, but the scope of your question is too broad, suggesting that you need more experience. Just get started and make some mistakes. We can work from there, once there's actually something going on.

Share this post

Link to post
Share on other sites

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.

Share this post

Link to post
Share on other sites

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 smile.png .


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!

Edited by shadowisadog

Share this post

Link to post
Share on other sites

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?

Share this post

Link to post
Share on other sites

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!

Edited by shadowisadog

Share this post

Link to post
Share on other sites

Most of the structure of any game will just emerge naturally from you programming the game in the right order with the right focus on specific problemsolving. You don't really need to plan out too much, other than the obvious research of how 2D rpgs function (which will give you a knack for producing content as needed, depending on the depth of that research). Play some games, pull them apart and study each of their mechanics. Then just add what you want to see, step by step, into the gameframe.


Keep it simple. The complexity of certain classic games are often a direct result of the developers being able to keep things simple, because this is what allows them to add complexity later on, when the basic infrastructure is rock solid and easily expandable systems are in place.


1. Get some mindmapping tool (e.g. XMind or w/e) and start dotting down everything you want to see in the game. Be imaginative and just brainstorm. Don't sensor yourself or think realistically just yet. That'll come later.


2. Try getting an idea of what you need to prioritize first and then get back to more advanced features later. Realistic implementation will be a natural result of setting clear priorities for yourself. Just prioritize what you got and see where it takes you.


3. Plan your coding structure somewhat. Don't spend too much time on this, but try to get an idea of how you want classes to group up, how things relate etc. Make some flowcharts.


4. Make a frame (window)


5. Make a game loop (one that either runs the entire loop or initiates the first of several game loops, e.g. one for each stand-alone frame - launcher, options, chargen, gameview, world map, etc).


6. Render something basic on the initial loop and from there, you can add new stuff that's within the confines of that individual frame.


7. Playtest rigorously. I like to differentiate between system/function testing (which you do every time you add new code) and game testing (playing the game as a player, which you should limit to short periods after some time and several systems have been put into place).


8. Now add whatever in whichever frame or underneath the hood, but be very specific. Think top-down, but do go all the way down as much as needed.


It's my firm belief that, if you follow this basic ruleset and repeat the process over time, a solid game will simply emerge out of it. Take it step by step, make it into a set of smaller problems that you need to solve in a given order. It shouldn't even matter what language you're using, as long as you're familiar with methodology and syntax. And if you're not, then you shouldn't be asking this question to begin with.


Oh and one more thing:

Don't think... feel! It's like a finger pointing a way to the moon. Don't concentrate on the finger, or you will lose all that heavenly glory. biggrin.png

Edited by Malabyte

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!