question about game states in rpg

  • (2 Pages)
  • +
  • 1
  • 2

17 Replies - 2093 Views - Last Post: 24 March 2009 - 12:00 PM Rate Topic: -----

#1 vAlexv  Icon User is offline

  • New D.I.C Head
  • member icon

Reputation: 1
  • View blog
  • Posts: 24
  • Joined: 12-December 08

question about game states in rpg

Posted 11 March 2009 - 01:41 PM

Hello everyone
Right now I am making my third game. I am planning of making a rpg or maybe a side scrolleer but I prefer to make a rpg.
My game states are
enum GameStates
{
STATE_NULL,
STATE_INTRO,
STATE_MENU,
STATE_CREDIT,
STATE_LEVEL1, Boss1,
STATE_LEVEL2, Boss2,
STATE_LEVEL3, Boss3,
STATE_LEVEL4, Boss4,
STATE_LEVEL5, Boss5,
STATE_EXIT
};
Since the game is linear.
But how would a rpg game state be implemented and there must be at least 200 states right?

Is This A Good Question/Topic? 0
  • +

Replies To: question about game states in rpg

#2 mocker  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 50
  • View blog
  • Posts: 466
  • Joined: 14-October 07

Re: question about game states in rpg

Posted 11 March 2009 - 02:19 PM

There is a system to design a basic game engine. What you are doing is essentially hard coding in every level, which works for prototyping short games but in anything that would ever be reused, you'd want to make it much more flexible.

Basic flowchart
http://www.gamasutra...3/figure_01.gif
from
http://www.gamasutra...ickinson_01.htm

Essentially you'd replace all the STATE_LEVEL's with something like STATE_PLAY. The levels are loaded as component of the game engine when it switches to STATE_PLAY, and possibly during the game cycle if you move zones.
Was This Post Helpful? 0
  • +
  • -

#3 WolfCoder  Icon User is offline

  • Isn't a volcano just an angry hill?
  • member icon


Reputation: 781
  • View blog
  • Posts: 7,604
  • Joined: 05-May 05

Re: question about game states in rpg

Posted 12 March 2009 - 11:16 AM

I have GOT to release the updated version of the WeaponSoul engine. Sure you can download the source code from an old alpha, but I've got a much better state handler.

It's an engine made specifically for RPGs! It allows you to write nucleii like this:

void mode_init()
{
}
void mode_main()
{
}
void mode_exit()
{
}
void mode_draw()
{
}



And then, I register the mode with my engine. I can then tell the engine to enter that mode, and it calls all the functions for me. I can even set modes to run concurrently (still buggy but I'm getting there) or globally where a particular mode is always running (great for HUDs). This way, I have a map walking mode, a battle mode, a title screen mode, and more.

RPG Maker only has about 20 or so modes, even less. But you should write your own mode handler so it becomes easy to make hundreds of modes without messy code.

Learn how to use pointers to functions and it all becomes easy.
Was This Post Helpful? 0
  • +
  • -

#4 Hyper  Icon User is offline

  • Banned

Reputation: 108
  • View blog
  • Posts: 2,129
  • Joined: 15-October 08

Re: question about game states in rpg

Posted 12 March 2009 - 02:23 PM

void (*FP)(int); /* Function Pointer */

www.google.com -> Pointers to functions
Those allow for custom (programmer) function names (callbacks)! :)
Was This Post Helpful? 0
  • +
  • -

#5 ghst  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 16
  • Joined: 29-October 08

Re: question about game states in rpg

Posted 21 March 2009 - 02:45 PM

An even better method would be to use a finite state machine.

Basically what you need is an abstract base class that is used for an interface. This is a class that will only be derived from and it has each states functionality. Update,Input,Render, Init, Shutdown.

Then each state derives off of that interface and implements it's own version of Update,Input,Render,Init,Shutdown. Then you just store a base state pointer and pointers to each state of your game. Then its as easy as just swapping between pointers when you want to change states. This gives you the ability to add or subtract game states without having to change much of the underlying code.
Was This Post Helpful? 0
  • +
  • -

#6 WolfCoder  Icon User is offline

  • Isn't a volcano just an angry hill?
  • member icon


Reputation: 781
  • View blog
  • Posts: 7,604
  • Joined: 05-May 05

Re: question about game states in rpg

Posted 22 March 2009 - 09:02 AM

View Postghst, on 21 Mar, 2009 - 02:45 PM, said:

An even better method would be to use a finite state machine.

