Sorry your browser is not supported!

So, I have a project idea in mind, and quite a bit of the framework is already finished (see also-Code Snippets).

I want to do a full-3d RPG game. I have a working story, a layout of how I want the battles to go, and quite a bit of experience with my chosen platform (DBP)

I want to know from those who have already completed projects, how do you know if you're ready to take something on? How do you go about it?

I also want to know from my forum friends (MrValentine, nonZero,PHAELAX , Virtual Nomad) if anyone would be interested in doing a fantasy RPG under my leadership. I imagine I'm not asking as much as reaching considering I'm the least versed in the code of any of you, but I still thought I'd give the asking a shot.

MrValentine, Reporting for duty!

I would possibly be able to help with environments... and later Textures... and possibly more under disclosure

Regarding knowing when the time is right...

I think it would be when you have broken the majority of your project down into chunks, assessed if you are able to piece them all together successfully, and foresee a working demonstration, and not to mention having a Game Design Document [GDD] at the ready!

More on this topic shortly, Stay Tuned!

Good assessment, I'd agree with that as far as for expecting to complete the project, but even if you arnt there yet any project attempt will help you learn and improve, particularly the large complex ones. You've got nothing to lose, sounds like you have some good prep done, so I'd dive right on in people joining in or not

With any large project, make sure it's modular. That way, you can come back to it at any point and if you've improved on something, you only have to update the modules and not go through tons of code looking for all the hard coded parts.

To my knowledge, in 12 years of existence, nobody has ever completed an RPG in DBP. The closest to success was probably Geisha House. With that in mind, good luck!

OOooooooo, that sounds like a challenge - one that I may take up on (one of these days; but not now )
Go for it Mr909!!!

My advice is to plan it out as much as possible before you start any coding, and work steadily towards the goal. As others have mentioned, having things modular is best and start with the skeleton of the end product i.e. use placeholder objects and models to begin with and flesh them out later when the mechanics are all working.
Better to have a plain bare bones working game than a very pretty not working game.

Fair point. But does DBC count? I'd probably class Soulhunter as an RPG, at least it was kinda Zelda inspired.

It took a long time to produce, but it's a damn good game.


But the main trouble with creating an RPG is that it is a lot of work. Generally I would suggest to make it manageable and to not over complicate things. It'll be a long project and that's generally why they tend to fail. If you get too ambitious, you'll throw yourself off course, hence I am refusing to even touch my 'Ronin' project now. Abeyance on the other hand is a much more manageable RPG, and even that's going to take a lot of work.

Having a good plan and an engine (and make it modular as Sasuke has said) in place would help you a lot, so you can create the content more effectively. Starting with placeholder models for the media will help you focus on the coding side more - the TGC store has some great content there and heck, FPSC allows you to export scenes.

The engine I am working on for Abeyance (a 3rd time this year ) is modular, the original one wasn't, but this one is. It'll make all the difference to development. I am using XML scripting, so for each level, I can just add to my XML scripts and any changes in source code will affect the game as a whole because all the code is doing is reading those XML scripts and then using any logic I've coding to interpret the data. The bonus to XML is that you can create XML files in Microsoft Access.

Although I am in the early stages of the rewrite, I have my level loaded using XML data. I've split the data into several databases - so there's a 'level' database, an 'NPC' database, 'items', 'waypoints' and so on. So in NPC.XML, I'd have a variable called "room" and it'll match the name of the room that NPC will appear and it'll also have coordinates for placing it in that room. Here you can see an example of how I'm using XML to load data.



There's 2 sets of data displayed on the screen, both are inside of level.xml, the first is the current level that's loaded, the second is the next zone. This database will assign 'names' to each room, it'll load the level file and it will place the camera and set its target.

Extra data I could add for the engine to read could also be 'zone' points and they'd be in waypoints.xml and it's 'room' variable could be 'bedroom' and that waypoint will have a target level of 'corridor'. So when the 'bedroom' level is loaded, that waypoint will be created.

It'd all be determined by the data you put into the script and your game engine only has to read it. This way it's modular and much more manageable. I do have a sample of a very basic text adventure engine using LUA laying around that should help demonstrate how it works. I'd have to dig it out.

