Beginning A Zelda-style Rpg Game

[javaJake]

I'm not really sure if this is the right community to be asking these sorts of questions. Everyone seems so knowledgeable and helpful in the Development forum, that it seems like it's the place to be if you want your questions answered.

If there's a different place I should visit instead, I'll be happy to move my post elsewhere.

I'm looking into writing my first real game, and I want to write it primarily for the Pandora and its control scheme. I attempted an MMORPG, but after two years of development, life did it's curve-ball thing, and I ended up canceling the project. I got discouraged. The GUI was only just starting to appear, I could never explain the game idea, it being unique enough, so I never got feedback (at all), and I had been using Java for 4-5 years, and I knew if I wanted to expand my specialized toolbox, I needed to get a project in something like C++.

So, here I am. A Java developer who's only just learned the fundamental C++ concepts, and he wants to start writing code for a game in a few months.

My biggest obstacles, and what I need your assistance with, are the following:

• I'm looking for a game engine with the following features:Entirely event-based game engine. For example, if any character moves a pixel, an event is fired. If a gun shot expires, an event is fired. A timer concludes, an event is fired.
• Every AI object that runs within this engine should all have an array/vector/variable that it writes state information too, so it can be saved and loaded easily to and from save-states.
• I'd like any AI object to be available to any other AI object via the game engine for inter-AI communication. The GUI should be layer-based, and allow the manipulation of pixels for different effects, like fog, distortions, etc. I would like the layer priority, and perhaps even the event system to be relative instead of numeric.
• The entire thing should be simple and self-explanatory, too. I want to hit the ground running without having read 20+ pages of documentation first.
• If I have to, I'll write it up from scratch.

[*]This thing is going to be very, very multi-threaded, being event-based. Timers should be events, for example. How do I make objects, functions, and variables thread-safe individually and/or as a whole?
[*]I've heard that SDL can be rather slow if you push it too far. I want to be able to apply filter layers to my tile-based GUI for various fades, wavy distortions, and particle effects. Will SDL allow me to accomplish these effects efficiently?

 

[PSyMastR]

int * x;
char * l;
double * pizza;

 

[todd]

JavaJake,

Here's a shameless plug for Pandora Panic.

I'm a Java developer by day. Historically a C programmer. "Always" wanted to learn C++. Pandora Panic is based on SDL and another, very simple, framework on top ("Penjin"). The project is coordinated by the author/maintainer of Penjin. It's very easy to write for and the nature of the project demands quick, simple, one-off games. A great introduction to coding in C++.

This doesn't answer any of your real questions below, but I offer it of a hint as something fun to do in the meantime. You can scratch up a game in a weekend.

FWIW (and not to start a religious war)... I've become a great deal less enthusiastic about learning C++ since working on PandoraPanic a little. I've begun asking myself why I care to go back to the bad old days of pointer arithmetic and manual memory management. And the overall syntax/structure of C++, being essentially a macro package laid over top of C, is a massive trainwreck! Java is none too pretty, but there are some things I appreciate about it which I think are real improvements over C++. Of course, there's a tool for every task. But I'm really starting to feel like C++ is a step backwards from Java and I'm not so eager any more to go there.

I'm looking forward to seeing another compiled language hit it big. Probably something which lends itself to concurrency on multi-core CPU's. But I wonder whether the days of a single dominant language might be numbered, if not already over by a decade.

In the meantime, here's hoping for a JVM on the Pandora in the near future. Java, JRuby, Jython, Groovy, Scala, you name it.

You didn't ask for my $0.02, but you caught my attention as I seem to find myself in a similar position to yourself.


--Todd

 

[cb88]

java is using over 150mb of my ram right now just to run netbeans.... THAT is why you should code in C/C++

 

[sinoth]

I don't think I have the answers you're looking for but I'm gonna do my best. To put my response in perspective, I'm a "roll your own" guy... there are some things that I don't mind using libraries for (such as std:: and boost:: stuff, as well as low-level libraries for sound, network, etc) but for the most part I think it's healthy as a game developer to work through a lot of these problems the hard way. Especially if it's the first time you try to do something, such as the AI you mention... I really don't think you'll find an acceptable pre-made solution, or "magic bullet".