Basically what you need is an abstract base class that is used for an interface. This is a class that will only be derived from and it has each states functionality. Update,Input,Render, Init, Shutdown.

Then each state derives off of that interface and implements it's own version of Update,Input,Render,Init,Shutdown. Then you just store a base state pointer and pointers to each state of your game. Then its as easy as just swapping between pointers when you want to change states. This gives you the ability to add or subtract game states without having to change much of the underlying code.


How is it a better method when it's the exact same method as I developed.
Was This Post Helpful? 0
  • +
  • -

#7 ghst  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 16
  • Joined: 29-October 08

Re: question about game states in rpg

Posted 22 March 2009 - 09:18 PM

Sorry I'm biased cause it was my method, no need to be hostile!

Maybe I didn't understand your engine, but what it seems like is you are using function pointers for the different states/modes in your engine. I was talking about using an ABC to act as an interface for the different states running in the game.

No harm mate..
Was This Post Helpful? 0
  • +
  • -

#8 WolfCoder  Icon User is offline

  • Isn't a volcano just an angry hill?
  • member icon


Reputation: 781
  • View blog
  • Posts: 7,604
  • Joined: 05-May 05

Re: question about game states in rpg

Posted 22 March 2009 - 10:12 PM

Ah, I was just pointing out that effectively, as long as you pass by reference, it's the same thing. You can get the source code from my project log. Registering a state is 1 line long, the first state registered is the initial state and it's a single line of code to change states.
Was This Post Helpful? 0
  • +
  • -

#9 stayscrisp  Icon User is offline

  • フカユ
  • member icon

Reputation: 994
  • View blog
  • Posts: 4,158
  • Joined: 14-February 08

Re: question about game states in rpg

Posted 23 March 2009 - 06:14 AM

I think ghst idea is a very good way of doing things, although you could take it one step further and make game state a singleton, since your only really going to have one state at a time.

then in your game class you could have a function Game::ChangeState(GameState* state);

now you can call a state with this line of code

game->ChangeState(PlayState::Instance());

Wolfcoders idea of making separate HUD state that is always running is intriguing although I'm sure this could be implemented into your states.
Was This Post Helpful? 0
  • +
  • -

#10 WolfCoder  Icon User is offline

  • Isn't a volcano just an angry hill?
  • member icon


Reputation: 781
  • View blog
  • Posts: 7,604
  • Joined: 05-May 05

Re: question about game states in rpg

Posted 23 March 2009 - 10:13 AM

/* Start the engine */
title_mode = ws_create_mode(title_init,title_main,title_exit,title_draw);
battlefield_mode = ws_create_mode(battlefield_init,battlefield_main,battlefield_exit,battlefield_draw);
status_mode = ws_create_mode(status_init,status_main,status_exit,status_draw);
select_mode = ws_create_mode(select_init,select_main,select_exit,select_draw);
/* Set global modes, like status */
ws_mode_global(status_mode,1);
/* Ingition! */
ws_ignition();



This is way simpler than any silly Object Oriented wrap. This is an example body of the entire main function for people using the engine. It's best to save the OOP for YOUR game and not the engine, when working with atomic scale features like these. With a threaded design like mine, you can see where many things can go wrong, so I avoid OOP like the plague (because it ended up screwing everything and hard to debug). Here's the underlaying code:

weaponsoul.h

#ifndef WEAPONSOUL_H
#define WEAPONSOUL_H

/*
	Regular Defines
*/
#define MAX_MODES 256
#define MAX_SPEED 120

/*
	Main function define
	Just a spoonfull of macros makes everything work easily under multiple compilers
*/
#ifndef WIN32
#include <stdio.h>
#define ws_main() int main(int argn,char *argv[])
#endif
#ifdef WIN32
#include <windows.h>
#define ws_main() int WINAPI WinMain(HINSTANCE hinstance,HINSTANCE hprevinstance,PSTR szcmdline,int icmdshow)
#endif

/*
	Error showing
	Just a spoonfull of macros makes everything work easily under multiple compilers
*/
#ifndef WIN32
#define ws_error(what) fprintf(stderr,"%s\n",what)
#endif
#ifdef WIN32
#define ws_error(what) MessageBoxA(NULL,what,"Error",MB_IConerror)
#endif

/*
	Screen Mode Defines
*/
#define WINDOW_MODE 0
#define FULL_MODE 1

/*
	Typical basic WeaponSoul data types
*/
typedef double d;
typedef unsigned long u32;
typedef long s32;
typedef unsigned long mode;
typedef unsigned char u8;

