2D RPG Game Questions (I stopped 3D for now)

Started by
10 comments, last by Jotaf 15 years, 2 months ago
I tried Irrlicht last month but didn't get it so I think I really need to master 2D first before going to 3D. I'm planning to make a real time yet turn based RPG. I have a story right now that I'm going to use in this game. It's quite long though. I hope I finish this. And make it 3D someday. :) Questions: 1) Should I use SDL, or do you have any suggestion? 2) Do you know any program that will help me create some sprites? 3) I'm not that good yet in C++. Should I stay C++ or move now to C#? I want to become a good programmer but most of the people around said that I should use C# or Java. I don't know why. (I'm not making this thread C++ vs C# vs Java or whatsoever.)
Advertisement
1) Use SDL. It's the DirectX outside the Windows world, and is neophyte-friendly (which I am assuming you are, based on the first line in your post).

2) Use sprites from such sites as molotov.nu until you find yourself an artist. Focus on things like gameplay and fun rather than creating awesome graphics up-front. Once you have your game nearly in-place and almost working the way you want it to, search for an artist, or redo the graphics yourself.

3) SDL has bindings for C#, so it's entirely possible to use SDL in a C# application. I personally prefer C++, and do suggest sticking with it for your game if you already have familiarity with it, and there will be a horde of post below mine which will refute this with various degrees of vehemency. Stick with what you know for your first project, but also be open to the possibility of learning other languages. You might even try making a couple of skeleton frameworks that blit a box on the screen, in C++, C#, and Java, and choose the one you prefer.

When choosing a language, it's important to consider coding style, speed of compiling, cross-platform availability, and availability of supporting and related APIs and tools (and the quality of their supporting communities). Choosing a particular language because a handful of people told you to, is wrong.

Good luck, and email me if you go the C++ way, as I can give you some direction in that capacity.
1) Yeah. It's easy to use and I really love it. By the way, do you think making a 2D game engine is worth it? I heard creating one will takes forever. I want to make one but I don't know where to start.

2) Thanks for the link. Uhmmm, do you have any link to any animated character sprites? I noticed most of the sprites there are not animating. I want to make my game more lively. :)

3) Yeah, I think C++ is better but every time I hear those people, C++ is the past and the new C# is future which is better and has less development time. No more memory leaks or what so ever. Gosh. I'm tired hearing those things.

Thank you very much for replying, DarkHorizon. I hope others will reply also. :)
I've been using C++ and either Allegro or SDL for a long time, and I have to say they're not the best combo around. If you're the typical procrastinator who wants to develop his precious framework over the next 5 years, it's ok, but if you actually want to make a game, I'd look into other alternatives.