* Entirely event-based game engine
I haven't heard of an easy framework for this, but I also haven't looked very hard. I think this is more of a central design decision to make early and try to conform as you build your framework. Might read up on some stuff here.

* AI objects ... saved and loadbed easily to and from save-states
This should be pretty easy, unless I'm over-simplifying the solution. I think you should be able to just have a list of all active AI objects (player, NPC, whatever) and give them a "writeState" action that spits their current action, stats, location, etc to a file. When you want to save state, just traverse this list and call that function on every object.

* inter-AI communication
Again, I think this shouldn't be too complicated to do on your own. Since you want stuff event driven, you could have an event that places messages in another object's event queue. For example, monster A could try to get monster B to follow him, and to do so he would insert some kind of request into B's queue and when B got around to process this, it would decide how to act on it.

* The GUI should be layer-based, and allow the manipulation of pixels
Sounds like you're gonna need a framebuffer. I've never used SDL for the framebuffer so I can't comment here.

* How do I make objects, functions, and variables thread-safe individually and/or as a whole?
You could probably write a thesis on this topic. In short, there is no magic library to make this easy. You're going to have to understand multi-threaded design and work around it. The concept isn't too bad... basically, you're good to go unless multiple objects need to access a common resource (such as terrain information or a monster's hitpoints). For situations like this you have to lock resources if a change is going to take place, or else you get one object reading while another is in the middle of writing and you get some funky results.

It sounds like you pretty much know what you want to do, you just don't want to reinvent the wheel. While that is a good mentality, it's easy to slip into library-scumming mode and not really get much done. I highly suggest jumping in head first as long as you trust yourself to keep up motivation and direction. Your MMORPG project probably stalled because you couldn't produce visible results to keep up motivation. I would suggest making an extremely simple game with some of the concepts you have in mind, and build from there.

 

[sindbad]

1. There was a port of python's Twisted to C++ which could be of help. There are some other libraries as well (libevent is for file events for example).

2. There's nothing like python's pickle or even java's serialisation to help you with this. Do it the hard and slow way.

3. As long as you don't try to make each AI into a thread (which would be a bad idea because of performance), it shouldn't be too hard.

4. There are GUI libraries for SDL that do that too.

5. message passing has always saved me when I needed a resource across threads. I remember reading of a small C++ library that did something similar, but it's hard in such a static language. Try, if at all possible, to make your threads behave like daemons or workers.

You might want to have a look at the Vala programming language and remember it for the future. C#-like syntax (so also java-like) which compiles to gobject C that is about as fast as C++ or even C.

 

[PokeParadox]

Here's a shameless plug for Pandora Panic.


Haha, shameless plugs ftw :lol:

On that note Penjin itself may be a good starting for you, it compiles to SDL or OGL and I'm adding further renderers in the future (let's get PandoraPanic! out the door first ) I would not be objectionable if you wished to take Penjin and extend upon on it, although many of your ideas mesh with my own so perhaps we'd be best working together to complete the common goals?

To address some specifics:
Event-driven engine - My friend has similar ideas where every object can send messages to any other. He is a busy guy and still hasn't finished our website, however :rolleyes: . But Karurosu certainly thinks something like this is possible.

Saving Loading - This just depends on how you set things up and what you need to save. What springs to mind is that you could have a central SaveManager and just give the pointer to anything that needs to save it's own variables... or conversely... you could have the manager add pointers to the relevant variables it should dump to file at init time and just have it dump the contents to file whn needed... the second option sounds better to me.

Layers and Pixels - SDL does supports layers (multiple surfaces) and also pixel manipulation... I'm not sure how to change pixels in OGL (I'm thinking it's going to need a fragment shader...) I can set pixels but not get their current colour, etc.

Thread Safe Programming - Yeah... one of my module whilst at uni was concurrency... it gave me headaches only thing I can suggest here is read and avoid the traps. If you use any libs find out which functions are thread-safe, etc.

 

[Capn_Fish]

OpenGL (ES, more on that later) with SDL is probably your best bet. OGL supports fog and stuff, and SDL is darn good at input stuff.