/*
	Globals that can be used outside of the engine
*/
extern s32 screen_width; /* Width of the game window/screen in pixels */
extern s32 screen_height; /* Height of the game window/screen in pixels */
extern s32 game_width; /* Width of the game itself */
extern s32 game_height; /* Height of the game itself */
extern u32 screen_bbp; /* Color depth of user's video screen */
extern u32 screen_mode; /* Window/Fullscreen mode */
extern d time_step; /* Time speed variable */

/* System only */
extern void ws_2d_begin(d alpha);
extern void ws_2d_end();

/*
	Starts the WeaponSoul Engine

	All program code after this function call will only be run
	when the engine is finished it's operation. The first availiable
	game mode will be entered and the game will run.
	Just call this function when everything is ready to be played!
*/
extern void ws_ignition();

/*
	Loads a mode from 4 functions

	Initialize, Main Function, Exit, and Drawing are the 4 functions you need
	to write before passing them to this command.
	initf: This function is called once beofre the mainf function is called over and over again.
	mainf: This function is called over and over again once initf was called.
	exitf: This function is called when the engine ends, or the current mode is changed.
	drawf: This function is called, you dont always have to write one and pass it too, every time the screen needs to be drawn.

	Save the return value as a mode, and keep it for when you want to change modes.
*/
extern mode ws_create_mode(void (*initf)(),void (*mainf)(),void (*exitf)(),void (*drawf)());

/*
	Stops the engine from almost anywhere you feel like!
	Just call this and the engine will quit.
*/
extern void ws_abort();

/*
	Changes the mode. Provide it with the return value from the ws_create_mode call.
	Please note that this DOES NOT HAPPEN IMMEDIATLY and
	when changing the mode, make sure the current mode that called
	this function will do nothing further that you don't want it to do.
*/
extern void ws_enter_mode(mode what);

/*
	Makes a mode global or makes it not global.
	Global modes are always handled regardless of the current mode.
	Global modes are drawn in the order they were created, with the
	last created mode being drawn on the top.
	Global modes are always drawn on top of the current mode.

	This is great for things that always need to be running like GUI, HUD, or other things.
*/
extern void ws_mode_global(mode what,u32 enable);

/*
	Returns the frames per second that the game is being drawn.
	Also adds all sorts of information
*/
extern char *ws_draw_fps();

/*
	Begins measuring the time things take
*/
extern void ws_time_begin();

/*
	Finishes measure the time things take, and the result
	can be viewed when you draw debug information as 'T'
*/
extern void ws_time_end();

/*
	Changes the video mode.
	Set the screen resolution and whether or not to enter fullscreen mode.
*/
/* Currently malfunctioning */
/*extern void ws_video_mode(u32 w,u32 h,u32 mode);*/

/* WeaponSoul Modules */
#include "wsinput.h" /* WeaponSoul Input */
#include "wswip.h" /* WeaponSoul Image Pack Loading */
#include "wsimage.h" /* WeaponSoul Image */
#include "wstext.h" /* WeaponSoul Text */
#include "wshull.h" /* WeaponSoul Collision */
#include "wsobject.h" /* WeaponSoul Objects */
#include "wstile.h" /* WeaponSoul Tilemaps */
#include "wsmap.h" /* WeaponSoul Maps */
#include "wsactor.h" /* WeaponSoul Actors */

#endif



weaponsoul.c

/*
	WeaponSoul RPG Engine Core
	written by WolfCoder (2008)
*/

/* Includes */
#include "weaponsoul.h"
#include <GL/gl.h>
#include <SDL.h>
#include <memory.h>
#include <stdio.h>

/* Screen */
SDL_Surface *screen;

/* Screen Variables */
s32 screen_width = 320*2; /* Size of the screen window */
s32 screen_height = 240*2;
u32 screen_bbp = 0; /* Video bits per pixel */

/* Internal resolution variables */
s32 game_width = 320;
s32 game_height = 240;

/* Full screen / Windowed Mode */
u32 screen_mode = WINDOW_MODE;

/* Video change flag */
u32 change_the_video_mode = 0;

/* Engine status */
u32 engine_running;

/* Time variable */
d time_step = 1.0;
d time_step_now = 1.0;
d time_draw_step = 1.0;
d time_draw_sample = 0;
d time_draw_difference = 0;
d time_sample = 0;
d time_difference = 0;

/* Time sampler variable */
u32 time_measure_difference = 0;
u32 time_measure = 0;

/* FPS buffer */
char fps_buffer[64];
d lfps = 0;
d dfps = 0;
u32 next_update = 0;