Look for 2D engines made by other people; ones that actually provide game objects, instead of just wrapping blit(). You can program many of them in other programming/scripting languages like Lua and Python, which are a lot easier on you than C++. Last week I played a pretty good 2D game and was shocked when I found out it was coded using GameMaker in less than a month. (It's called Verge by the way.)

Recently I've seen the appearance of a new school of thought among some game programming communities that reasons the following: throwing more computational resources at a problem (memory, CPU cycles) is more efficient than throwing programmer-time at it (ie, spending more years developing it). Memory and CPU capabilities are increasing all the time, while your time is limited. If you have a vision for a particular game you should code it now, not stop your life for a few years developing the 1000th game framework that this world has seen.
C# == Microsoft in my eyes...
Is it at all portable? I'll just stick to C++ and SDL. C++ is still the gaming industry standard.

Don't worry about animating sprites yet. Save the details until you have a character moving and interacting with the environment. Until then, I suggest that you write a quick wrapper class that covers up the SDL_Surfaces that you will use for the sprites. Something along these lines:
class Sprite{public:SDL_Surface* spriteMap;virtual void draw(){}virtual void update(){}};


If you want faster results, as Jotaf says, you should use a pre-existing 2d graphics or game engine. These are very easy to find. Check the libraries list at libsdl.org. Such an engine would presumably already do animations, too.
@Jotaf

I don't get what you mean framework. Is it like a game engine? So it means it will take so long to make a RPG Game if I didn't use one?

I'm a type of person who really wants to learn more about game programming. I want to know how this and that works. If you have any popular and easy 2D game engine to recommend. Can you please post it here. Maybe I'll use a game engine for now if it will make me more faster creating my game and will develop my own maybe someday with my future team. I hope I meet then. hehe.

@grimfang4

Yeah. C# is only for Microsoft.

Ok. Maybe I'll just skip the animating.

I don't get your draw and update. (Sorry if I sound noobish but this the only game I'll make my game organize. I didn't use any classes creating my old games ago so it was so messy. )

Quote:class Sprite
{
public:
SDL_Surface* spriteMap;
virtual void draw() // This one will draw it? Blitting?
{}

virtual void update() // What about this one?
{}
};


I don't get it. Isn't SDL is a graphic engine?
Well, if you're going to use a game engine, then you can ignore that snippet. If you want to understand it (and see SDL at work), though, I'll provide an actual example. This is a bit overkill... and I don't fully know why I'm doing it, but here you go:

#include "SDL.h"// This is just for a static (non-animating) spriteclass StaticSprite{public:SDL_Surface* image;float x, y;float velX, velY;Sprite()   : x(0), y(0)   , velX(0), velY(0)   , image(NULL){}Sprite(SDL_Surface* image, int x = 0, int y = 0)   : x(x), y(y)   , velX(0), velY(0)   , image(image){}virtual void draw(SDL_Surface* destination){    SDL_Rect d = {x, y, 0, 0};  // Position on dest surface    SDL_BlitSurface(image, NULL, destination, &d);  // The actual blit}virtual void update(float dt){    x += velX * dt;    y += velY * dt;}};int main(int argc, char* argv[]){    // Set up SDL's window    if( SDL_Init(SDL_INIT_VIDEO) < 0 )    {        printf("Couldn't initialize SDL: %s\n", SDL_GetError());        return 0;    }        int w = 800;    int h = 600;    SDL_Surface* screen = SDL_SetVideoMode(w, h, 32, SDL_SWSURFACE);    if ( screen == NULL )    {        printf("Couldn't set video mode %dx%d: %s\n", w, h, SDL_GetError());	return 0;    }    // Make my sprite:    StaticSprite me(SDL_LoadBMP("myPic.bmp"));    me.velX = 200;    me.velY = 200;        // Begin the main game loop    SDL_Event event;    float dt = 0;    int frameStartTime;    bool done = false;    while(!done)    {        frameStartTime = SDL_GetTicks();        while(SDL_PollEvent(&event))        {            if(event.type == SDL_QUIT)                done = true;        }                me.update(dt);        SDL_FillRect(screen, NULL, 0);  // Clear screen with black        me.draw(screen);        SDL_Flip(screen);        // Put frame rate throttling code here        dt = (SDL_GetTicks() - frameStartTime)/1000.0f;    }    SDL_Quit();    return 0;}



... I'm sorry about that. I don't know how well-versed you are with C++, but I used default parameters and initializer lists :(

This example should work right out of the box if your SDL build environment is set up correctly (use a tutorial for this or my page: http://pubpages.unh.edu/~jmb97/tutorials/installSDL.html). Make an image called myPic.bmp, and you should see it move diagonally across the screen.

If you want to talk about it more, you can email me.

SDL is not just a graphics library. It does basic video (2d framebuffer), excellent input (including joysticks), and raw audio. It is often used to set up a window for OpenGL to use.
If you want to know how a 2D engine works look into PhoenixGL for example : http://code.google.com/p/phoenixgl/
My Blog - http://www.freakybytes.org
Quote:Original post by m3rk
@Jotaf

I don't get what you mean framework. Is it like a game engine? So it means it will take so long to make a RPG Game if I didn't use one?

I'm a type of person who really wants to learn more about game programming. I want to know how this and that works. If you have any popular and easy 2D game engine to recommend. Can you please post it here. Maybe I'll use a game engine for now if it will make me more faster creating my game and will develop my own maybe someday with my future team. I hope I meet then. hehe.


An RPG? Definitely [rolleyes]

If what you want to do is a breakout or snake clone, it's possible to learn the inner workings of a game engine and make one within a reasonable time scale (months or a year, depending on your commitment to it). A simple game is a good way to start, and will be more than enough of a challenge. Don't get overly ambitious with generic classes for everything; just get it to work.

But if you really wanna make an RPG to be proud of, forget it [smile] We at these forums have seen it way too many times: you'll learn how to make some things right, learn how to do some things wrong, and after a few years, still have a long "to do" list filling you with despair! Not to discourage you, but that's how most people start [wink]

Anyways maybe you should try something different. Get GameMaker, it may sound like it's too damn easy, but it actually has a pretty powerful scripting language, with a syntax resembling C. You *can* code *anything* (gameplay-wise) with it that you can code in C++. Some of the features are drag-and-drop, sure, but you can code your game logic the good old-fashioned way. It would be a great way to get a taste of making a complete game within a reasonable span of time.

SDL is not so bad though; if I were you, I'd try messing around with both of these in parallel. Also, instead of SDL there are other engines that provide most of the things that a game needs, like HGE for example (although they seem to release only a new version every year). I've been a bit out of the loop with the latest 2D engines though, so I can't give any more suggestions that I know as well as the ones I already mentioned.

In case you're familiar with Python, using something like FIFE could really ease your work:
Flexible Isometric Free Engine
-----PARPG - open source isometric 2d old school RPG still looking for interested contributors

This topic is closed to new replies.

Advertisement