(The following is the impression I have gotten. I've not actually used OGLES yet)

OGLES code should work fine with any OGL implementation, but it only uses the best parts of it, forcing you to code nicely.

HTH

 

[TheGoodDoktor]

Hi

If you want to do an event based system (which is a good idea) in C++ then I would recommend that you:

Write a base class that you will derive all your game objects from with:
A virtual message handler function that you pass the messages too
A serialise and de-serialise virtual function that you pass some kind of object that you serialise to

Write a game object list class that will:
Add created game objects to itself
Use to send a message to a specific game object.
Allow you to be able to broadcast a message to a range of objects

The important thing to remember it that you should only modify an object's state in it's message handler, never access the object directly in code except for queries which you should do through const functions. You then have a clearly defined point where the data in your objects is modified which should make multi-threading easy (well easier, it's never easy!)

The serialisation methods should store and re-create the object's current state using some kind data stream (you could use a simple byte array if you like)

The is just some basic information to get you started, the rest should come naturally.

Good luck!
TheGoodDoktor.

 

[efegea]

I'm going to recommend the book I'm reading:

3D game engine architecture, by David H. Eberly

Only the beggining of the book is already covering some of these points (I'm still on page 129 of 735) and the book is very good.

EDIT: although it's not clear what kind of game you want to do, 3D or 2D. Anyway, a lot of things the book covers are applicable to 2D engines..

 

[javaJake]

Edit: Quote fail! I've italicized the quotes so they're easier to read. Could a mod could split my post in two?

I don't think I have the answers you're looking for but I'm gonna do my best. To put my response in perspective, I'm a "roll your own" guy...

I'm the same. I'd really rather not learn a new library, but sometimes it is the best in the end.

there are some things that I don't mind using libraries for (such as std:: and boost:: stuff, as well as low-level libraries for sound, network, etc) but for the most part I think it's healthy as a game developer to work through a lot of these problems the hard way. Especially if it's the first time you try to do something, such as the AI you mention... I really don't think you'll find an acceptable pre-made solution, or "magic bullet".

This is quite possibly true, but on the other hand, there are often solutions out there with goals very similar.

This should be pretty easy, unless I'm over-simplifying the solution. I think you should be able to just have a list of all active AI objects (player, NPC, whatever) and give them a "writeState" action that spits their current action, stats, location, etc to a file. When you want to save state, just traverse this list and call that function on every object.

I am also thinking along these lines for save-states. I really would rather not serialize entire objects and whatever junk they come with, so it seems like the only other alternative was to make some sort of place to store object-specific state information. But I wanted to be sure this was the only alternative.

Sounds like you're gonna need a framebuffer. I've never used SDL for the framebuffer so I can't comment here.

Now that you mention it, framebuffer sounds vaguely accurate for this sort of situation. Thanks for the hint, I'll go peek around the 'net.

Your MMORPG project probably stalled because you couldn't produce visible results to keep up motivation.

Actually, someone else had already done it before. That's a real project killer right there.

There was a port of python's Twisted to C++ which could be of help. There are some other libraries as well (libevent is for file events for example).

Not quite sure what you're suggesting. I'd rather write in pure C++ for best efficiency and readability, and I won't need to do much with files besides the occasional write for save-states and numerous reads for resources.

There's nothing like python's pickle or even java's serialisation to help you with this. Do it the hard and slow way.

OK. Array it is, then!

As long as you don't try to make each AI into a thread (which would be a bad idea because of performance), it shouldn't be too hard.

Oh... OK. Well then, I'll keep it to as few threads as possible.

message passing has always saved me when I needed a resource across threads. I remember reading of a small C++ library that did something similar, but it's hard in such a static language. Try, if at all possible, to make your threads behave like daemons or workers.

When you say "daemons or workers", what are you thinking of?

You might want to have a look at the Vala programming language and remember it for the future. C#-like syntax (so also java-like) which compiles to gobject C that is about as fast as C++ or even C.

I'll take a peek, thanks! I may decide against this, since I'd like to learn straight C++.

On that note Penjin itself may be a good starting for you, it compiles to SDL or OGL and I'm adding further renderers in the future (let's get PandoraPanic! out the door first ) I would not be objectionable if you wished to take Penjin and extend upon on it, although many of your ideas mesh with my own so perhaps we'd be best working together to complete the common goals?

Penjin? Is this the GUI core for PandoraPanic?

Thread Safe Programming - Yeah... one of my module whilst at uni was concurrency... it gave me headaches only thing I can suggest here is read and avoid the traps. If you use any libs find out which functions are thread-safe, etc.

I may stay away from threads as much as possible, at this point.

OpenGL (ES, more on that later) with SDL is probably your best bet. OGL supports fog and stuff, and SDL is darn good at input stuff.

While OGL sounds interesting, it also doesn't seem to provide the pixel manipulation I'd like for some more custom animations that don't come by default in the system.

Write a base class that you will derive all your game objects from with:
A virtual message handler function that you pass the messages too
A serialise and de-serialise virtual function that you pass some kind of object that you serialise to

I understood and agreed with everything except the last here. What specifically is the bolded object's job?

The important thing to remember it that you should only modify an object's state in it's message handler, never access the object directly in code except for queries which you should do through const functions. You then have a clearly defined point where the data in your objects is modified which should make multi-threading easy (well easier, it's never easy!)

Ah, good point! I hadn't thought of this before.

The serialisation methods should store and re-create the object's current state using some kind data stream (you could use a simple byte array if you like)

Yea, the data stream is probably going to be some index or array of information about what that particular object is trying to accomplish.


Thanks everyone for your posts, you've all been very very helpful.

 

[PokeParadox]

Penjin? Is this the GUI core for PandoraPanic?

Basically it's a homebrew game engine been developed in my free time since about... hmm... 2 years or so ago.
But yes it's at the core of PandoraPanic! lot's of room for improvement but PandoraPanic! is helping this and I have my own list of things to do which share some of the ideas discussed here. It's 2D engine but I have some code working in 3D/OGL. I need to sort a proper camera out before 3D is useful.

 

[Klaus]

java is using over 150mb of my ram right now just to run netbeans.... THAT is why you should code in C/C++

150MB to run a fully-featured IDE? Doesn't sound too bad. I'll bet Visual Studio is not that much less memory hungry, but I'm too lazy to fire up my VM to test it.

Sorry Jake, this as offtopic as cb88's post, but I couldn't resist. Good luck, though!

 

[icurafu]

I created a snes style zelda clone during uni for software architecture. This was just to learn and put into practice some of the popular design patterns.

Oh, yeah. I wrote it in java 1.3 because performance wasn't too great an issue and it fit under 16MB. Would not recommend java if you are looking for a jkob in the industry. Unless you wanna do mobile phone games, but even that is changing.

 

[javaJake]

I created a snes style zelda clone during uni for software architecture. This was just to learn and put into practice some of the popular design patterns.

Not to shoot down your work, but I just want to clarify that I don't want to create a clone of anything. My games better be unique or else.

 

[Sphinxter]

Step one: New handle.

 

[javaJake]

:lol:

No, it's unique, it matches my preferred language, it makes for some interesting conversation, and it's used everywhere. No turning back now.

 

[Capn_Fish]

OGL supports doing things to individual pixels. What do you think it can't do that it needs to?

 

[javaJake]

Penjin? Is this the GUI core for PandoraPanic?

Basically it's a homebrew game engine been developed in my free time since about... hmm... 2 years or so ago.
But yes it's at the core of PandoraPanic! lot's of room for improvement but PandoraPanic! is helping this and I have my own list of things to do which share some of the ideas discussed here. It's 2D engine but I have some code working in 3D/OGL. I need to sort a proper camera out before 3D is useful.

I'll definitely take a look.

OGL supports doing things to individual pixels. What do you think it can't do that it needs to?

Ah, OK. It seemed to me like OGL was going to need a lot of tricks and figuring out to get pixels to work. I'll take a look and see how OGL works (I haven't learned either OGL or SDL yet...) and then figure out what I want to do from there.

 

[Parkydr]

SDL does a lot of what you want.