/* Mode functions */
void (*ws_mode_init_function[MAX_MODES])(); /* Init, Main, Exit, Draw pointers */
void (*ws_mode_main_function[MAX_MODES])(); /* I tend to call these functions the nucleus */
void (*ws_mode_exit_function[MAX_MODES])();
void (*ws_mode_draw_function[MAX_MODES])();
u32 always_running[MAX_MODES]; /* Will this mode run even if it isn't the current mode? great for system stuff like HUDs */
u32 draw_in_3d[MAX_MODES]; /* Draw this in the 3D layer of the engine? */
u32 num_modes; /* Number of modes loaded */
u32 current_mode; /* Currently running mode, defaults to 0 */
u32 mode_initialized = 0; /* Have the modes been initialized? */
u32 mode_prepared; /* Is the current mode prepared? */
u32 new_mode; /* Are we changing modes? */

/* Starts the time gate to begin measuring the time */
void ws_time_begin()
{
	time_measure_difference = SDL_GetTicks();
}

/* Stops the time gate to end measuring the time */
void ws_time_end()
{
	time_measure = SDL_GetTicks()-time_measure_difference;
}

/* Changes the video mode */
void ws_video_mode(u32 w,u32 h,u32 mode)
{
	/* Change the variable parameters */
	screen_width = w;
	screen_height = h;
	screen_mode = mode;
	change_the_video_mode = 1;
}

/* Actually changes the video mode when these flags were raised */
void ws_video_mode_action()
{
	const SDL_VideoInfo *info;
	/* Not changing, don't do a thing */
	if(!change_the_video_mode)
		return;
	/* Repeat several things done at the beginning restricted to video operations */
	/* Alright, the media layer is active, let's find out something about the end-user's video properties */
	info = SDL_GetVideoInfo();
	if(!info)
		ws_error("Something is wrong with your video display properties.\nPlease set them to something sane!");
	/* Open a window for windowed mode */
	screen_bbp = info->vfmt->BitsPerPixel;
	if(screen_mode == WINDOW_MODE)
		screen = SDL_SetVideoMode(screen_width,screen_height,0,SDL_OPENGL);
	else
		screen = SDL_SetVideoMode(screen_width,screen_height,0,SDL_OPENGL | SDL_FULLSCREEN);
	if(!screen)
	{
		ws_error("Could not set the video mode!");
		return;
	}
	/* Point to the new screen */
	SDL_SetClipRect(screen,NULL);
	/* End changing */
	change_the_video_mode = 0;
}

/* Returns the frames per second the drawing thread is running at */
char *ws_draw_fps()
{
	if(next_update <= 0)
	{
		dfps = 16/time_step;
		next_update = 50;
	}
	else
	{
		next_update--;
	}
	memset(fps_buffer,0,sizeof(fps_buffer));
#ifdef WIN32
	sprintf_s(fps_buffer,64,"FPS:%d\nENT:%d\nMAP:%d",(int)(dfps),(int)wsobject_num_entities(),(int)wsmap_num_maps(),(int)time_measure);
#endif
#ifndef WIN32
	sprintf(fps_buffer,"D: %d",(int)(dfps));
#endif
	return fps_buffer;
}

/* Mode Initialize */
void ws_mode_init()
{
	/* Don't do anything at all */
	if(mode_initialized)
		return;
	memset(always_running,0,sizeof(always_running));
	memset(draw_in_3d,0,sizeof(draw_in_3d));
	num_modes = 0;
	current_mode = 0;
	mode_initialized = 1;
	mode_prepared = 0;
	new_mode = 0;
}

/* Changes the mode */
void ws_enter_mode(mode what)
{
	/* Invalid mode produces a no change */
	if(what >= num_modes)
	{
		ws_error("Invalid mode change because that mode doesn't exist.");
		return;
	}
	/* Change the modes */
	new_mode = what;
}

/* Enables/Disables global modes */
void ws_mode_global(mode what,u32 enable)
{
	/* Invalid mode produces a no change */
	if(what >= num_modes)
	{
		ws_error("Could not set/unset a mode as global because it doesn't exits.");
		return;
	}
	/* If the engine is not on, just set variables */
	if(!engine_running)
	{
		always_running[what] = enable;
		return;
	}
	/* Is it already enabled/disabled? */
	if(always_running[what] && enable)
		return;
	if(!always_running[what] && !enable)
		return;
	/* Are we enabling it? */
	if(enable)
	{
		/* Is it the current mode? */
		if(current_mode != what)
		{
			/* Then we need to initialize it */
			if(ws_mode_init_function[what] != NULL)
				ws_mode_init_function[what]();
		}
	}
	else
	{
		/* Disabling */
		/* Check for current mode */
		if(current_mode != what)
		{
			/* Let's trash it */
			if(ws_mode_exit_function[what] != NULL)
				ws_mode_exit_function[what]();
		}
	}
	/* Set global */
	always_running[what] = enable;
}