There are alternatives to XML in DBP, there is LUA and Dark Data too, or you could even create your own script parser (Goga's string plugin will probably be helpful in that respect).

If you've never set up a scripting system, it might sound confusing, but it actually makes things easier and reduces the number of times you have to compile your project and there's more than one way of approaching scripting. The way I've explained it is how I'm using XML for my project. The way I'm doing it actually allows me to use Microsoft Access to create my scripts. Other people may do it differently.

For more information how that works, click here.

No, none of that counts because then I'd be wrong, and as you know, that is completely unacceptable for my street cred and air of mystique, so just ignore that and never ever speak of it again.

That is Latin, meaning know thyself.

Being ready is like being in love. No one can tell if you're in love, you just know it. Through and through. Balls to bones.

TheComet

Ha! Gayyyyy... I joke

As someone who started an RPG and then realized just how much work there is involved I have to warn you that there is a lot... If you really want to completely finish one, then I suggest you make a very detailed plan, and make sure you know exactly what you are going to do before you do it...
Not doing this was probably one of the main things that made me get fed up... A huge mountain of coding is a lot easier when its broken down into half-hour steps

Hush, I still don't know for sure if I'm ready yet.

I think I'm going to just wait until I get the computer I've been eyeballing. I plan to get the Bonanza pack on there, and then I'll have enough resources that, hopefully, I'll be able to do most of it on my lonesome.

So... that could be anywhere from two weeks to six months. Bleh. Oh well. In the meantime, I guess I'll keep working on the framework I've been developing.

Knowing if you are genuinely ready is a difficult one, because you've never taken on something like this and it's not easy to predict the future or necessarily know your own thresholds before it goes under way. Your own naivety can get in the way too. Bear in mind just because you've got the skills doesn't mean you've got the endurance and determination to see it to the end. You might be good at a 500 metre race but can you run a marathon?

The good thing when you start a project is you're excited by it, you're getting lots of ideas and you feel really good about it and that motivates you and you might get some good stuff out, then you've go to keep that momentum going and to have that drive to see yourself past the 500 metre line and then past the 1000 metre line and so on until you reach the end.

But I think there's things you can do to make the run easier. Know your own skills, do you have the ability to actually code this? In other words, are you a good runner? Bear in mind, you don't have to be Linford Christie to run a marathon, people who aren't very athletic pull it off. Likewise, you don't have to be an awesome coder to be good enough to complete a big project.

Then you need to have a good plan and it has to be based around your lifestyle and it's got to be a plan you know you can stick to. In a coding session I think it's good for motivation if you can have achieved something by the end of it, rather than walk out with half-a-job. I'm not saying sit down and make a highly organised plan and stick to it by the letter, I mean it would be unnatural and of course you're not going to predict everything, you'll develop new ideas and want to work them in, you'll want to change things and so on. The important thing about your plan and your goals is 'realism'.

It's the realism that relies on how much you know about yourself as a coder. This is where projects tend to fail. Is it realistic to think you'll have a large, high fantasy RPG with lots of characters and classes? Throw in a really dynamic battle system? If you're a one man band, especially if you're not a pro, then that's highly unrealistic. But can you still code an RPG? Yes. But that largely rests on you.

Use me as a cautionary tale if you must. I will compare 2 RPG project ideas.

Ronin - Turn based RPG with 3 characters in a party, maybe 8 or 9 characters in total for you to choose from. Each will have a different skill sets (and animations) and different specialism. It'll be a large world setting with multiple towns and cities. Do I have the skills? I can definitely code all that, I have the know how for each system and have prototyped many of them. How realistic? Not very, it's pretty damn big project for one guy to work on. I've failed many a time. I barely even get a demo out.

Looking at the scale is actually kind of overwhelming. Believe it or not, this was my first Dark Basic project, which is nuts for somebody who was pretty new to game making. Each stage of my learning, I've attempted to get the ball rolling. My latest attempt was actually this year and I would say I am a capable programmer and I was getting some good stuff done and it was my most realistic attempt yet - I had answers to how to make the project manageable. But, I knew I'd need to put it aside, because it would be better to do something smaller...as much as I'd like to see this project out there.

Abeyance: I've released 2 fully playable demos this year (one was 2D on 3D in DBP, one was full 3D in DBP), almost a 3rd (in Unity3D). Yes, I've had some indecisiveness, but it's a LOT more realistic. There's one character to play, there's no large world settings, no additional weapons or armour and the maps are fairly simple, there's not a lot of characters and enemy types. The battle system, whilst similar to Ronin's is a lot less complex. There's still 6 classes, but the way they're designed means I can use a limited number of animations (maybe 4 or 5 in total and rely on particles for the rest). How the player uses the classes is different enough for them to be different classes - different moves have different tactical advantages. This means less media, less coding and now that the engine is being coded in a modular way, it'll be a lot easier to take on the big stretch. It's still an RPG, it'll still be a big project, but something I can do whilst I still have a full time job.

If it helps, you're welcome to look at how it progressed. For the first demo it took me one month and the same for the second. You can see how I've tried to keep 'simplicity' and 'manageability' in mind. It's still a WIP, so it's not an example of success, but it is a sample of something manageable for a man band and somebody who isn't a professional.

Very true, wish I knew not to over plan things many half finished projects ago.

As others have said, split it into manageable chunks. When I code, I try to encapsulate everything in C++ style classes by having code that relates to each different 'item' in its own file.

e.g. scoring/life display class, player class, etc.

If I have several 'enemies' on screen, I create an 'enemies' container class that then creates and manages its own list of enemy entities. Messages are passed to the enemies container class, e.g. enemies_ResetAllEnemies() using functions. Each container class has its own Update() function, which is called in every iteration of the main loop. The container class then calls its children's Update() function as it deems necessary.

e.g. in pseudo-code:



This way, it's clear who has ownership of what, who is responsible for deleting and initialising what, who each variable belongs to, etc.

I go so far as to have each class responsible for loading and creating its own resources; that way, when the resources are lost, e.g. by the user changing the screen rez, all I have to do is call game_RezChange() and each class recreates and reloads what it needs to:



Just one way to do it, but it works for me!

As your projects get bigger, keeping track of ownership, and who sends messages to who, becomes increasingly more important. In my examples, I would not have the gamecontainer class sending a message to an enemy entity directly - it would do it via the enemies container class, which has responsibility for sending the message and reporting back appropriately.

HTH,

James