Hey, I've made a quite a few mini-games and a small Platformer game and now I want to make a game with a story:)
I want it to be an 2D Isometric RPG with all the cliche systems an RPG has like magic, quests and dungeons..
I have a pretty good idea of what I want it to be like and it has high inspiration from the Elder Scrolls series.
The only thing I'm finding it hard to do is thinking where to start? I'm going to start writing the story when the basic game engine is done so if I feel like making a sequel then I wont have to rewrite the entire game.
I'm pretty pumped to make this but I don't know where to start in programming terms..
Should I start on NPCs and AI support?
Maybe the world and city support?
The game itself will be a file that I can load into the engine meaning that I can write my own mods.
I want the game to be very heavily based on magic.
Btw this is not a small project I'm hoping to work on this until September to a good standard.
I've written an rpg game engine before(one of my first projects) but it was buggy and cluttered in terms of programming.
The graphics were also bad because at the time I didn't know how to resize images in java but now I think I have pretty much all the knowledge needed to write a good game.
Now I just need to know where to start.
Also here is my website if you want to try any of the buggy mini-games I've made(don't bother with the applet on the home page): http://cmprogramming.weebly.com/portfolio.html
0
Where to start on my RPG?
Started by CryoGenesis, Jul 04 2012 01:11 PM
13 replies to this topic
Sponsor:
#2 Members - Reputation: 117
Posted 04 July 2012 - 01:16 PM
While I am not as experienced in programming as yourself, I would recommend creating a GDD (Game Design Document) first. This is not a 20 minute project as you may spend several hours or days on it.
By writing down all of your ideas and concepts, to include details such as sounds, music, graphics you want to do, features of your game, skills that characters will use, settings, world maps/dungeons, and so on, you can have a clear idea of the project in front of you.
Once this is complete, you have a road map to your entire project. Of course you can change things as you go along, but the framework is laid. At this point, you can now pick a reasonable spot to begin, such as developing the character and their skills, perhaps the progression system. For this, I'll leave it up to you and the advice of a more experience programmer in RPGs.
However, as you begin, you can simply work from this GDD, and you will be able to "check off" things that you've completed and work in some sort of linear fashion, making sure you aren't forgetting anything and capturing all the content you want.
Cheers. (I have a template of a GDD if you're interested)
By writing down all of your ideas and concepts, to include details such as sounds, music, graphics you want to do, features of your game, skills that characters will use, settings, world maps/dungeons, and so on, you can have a clear idea of the project in front of you.
Once this is complete, you have a road map to your entire project. Of course you can change things as you go along, but the framework is laid. At this point, you can now pick a reasonable spot to begin, such as developing the character and their skills, perhaps the progression system. For this, I'll leave it up to you and the advice of a more experience programmer in RPGs.
However, as you begin, you can simply work from this GDD, and you will be able to "check off" things that you've completed and work in some sort of linear fashion, making sure you aren't forgetting anything and capturing all the content you want.
Cheers. (I have a template of a GDD if you're interested)
#5 GDNet+ - Reputation: 1154
Posted 04 July 2012 - 03:08 PM
If you want to just get done with it, have you considered using a game engine to avoid this work and be able to get directly to the point?
If you intend on actually making the engine, I would believe that having created another engine before you have already went through some of the stones on the path. So this would be a little easier, even tho, once you reach unseen territory it'll be a new experience.
Anyway, I would start from the basics, how do I want to do maps? Using simple tiles? Ok, so you create a simple tile based map with an integer matrix representing textures. Simple map done? Now on to the drawable objects, such as the controllable character. A simple character placed on a location on the map. Now, how does he move? What are his animations? How do I work on the animations for the character sprites?
Great, now you have a base character that you can use to build enemies and npcs, being able to separate the npc behavior and enemy behavior in different entities, now that the components that all characters (player controlled, enemies, npcs, everything) have, are already done.
Long story short, what I'm trying to say is, I would take steps during which you would be able to see the progress and test fast. This is the way I build everything. Being able to actually make the minimum viable product fast will allow you to actually test how things work, find things you didn't expect when you planned, find gameplay issues, etc.
Making a design document can be a good thing if you have a billion ideas and you want have a great idea of how you want your game to be on the long run, but in my opinion considering the actual development, doing small steps one at a time and being able to see things working will give you better results overall.
If you intend on actually making the engine, I would believe that having created another engine before you have already went through some of the stones on the path. So this would be a little easier, even tho, once you reach unseen territory it'll be a new experience.
Anyway, I would start from the basics, how do I want to do maps? Using simple tiles? Ok, so you create a simple tile based map with an integer matrix representing textures. Simple map done? Now on to the drawable objects, such as the controllable character. A simple character placed on a location on the map. Now, how does he move? What are his animations? How do I work on the animations for the character sprites?
Great, now you have a base character that you can use to build enemies and npcs, being able to separate the npc behavior and enemy behavior in different entities, now that the components that all characters (player controlled, enemies, npcs, everything) have, are already done.
Long story short, what I'm trying to say is, I would take steps during which you would be able to see the progress and test fast. This is the way I build everything. Being able to actually make the minimum viable product fast will allow you to actually test how things work, find things you didn't expect when you planned, find gameplay issues, etc.
Making a design document can be a good thing if you have a billion ideas and you want have a great idea of how you want your game to be on the long run, but in my opinion considering the actual development, doing small steps one at a time and being able to see things working will give you better results overall.
A.
Lotus RPG Engine - My Journal: http://www.gamedev.n...die-rpg-engine/ |
Action RPG In development using XNA 4.0. | Blog in English: en.lotusrpg.com.br |
Personal blog In Portuguese: lotuzgames.wordpress.com |
#7 Members - Reputation: 194
Posted 04 July 2012 - 08:39 PM
Well obviously you need to have the story written somewhere for starters. After that you might want to start laying out the different concepts your game will include. These concepts will be useful to represent a low representational gap with your class objects. Perhaps making a quick domain model and a class diagram first will help you in avoiding those "shortcuts" you speak of.
These "chunky" programming you mention, do you write in OO or procedural code? Think of each object in terms of responsibility. What should "Entity A" logically do. I'd also suggest working in iterations. Start with the most difficult core functionality and review each step to make sure you are going in the right direction.
My experience mostly comes from business logic applications, but it translates rather smoothly to games if you plan things right.
These "chunky" programming you mention, do you write in OO or procedural code? Think of each object in terms of responsibility. What should "Entity A" logically do. I'd also suggest working in iterations. Start with the most difficult core functionality and review each step to make sure you are going in the right direction.
My experience mostly comes from business logic applications, but it translates rather smoothly to games if you plan things right.
Edited by DZee, 04 July 2012 - 08:40 PM.
I "surf" the web, literally.
#8 GDNet+ - Reputation: 1154
Posted 05 July 2012 - 11:22 AM
And in the end, planning game design will not help you in writing clear code. Perhaps you should invest your time in improving your development knowledge, learning a bit more about development patterns, since the problems you face seem to be regarding code itself.
A.
Lotus RPG Engine - My Journal: http://www.gamedev.n...die-rpg-engine/ |
Action RPG In development using XNA 4.0. | Blog in English: en.lotusrpg.com.br |
Personal blog In Portuguese: lotuzgames.wordpress.com |
#9 Members - Reputation: 440
Posted 05 July 2012 - 01:16 PM
I think my code is fine. When I work on small projects which are pretty straight forward and don't have too much content I can code them very well.
It's just when I'm working on a big project on my own which has lots and lots of different features it gets a bit harder to think where to start.
I actually can't wait to start on making this game.
It's just when I'm working on a big project on my own which has lots and lots of different features it gets a bit harder to think where to start.
I actually can't wait to start on making this game.
#10 Members - Reputation: 1050
Posted 06 July 2012 - 07:46 AM
Most IDE's (with the exception of the uber lightweight) should support splitting your project into multiple files. For instance I could have main.cs with my game loop in it and a seperate file called actors.cs with all classes related to animating the characters and NPC AI etc in it. By moving these classes out of the same file as my game loop it massively improves readability IMO. I suggest you look into these features if you haven't done so already, just don't break it down too far, I think game loop, actors and map should do nicely as a 3 file set-up. A 4th file with some more misc classes could also be added, shouldn't need to go further than that at this point.
Might help you manage this larger project.
Might help you manage this larger project.
#12 Members - Reputation: 1050
Posted 07 July 2012 - 05:20 PM
Ok, Set up your main game loop empty for now. Then in comment lines write what needs to be done in order which might be: read input, process input, run AI loop briefly, update character locations, draw. Change as you see fit. Then go from there.
#13 Members - Reputation: 194
Posted 08 July 2012 - 10:45 AM
Yeah I already do that in eclipse. It's not about how I do it after I start it's about where do I actually start at all ;D
Like I've said earlier, try to define your different entities as classes. Then look at their interactions with the rest of the system. Obviously you will have to tweak your initial analysis, but that's completely normal. It's also normal that you find bigger projects more difficult to keep organized.
Here are some guidelines to get you started with OOAD:
1-Think of the entities
2-Draw the domain model
3-Write generic use cases for what seems fuzzy(Such as, how will a player move around the world for example).
4-Make a class diagram with relations, use GRASP and think of Cohesion and Coupling for each of your classes.
5-When you are stuck on a part, review the GOF Patterns, perhaps one of them can help you with a specific problem.
6-Start writing code and keep going back to the domain model and previous steps to clarify your progression.
Obviously this isn't going in very much detail, I skipped contracts/glossaries and sequence diagrams for simplicity. This is what I do whenever I start a project with more than 50 classes. You can also look up architectural patterns(MVC is an example, but it doesn't map that well on games...), they can dictate how your classes should be organized.
If you are too lazy, then this is the most important principle in my opinion : Think of objects in terms of responsibility If you apply yourself during the creation of each class with this principle you shouldn't be too bad(Why should X do that, why should X have that, why should X talk to Y, does it make sense that X does this... and so on).
Edited by DZee, 08 July 2012 - 10:49 AM.
I "surf" the web, literally.
#14 Members - Reputation: 440
Posted 08 July 2012 - 11:26 AM
I've thought of a way to do it.
Have a base entity that has methods like move to place or interact with object.
Assign each entity with a script.
Run each entities script during game.
Have maps. Assign each map data file (position of entities). assign each map image file for the world.
Have a player. When a player does something a method in the Entities script is called for instance.
Player clicks on the NPC to talk. NPC's script is called at onPlayerTalk();
Something along the lines of that
.
Have a base entity that has methods like move to place or interact with object.
Assign each entity with a script.
Run each entities script during game.
Have maps. Assign each map data file (position of entities). assign each map image file for the world.
Have a player. When a player does something a method in the Entities script is called for instance.
Player clicks on the NPC to talk. NPC's script is called at onPlayerTalk();
Something along the lines of that
.