/* Creates a new mode */
mode ws_create_mode(void (*initf)(),void (*mainf)(),void (*exitf)(),void (*drawf)())
{
	/* Initialize */
	ws_mode_init();
	/* Set pointers */
	ws_mode_init_function[num_modes] = initf;
	ws_mode_main_function[num_modes] = mainf;
	ws_mode_exit_function[num_modes] = exitf;
	ws_mode_draw_function[num_modes] = drawf;
	/* Draw in 2D by default */
	draw_in_3d[num_modes] = 0;
	/* Increment */
	num_modes++;
	/* Return mode */
	return num_modes-1;
}

/* Mode logic handler */
int ws_logic(void *data)
{
	u32 i;
	/* Enter the main loop */
	while(engine_running)
	{
		/* Sample the time */
		time_sample = SDL_GetTicks();
		/* Handle the input */
		ws_input_handle();
		/* Handle the objects */
		wsobject_handle();
		/* Handle animated tiles */
		wstile_handle_tile_animation();
		/* Run logic */
		if(num_modes > 0)
		{
			/* Exectute the current thread's main function */
			if(ws_mode_main_function[current_mode] == NULL && mode_prepared)
			{
				ws_error("Null pointer to main function for mode.");
				return 1;
			}
			else
			{
				ws_mode_main_function[current_mode]();
			}
			/* Execute all global modes */
			for(i = 0;i < num_modes;i++)
			{
				if(always_running[i])
				{
					if(ws_mode_main_function[i] != NULL)
					{
						ws_mode_main_function[i]();
					}
					else
					{
						ws_error("Null pointer to main function for global mode.");
						return 1;
					}
				}
			}
		}
		/* Maximize at maximum Logical Frames */
		/*while(SDL_GetTicks()-time_sample < (1000/MAX_SPEED));*/
		/* Get difference */
		time_difference = SDL_GetTicks()-time_sample;
		/* Calculate proper time step */
		time_step_now = time_difference/(1000/16);
		/* Slowly adjust to the new time */
		time_step += (time_step_now-time_step)/10;
	}
	/* End of the thread */
	return 0;
}

/* Stops the engine in-game */
void ws_abort()
{
	/* Abort the engine! */
	engine_running = 0;
}

/* 2D begin */
void ws_2d_begin(d alpha)
{
	/* Begin 2D drawing */
	glViewport(0,0,screen_width,screen_height);
	glMatrixMode(GL_PROJECTION);
	glLoadIdentity();
	glOrtho(0,game_width,game_height,0,-1.0,1.0);
	glMatrixMode(GL_MODELVIEW);
	glLoadIdentity();
	glDisable(GL_DEPTH_TEST);
	glEnable(GL_TEXTURE_2D);
	glEnable(GL_BLEND);
	glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA);
	glColor4f(1,1,1,(GLfloat)alpha);
	glTexEnvf(GL_TEXTURE_ENV,GL_TEXTURE_ENV_MODE,GL_REPLACE);
}

/* 2D end */
void ws_2d_end()
{
	/* End 2D drawing */
	glFlush();
	glDisable(GL_BLEND);
	glDisable(GL_TEXTURE_2D);
	glEnable(GL_DEPTH_TEST);
}

