Jump to content
  • Advertisement
Sign in to follow this  
Novembxr

Making a Final Fantasy like game

This topic is 995 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This wouldn't be the first "game" I've made in Java, but it is definitely more complicated than anything I've done before. This Java game (for fun, not for school or anything) is meant to play out like a JRPG, just without a story and quests etc. the player traverses across a randomly generated board of tiles by rolling dice. Whatever tile he lands on triggers an effect. If the tile happens to be an encounter tile, the game should stop rendering the board and the player and render the combat scene (assuming the Enemy objects have already been initialized). I was unsure how to go about doing this. Currently, I just have a single thread running in the driver class that runs a simple render method which is called in the game loop. I don't want to throw a bunch of conditional statements in the render method to render different scenes based on very specific things (as this method is responsible for rendering everything at the moment: inventories, player, tiles, etc.).
I know I'm probably being very vague, but I was wondering if there was an ideal way to do what I want to do. Should I make a state machine to handle game states and render accordingly? Even with this way of doing things, I still feel like the render method would get messy and error prone. Any suggestions?

Tl;dr:
Looking for an appropriate way to switch between rendering a "game world" and a "combat scene" similar to final fantasy games and other JRPGS

Edited by Novembxr

Share this post


Link to post
Share on other sites
Advertisement

I'm not familiar with Java enough to provide code, but here's how you could handle it.

 

  • There would be a Game and GameState class
  • Game would hold a reference(I think that's what they're called in Java?) to a GameState
  • Set GameState to whichever is needed(rolling dice, fighting, menu, whatever)
  • Call Update in said GameState
  • You can then pass your renderer a list of entities/sprites to draw that exist in the current state

 

My shitty attempt at Java

 

This is obviously missing key components, but it shows the concept of using a state machine.

public abstract class GameState
{
    public void Update(Game _game);
    public void Render(Game _game);
};

public class GameStateRollingDice extends GameState
{
    public void Update(Game _game) {
        //Update RollingDice logic
    }
    public void Render(Game _game) {
        //Render RollingDice frame
    }
};

public class Game
{
    private GameState m_currentState;

    public void Update() {
        m_currentState.Update(this);
        m_currentState.Render(this);
    }
};
Edited by Renthalkx97

Share this post


Link to post
Share on other sites

The trivial way to do this is to just take a base class/derived class approach to it. You could have a base "Screen" class with a method called Update that returns the transition state. (You'll probably want a Render method as well but that's beyond the scope of this.) Then you create subclasses for all the "screens" (or modes) of the game, ie: MapScreen, BattleScreen, MenuScreen, etc. On every iteration of the game loop, the current screen's Update method is called. It will update the game and returns whether there should be a transition. Here's an (oversimplified) example of how this works. (Forgive the C#-isms if there's any; I practically never use Java.)

public abstract class Screen
{
    public abstract int Update();
    // whatever other functions you need that are common to all screens
}

void MainLoop()
{
    // declare all the screens of the game here
    TitleScreen titleScreen = new TitleScreen();
    MapScreen mapScreen = new MapScreen();
    BattleScreen battleScreen = new BattleScreen();
    MenuScreen menuScreen = new MenuScreen();
    // ...

    // put the screens in the array for transition
    Screen[] screens = new Screens[] { null, titleScreen, mapScreen, battleScreen, menuScreen };

    // what screen we're looking at, initialized at title screen
    Screen current = titleScreen;

    // begin main loop
    while (null != current)
    {
        // update the game and get transition state
        int transition = current.Update();

        // if it didn't return -1, there's a transition
        if (transition != -1)
            current = screens[transition];

        this.WhateverOtherProcessingYouNeedToDoPostUpdate();
    }
} 

Like I said, this is an oversimplification. For example, if your MapScreen triggers a battle, it probably also needs to tell the BattleScreen what enemies are present in the encounter, so that needs to be passed over. My example has the Update method return an int for the # of the screen to load, but in reality, instead of returning an int for the number of the screen to load, your Update method would probably return a ScreenTransition object that contains whatever information you need to initialize the screen being transitioned to, or null if there is no transition.

 

You may also want to draw a state transition graph of your game screens, to figure out with what other screens a given screen can transition to. In the case of a Final Fantasy-style RPG, the map screen communicates with nearly every other module in the game except maybe the Game Over (which probably doesn't need to have it's own screen if it's just a 2D image blit...), whereas a battle screen may only go to Game Over screen or back to map screen. (You can't access the menu, the title screen, any mini-game, etc. from the battle.) In that case, it may be even simpler if the map screen's module "owns" every other module and manages the transitions itself instead of the main loop, because that would mean that the map screen has the information to initialize all other screen.

Edited by Bearhugger

Share this post


Link to post
Share on other sites

Wow, didn't expect so many replies so quickly. Thanks everyone for your contribution, especially L. Spiro for the nice articles on his blog.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!