Scripting an RPG

[n321]

Hello,

I stumbled on this old, but interesting, set of tutorials that may be useful to some. I am finding them to be of some use.

I have very little programming knowledge, enough to put together a small game launcher app. It has been my goal over the last few months to learn scripting in udk with the goal to, in time, get a decent RPG prototype working. Problem is, I’ve worked with some Quake 2 code and a little Quake 3 but that is just modifying what others have worked hard on.

The issue for some, including me, is not just syntax...Its also the technique of programming in an oop environment. One of the real hard things to wrap my head around is how an RPG would be structured, how the code would look. That is why this set of tuts is helping me. Is focused on a beginner and teaches them to write an text based RPG in C++. Most programmers would tell you you learn by the act of practice. In this series not only would you learn some syntax but also oop design and how an RPG can be structured.

Now some will look at this and say eeewww a TEXT RPG. Well this is true, but lets think how it can relate to UDK. Uscript is similar to C++ in the way that it is oop, code structure is similar, and some C++ syntax is supported. The first part of prototyping many things begin in the background. For example, when designing the XP system I am now using I started with the one purpose of having the engine keep track of XP and print it to the console. With this in mind MUCH of the knowledge in these tuts can be adapted to understand how it could be done in UDK. Everything from inventory to XP, It all happens in the background in code and then is attached to visual objects to represent what is happening. To add to my XP example, When you open up the player menu in a game and see your player standing there and his stats listed beside him, That is just a UI calling for the value of a given piece of code. The same goes with many things like inventory or dialogue or events.

Anyways, I feel that once one grasps how oop works and then how it can be used to structure the code for a RPG one would be well on their way to being able to design one. Once the code is in place then one could add the visual representation making a text rpg become a 3D rpg. Now of course one would need to learn to understand the many intricacies of Uscript but I think that as its syntax is more similar to java that is not so bad, its more the structure and design that gets my brain smoking.

Any who, take a look and maybe it might be useful to you! :)
http://tlundmark.blogspot.com/2006/01/programming-rpg-in-c-video-tutorial.html

[Prezadent]

This is a text adventure tutorial for C#. Although it is part of XNA series, it is just an introduction to C# and oop. Watch the
Intro To Hyperion for an overview of the game.

http://www.3dbuzz.com/vbforum/sv_videonav.php?fid=e4da4800d407d5304c121d86f9f2a9 7d

[Prezadent]

Also, this may be of some use in making an UDK RPG
http://www.fileplanet.com/187714/180000/fileinfo/Unreal-Tournament-3---BattleRPG-V10.1

[JasonG]

I've been a developer for over 15 years and I've seen far too many people chase their tail with software projects because they focus too hard on trying to do something "right" rather than making something work first. I would focus on just making something work and then refactor your code to be right later. In fact, don't even worry about performance that much until you have something working.

The reason I say this is that so many people focus on making things work "right" that they never get anything done at all. Furthermore, I see many people solving performance problems that that they think will be a problem and then it turns out the perceived performance problem never manifests itself. This leads to lots of wasted time, effort, and code on fictitious problems. Dont' try to solve performance problems until they actually show themselves to be problems. I'm not saying be stupid, if something is obvious, handle it but don't spend days and weeks thinking about every possible problem that "might" show up either.

So in short, I wouldn't worry about the "right" way to build RPG elements for your game. Many times there is no "Right" way, there's just the way it works for your game. So just use what skill you have in coding to make something work and don't worry about the rest of it until you have to. Its way better to have something that works but may not be perfect than to have something that's perfect but doesn't work. That may sound like an obvious statement but there are quite a few zealots out there that put more focus on "Right" rather than "Works".

1. Make it work
2. Make it work right
3. Make it work fast

[n321]

Thankyou for the insight JasonG, I agree. Tho I think My issue is the Getting it to work in the first place part. I Struggle with the idea of oop alot and then there is trying to apply what i want to happen to understanding how to make it happem. I understand how alot of these systems work but its nice to see how they work in the background.

[Builder_Anthony]

I basicly started all my building experience from the game neverwinter nights.Its a dungeons and dragons rpg.There is alot of scripts set up for rpg in that game and some nice people as well.Monday there swicthing the forums over but if you do a internet search for nwn scripting itll take you right there.Better hurry though there moving the forums over to bioware.Otherwise youll see about 1000 pages of scripts.Shame there erasing all of that but well be able to post screen shots in the new place.


Im also intrested in a rpg game style.Im very new....3 days into unreal but im not sure if i should redo my game into unreal or start another all together new game.Its hard because i spent three years on a completed and gametested game.So it be easy to go that route but i kinda want to flip pages and start on a furturistic game now.Hope this helps some.

[carlb]

One of the most difficult parts is working on art assets. When you're tired of doing that, then tweak and modify your scripts so they work like an PRG.

After all, almost everything you do for a FPS will end up translating into a RPG unless it's really narrow of scope.

Baby steps, my friends!

[Snufkin]

I cannot wait for your RPG Tutorials Raven!

[Deliverance6]

In response to JasonG's comment a few posts up, i entierly agree. Making somthing work is more important than making it right. If you look at commercial games released within the last 5 years, you'll notice a trend of "slacking" has developed, where a game is rushed out in a half-beta state instead of being properly polished (ut3, Oblivion, Fallout3 etc).
Providing the majority of the code works, even if it doesnt work well, then you're on the right track.
Having only recently learned advanced coding in C++ (worked with Darkbasic and ObliviScript for near 8 years though) im finding that ill write a code section, and once it works focus on other areas. When im sick of those "other" things (like art assets or a level or whatever) then ill go back to the code and try and re-write parts of it for optimization.

On the subject of OOP (Object oriented Programmging), i had grown to hate it after years of working with the Gamebryo engine, but after 6 months working with Uscript and UT3 you do get used to it. If you know other languages to start with then its an extra pain but if you persevere you will get there. The fact that epic bundle dev-scripts with their releases is a huge bonus, because when you're first starting out then you can see how other aspects work and then try and emulate one before starting your own code base.

[TheDopefish]

http://tlundmark.blogspot.com/2006/01/programming-rpg-in-c-video-tutorial.htmlWhoa, cool, that's my blog :D

I'm glad it could be of use for someone atleast ;)

EDIT:
Damn it, in my amusement I accidently necro'd another old thread :(