/* Ignition */
void ws_ignition()
{
	const SDL_VideoInfo *info;
	SDL_Thread *thread;
	SDL_Event quit_event;
	u32 i;
	/* Attempt to start the SDL video system */
	if(SDL_Init(SDL_INIT_VIDEO) != 0)
	{
		ws_error("I couldn't start SDL, did you install everything alright?");
		return;
	}
	/* Alright, the media layer is active, let's find out something about the end-user's video properties */
	info = SDL_GetVideoInfo();
	if(!info)
		ws_error("Something is wrong with your video display properties.\nPlease set them to something sane!");
	/* Set the OpenGL Attributes */
	SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER,1);
	/* Open a window for windowed mode */
	screen_bbp = info->vfmt->BitsPerPixel;
	if(screen_mode == WINDOW_MODE)
		screen = SDL_SetVideoMode(screen_width,screen_height,0,SDL_OPENGL);
	else
		screen = SDL_SetVideoMode(screen_width,screen_height,0,SDL_OPENGL | SDL_FULLSCREEN);
	if(!screen)
	{
		ws_error("Could not set the video mode!");
		return;
	}
	/* Set the default window title */
	SDL_WM_SetCaption("WeaponSoul","weaponsoul");
	SDL_SetClipRect(screen,NULL);
	/* Now adjust OpenGL for WeaponSoul */
	glClearColor(0,0,0,0);
	glShadeModel(GL_FLAT);
	glPixelStorei(GL_UNPACK_ALIGNMENT,1);
	/* Initialize the rest of weaponsoul */
	wsimg_init();
	/* Now! Hahaha! The video has been initialized, let's go ahead and start running! */
	ws_mode_init();
	wsobject_init();
	wsmap_init();
	engine_running = 1;
	/* Start the game logic */
	thread = SDL_CreateThread(ws_logic,NULL);
	/* Initialize global modes before engine was turned on */
	for(i = 0;i < num_modes;i++)
	{
		/* Is it not the current mode? That's going to get initialized already in the main body */
		if(i != current_mode)
		{
			/* Is it global? */
			if(always_running[i])
			{
				/* Initialize if it can be */
				if(ws_mode_init_function[i] != NULL)
					ws_mode_init_function[i]();
			}
		}
	}
	/* Enter the main loop */
	while(engine_running)
	{
		/* Sample the time */
		time_draw_sample = SDL_GetTicks();
		/* Prepare the mode for execution if it isn't ready */
		if(mode_prepared == 0)
		{
			if(ws_mode_init_function[current_mode] == NULL)
			{
				ws_error("Null pointer to initialization function for mode.");
				return;
			}
			else
			{
				ws_mode_init_function[current_mode]();
			}
			mode_prepared = 1;
		}
		/* Clear the old picture */
		glClear(GL_COLOR_BUFFER_BIT);
		/* Prepare to draw 2D graphics */
		ws_2d_begin(0.5);
		/* Draw 2D graphics */
		if(num_modes > 0)
			if(ws_mode_draw_function[current_mode] != NULL && !draw_in_3d[current_mode])
				ws_mode_draw_function[current_mode]();
		/* Draw global 2D graphics */
		for(i = 0;i < num_modes;i++)
		{
			if(always_running[i])
			{
				if(ws_mode_draw_function[i] != NULL && !draw_in_3d[i])
					ws_mode_draw_function[i]();
			}
		}
		/* Finish drawing 2D graphics */
		ws_2d_end();
		/* Check for engine quit */
		while(SDL_PollEvent(&quit_event))
		{
			/* User closes the window */
			if(quit_event.type == SDL_QUIT)
				engine_running = 0;
			/* User presses the ESC key */
			if(quit_event.type == SDL_KEYDOWN && quit_event.key.keysym.sym == SDLK_ESCAPE)
				engine_running = 0;
		}
		/* Show the finished picture */
		SDL_GL_SwapBuffers();
		/* Change the video mode if chaning modes */
		ws_video_mode_action();
		/* Execute the current thread's cleanup if changing modes */
		if(new_mode != current_mode)
		{
			/* Call the exit function */
			if(ws_mode_exit_function[current_mode] == NULL)
			{
				ws_error("Null pointer to exit function for mode.");
				return;
			}
			else
			{
				ws_mode_exit_function[current_mode]();
			}
			/* Change the mode */
			current_mode = new_mode;
			mode_prepared = 0;
		}
	}
	/* Wait for the other thread to finish */
	SDL_WaitThread(thread,NULL);
	/* Clean up the current mode */
	if(num_modes > 0)
	{
		if(ws_mode_exit_function[current_mode] == NULL)
		{
			ws_error("Null pointer to clean-up function for mode.");
			return;
		}
		else
		{
			ws_mode_exit_function[current_mode]();
		}
	}
	/* Clean up all global modes */
	for(i = 0;i < num_modes;i++)
	{
		if(always_running[i])
		{
			if(ws_mode_exit_function[i] != NULL)
				ws_mode_exit_function[i]();
			always_running[i] = 0;
		}
	}
	/* Free the rest of weaponsoul */
	wsmap_exit();
	wstile_free();
	wsimg_exit();
	/* Stop the simple direct media layer */
	SDL_Quit();
}


This post has been edited by WolfCoder: 23 March 2009 - 10:21 AM

