Jump to content

  • Log In with Google      Sign In   
  • Create Account

Herwin P

Member Since 09 Apr 2013
Offline Last Active Sep 25 2016 08:59 PM

Posts I've Made

In Topic: Tackle my first big project

31 March 2016 - 10:04 PM

Since your purpose is building up your portfolio, I think you should go with Unity and get working as soon as possible. I heard people in the industry like using Unity, because hiring people who already have experience with it is easier because they don't need to train you as much and everything. That's just something I heard on the Internet though.


About digging deeper into C++, it depends on you. Developing your own framework takes a lot of time and sweat. If you're impatient and want to get results quickly, it might make you really frustrated, but if you're more interested in the study of programming, then it might be worth it.

In Topic: Concept for a rpg game where the character grows based on what you do?

07 March 2016 - 07:46 PM

It will indeed require a lot of content. You need to determine the bounds of the story and give the player freedom to do what they want inside those boundaries. The problem with writing for games is that the player can also be the story teller.


Like Conquestor said, having a few fleshed out paths is a good way of doing this. You can write the hero path, pacifist path, and murderous path, for example, and give options related to these paths. Of course, it's not without its problems. You can't force the player to follow through a single path in the whole game. They might start being a pacifist at first, but there's nothing stopping them for killing people for reasons like boredom or curiosity. What if they act like both a hero and a murderer, etc.


Another idea is to make consequences of the actions the player take appear immediately. If you choose to spare a soldier, a few scenes later you might see him killing other people, and that thing is done. You might not see the soldier again for the rest of the game (thus less content to make) and the player can rethink their future choices because now they understand that their choices matter. This way they might realize that their lack of courage to kill caused more people to die, and they might choose to be more ruthless next time, or the other way around.


I think that would be enough for now. Writing down all the possibilities would take forever. Just determine the boundaries of the experience. What kind of experience you want your players to feel? What is the message of the story? Is it about life in war? Agency? Once you've determined what your game is about, you can build around it.

In Topic: Help with my game program architecture

09 February 2016 - 07:21 PM

Then, I'm not certain about handling game screens (game states) making games with SFML. I declared an enumeration type for representation each of the states, but it's pretty clear to me that it's not sufficient since in every game state there is a set of objects (for example a text of welcome on the initial game screen, some background etc) that are created on switching to a state and destroyed on switching off to another. I of course could re-instantiate those objects over and over again while the game cycles through processInput(), update() and draw() just by declaring those objects in the methods, but I think it's too sily and ugly way of handling things like this. Moreover, in this case I have to set the origin, position, etc of the objects. For example, if I want a text to be displayed on the screen once the player loses the game, I'd have to declare a text variable, set its font, character size, string, origin, position right in the draw() method, which again seems not a very good practice. In addtition, there are some variables that must be re-assigned when the player causes the game come out of one state and get into another.


You can make a base class for state and child classes of it for each specific state, and create and destroy its objects in its constructor and destructor. Then you can make a state handler class that contains those states, in a container of type pointer of the state base class, and handles the switching.


You can even define specific processInput(), update() and draw() methods for each state so they can have different behavior. For example, a menu state only draws play and exit buttons while the game state draws the board and handles the game commands. On the state handler class you can set these methods too, to command the active state to call its respective methods.


Also, if you need to share resources among states, like textures, fonts, etc, you can declare them in the state handler class and share them to the states.

In Topic: How to ease sprite creation for an RPG

04 December 2015 - 03:32 AM

I'm not sure what you are using for a game engine here, but I have seen a method in Unity where you draw the basic sprites and then animate them in the editor using bone/rigging techniques similar to 3D animation methods.  I'm not sure if this reduces the work load as I'm pretty new to game dev. in general, but this came to mind and I don't think anyone above mentioned it.


I'm not using an engine for this one actually. I'm using C++ and SFML for study purposes. I already made a simple top-down shooter with basic data-driven design, which we're using as the base for this RPG now. Though that shooter has a flat top-down view, so the sprites and animations are really simple.


We used Unity for our previous platformer, so we already have experience with that technique. We decided not to use for this RPG because we plan to have the character to be able to face 8-directions, and we thought using sprite sheets would be easier for that. Not sure if other people would think differently.

In Topic: C++ Classes, Hierarchy, Friends Chart

04 December 2015 - 03:11 AM

No you can't! That will cause slicing.


If you need polymorphism, you need to use pointers. So,

std::vector<Move*>, or preferably std::vector<std::unique_ptr<Move>>.


Oopsies. My bad. I wrote that example without thinking. mellow.png