Was This Post Helpful? 0
  • +
  • -

#11 stayscrisp  Icon User is offline

  • フカユ
  • member icon

Reputation: 994
  • View blog
  • Posts: 4,158
  • Joined: 14-February 08

Re: question about game states in rpg

Posted 23 March 2009 - 10:30 AM

Silly OOP Wrap! :angry:

What are you talking about?!

the main function for my game reads as so

#include "Game.h"
#include "IntroState.h"
#include "PlayState.h"
#include "GameOverState.h"
#include <iostream>


int main ( int argc, char *argv[] )
{
	Game game;

	// initialize the engine
	game.Init( "Test Game", 640, 480, 32, false );

	// load the intro
	game.ChangeState( IntroState::Instance() );

	// main loop
	while ( game.Running() )
	{
		game.HandleEvents();
		game.Update();
		game.Draw();
	}

	// cleanup the engine
	game.Cleanup();

	return 0;
}


:wub:
Each state is nicely hidden away in its own file and the game class simply calls the current states functions.

About a million times simpler than lumping almost everything into your main function.

now say you want to test out something new without messing with any of your working code, you simply derive from your gamestate again and then you have an almost fresh test bed to play with.

I find it rather amusing that you call something that almost every professional game developer would call an excellent and powerful way to program "silly".

This post has been edited by stayscrisp: 23 March 2009 - 10:31 AM

Was This Post Helpful? 0
  • +
  • -

#12 Hyper  Icon User is offline

  • Banned

Reputation: 108
  • View blog
  • Posts: 2,129
  • Joined: 15-October 08

Re: question about game states in rpg

Posted 23 March 2009 - 01:43 PM

View Poststayscrisp, on 23 Mar, 2009 - 12:30 PM, said:

Silly OOP Wrap! :angry:

What are you talking about?!

the main function for my game reads as so

#include "Game.h"
#include "IntroState.h"
#include "PlayState.h"
#include "GameOverState.h"
#include <iostream>


int main ( int argc, char *argv[] )
{
	Game game;

	// initialize the engine
	game.Init( "Test Game", 640, 480, 32, false );

	// load the intro
	game.ChangeState( IntroState::Instance() );

	// main loop
	while ( game.Running() )
	{
		game.HandleEvents();
		game.Update();
		game.Draw();
	}

	// cleanup the engine
	game.Cleanup();

	return 0;
}


:wub:
Each state is nicely hidden away in its own file and the game class simply calls the current states functions.

About a million times simpler than lumping almost everything into your main function.

now say you want to test out something new without messing with any of your working code, you simply derive from your gamestate again and then you have an almost fresh test bed to play with.

I find it rather amusing that you call something that almost every professional game developer would call an excellent and powerful way to program "silly".


I prefer the way you did it (stayscrisp), very easy to read. You can then look up each individual thing to see what it does. :)
Was This Post Helpful? 0
  • +
  • -

#13 WolfCoder  Icon User is offline

  • Isn't a volcano just an angry hill?
  • member icon


Reputation: 781
  • View blog
  • Posts: 7,604
  • Joined: 05-May 05

Re: question about game states in rpg

Posted 23 March 2009 - 06:18 PM

View Poststayscrisp, on 23 Mar, 2009 - 10:30 AM, said:

...
Each state is nicely hidden away in its own file and the game class simply calls the current states functions.
...


Each of my states are also hidden away in each of their own files. The game does call the current state's functions. You might see a difference, but I barely even notice at all the difference between my code and your code except for it's shaped differently. There's a battlefield.c, a status.c and so on. The weaponsoul.c program code is meant to be for my eyes only and those willing to change the gears inside.

Actually let me rephrase this, any experienced programmer can see that both our methods are actually nearly identical. They're both object-oriented code. I can, however, easily start delegating more modes into threads to increase the speed on multiple core CPUs. From your point of view, the engine should behave like a monolithic system where you can randomly make calls to it (like OpenGL). This is the initial system, I know I'm going to go back and start heavily fine tuning everything. I might even re-write a few things in ASM. Speed is of utmost importance.

Furthermore, you should look at the entire source code (available for download on my log) before making criticism in the engine's entirety.

I want to leave it up to someone writing a game to use OOP or even something else.

I need more control of how everything is structured, so C is the thing for the job in Video Game engines. However, depending on the design of the engine, full C++ might be better as well.

As for looking up what does something, it takes me nearly instantly to do so and to change/fix it. I've already had to do so already. I can even go back and fix stuff even months after not looking at the code just fine.

View Poststayscrisp, on 23 Mar, 2009 - 10:30 AM, said:

...
now say you want to test out something new without messing with any of your working code, you simply derive from your gamestate again and then you have an almost fresh test bed to play with.
...


That's precisely what I do all the time with it. I add new features and change things easily. As I said, I should have rephrased it, but all those fancy features in C++ are a waste of time- you can write Object Oriented code just fine in C. I even have a test driver program that shows me if something breaks. It works much like the Acid3 test in a way. I've done my share of experimenting even with the code, you can see plenty of commented out places where I decided that a feature doesn't work right just yet.

Just because you have heard professional game designers use object oriented features of C++ doesn't mean they actually are all the time, or that they always do that. When they do, their answer would be along the lines of "We needed something to manage half a million lines of code easier". I know that's actually nearly exactly the quote of one programmer who was writing an FPS engine. The reason I'm writing in C is that, not only do I know what I'm doing, but I know with so much detail that I know precisely how everything should act and be designed. I'm not going to use any object oriented features of C++ until I feel they are mandatory.

I have been through probably about 8 versions of these engines, some of them used the C++ features. This is the final design I have decided to settle upon. The code you can see has been through about 4 or so years of designs and prototypes. I have a very very clear understand of what I precisely want to do, so much so that I remember pages of document ion in my mind and can recite them onto paper. While I don't need any documentation yet, the end user will eventually. I already have a user manual in the works.

Please study and learn the difference between features provided by C++/JAVA/ect. and Object Oriented design.

Sorry for the lengthy post, but I kind of have to defend my work. However, this is probably brought on by the fact that I'm just misunderstood back there- my overall point is that I really see no difference at all in either of our code (Except for mine is completed and has a couple of other core features). It looks complicated because every single line of it is deliberate.

This post has been edited by WolfCoder: 23 March 2009 - 06:51 PM

Was This Post Helpful? 0
  • +
  • -

#14 stayscrisp  Icon User is offline

  • フカユ
  • member icon

Reputation: 994
  • View blog
  • Posts: 4,158
  • Joined: 14-February 08

Re: question about game states in rpg

Posted 24 March 2009 - 05:30 AM

I didn't once criticize your engine, in fact I'm pretty sure i said one of your ideas was intriguing.

I was simply showing another way of doing things which to me is a lot clearer and easier to manage, you may feel that OOP or just c++ features (as you put it) is pointless but that doesn't account for everyone.

I haven't just heard professional game developers "use OOP" I was taught c++ and game development by someone who was in the industry as a programmer and he taught me this way and expressly told me that I would need to master it. This way has many many merits, I'm never gonna have to touch my game state code again its totally reusable across any project I choose ,of course i could improve it in time but for now it does exactly what I want. I can also say the same for most of my other code.

I just found it quite annoying that you would just dismiss design methods as silly or useless, how about you try "not my cup of tea" or "i found it wasn't for me"
Was This Post Helpful? 0
  • +
  • -

#15 mocker  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 50
  • View blog
  • Posts: 466
  • Joined: 14-October 07

Re: question about game states in rpg

Posted 24 March 2009 - 05:44 AM

Wolfcoder.. just because you have something that works doesn't mean it is the best way, or THE way everyone else should do it. I haven't examined your engine so the following isn't me going 'your way is wrong', but your way is ONE OF MANY (and this has been done many times by other people, you aren't breaking new ground)

Quote

I need more control of how everything is structured, so C is the thing for the job in Video Game engines. However, depending on the design of the engine, full C++ might be better as well.


I don't know where you get off making blanket statements about THE language to make game engines in. Do a google search and you'll see tons of engines in pretty much every language, with many many many of them using an OO design. Games are pretty much ideal for demonstrating how to design with objects, at least for managing the game entities. Many professional engines use a C++ OO design, with the main rendering sections either heavily optimized, or asm. You don't need to make the whole engine the lowest level language you can find when it is only most heavily used rendering loop that needs the marginal increase in speed.

The mention of a finite state machine is essentially what most game engine systems implement (random hobbyists experimental engines not includes).

staycrisp said:

I think ghst idea is a very good way of doing things, although you could take it one step further and make game state a singleton, since your only really going to have one state at a time.

I've seen stacks used effectively for storing game states. They let you do things like pause/resume states easily without having to load and reload the entire thing. You only have the top state updating, so you could switch to a main menu and back and your game resumes as if nothing happened.

This post has been edited by mocker: 24 March 2009 - 05:46 AM

Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2