Jump to content

  • Log In with Google      Sign In   
  • Create Account

Plethora

Member Since 21 Aug 2006
Offline Last Active Jun 19 2014 12:30 PM

#5067785 Battle System in a tactical battle (srpg style)

Posted by Plethora on 06 June 2013 - 06:23 AM

I think you've made a number of mistakes regarding character A here, correct?
20 - 9 = 11, not 12.
Likewise, its every 11th round, not 12th (numbers in parenthesis would thus work)

 

Heh, yes, While reading over the post I changed the numbers but mistakenly missed some, lol.

 

I have to advise you to make good use of terrain. You may not realize it yet, but a strong part of tactics and keeping the game fresh will come from terrain being different.

 

I couldn't agree more and believe me, I want to do fun things with terrain, its just a matter of time (ie I don't have enough of it).  Terrain effects (along with unit facings affecting combat) is near the top of the list for "phase two" of development.  I'm in step one of the iterative design process... I intend to release something playable in some fashion without those aspects of combat and evaluate where I'm at at that point.  From there its a matter of prioritizing what additions will make the most difference in "fun factor" to the game as a whole.  Thus, I'm trying not to extend massive amounts of thought energy on the topic.  Hopefully that makes sense.




#5066291 Strategy Game - Unit Damage

Posted by Plethora on 30 May 2013 - 08:10 PM

It depends on the game. 

  • Randomized Damage:  This tends to work better for games that are designed to be quick, casual, and/or have little to no death penalty.  In addition, Randomized Damage can work well (as someone said before) in situations where a player has ample time, resources, and options to re-evaluate his/her strategy in light of some good or bad rolls. 
  • Deterministic Damage:  Tends to work better for ultra competitive games (like starcraft), and games where the player has enough on the line that losing on a failed die roll will piss him/her off enough that he/she might not want to keep playing.

In both cases, its important to balance appropriately.  A poorly balanced game with randomized damage can come off as completely random such that player choices have no value.  Conversely, deterministic damage can end up boring because everything ends up working out the same way every time.  As the game designer its your job to address those concerns in some alternate way.

 

EDIT:  I should add... all good damage models have variance... its just a matter of where you put it and how much direct input the player has on it.  In starcraft, the variance comes into play in terms of damage types and the ability of a player to micro-manage his units such that they perform optimally.  When two armies clash in starcraft, you can have radically different outcomes based on positioning and micromanagement from one battle to the next.  That is not to say that system is better or worse its a matter of preference, and the type of game you're trying to create. 




#5066257 Engineer looking to expand into games.

Posted by Plethora on 30 May 2013 - 04:38 PM

The first decision you have to make is exactly what kind of starting point you wish.  There is a kind of divide (though like many things its more like a spectrum) between starting with a more traditional programming language (c++, java, even python or c#), or starting with one of the many game engines out there such as Game Maker or Unity.  Game Maker and Unity are radically different from each other but both are "engines" which are designed to allow you to make games much faster than you would be able to if you were starting off with c++ for example.

 

My advice would be two-fold:

  1. Many beginners feel like they have to make a decisions and stick with it forever.  This is as far from true as possible.  If I were you I would go right now and download something that seems interesting to you and start messing around with it.  For the most part, whatever you choose will have plenty of tutorials and resources available, and even commercial software will typically have a trial version.  If you find something you really like you may find that you might consider paying for it where you wouldn't have before.
  2. I think in the beginning the most important thing you can do is just dive into creation.  You will have plenty of time for thinking and planning out your path later.  For now what you want to figure out is what tools seem right for you, and start getting a handle on how those tools work.  While a lot of people here are very knowledgeable about one tool or another, you're the only one that can decide which one is right for you.

So here's my advice... go get the free trial of GameMaker right now and start messing around.  If, in two days, you hate it, or it just doesn't feel good to you, then drop it and try something else.

 

:)




#5065901 What am I missing here?

Posted by Plethora on 29 May 2013 - 01:07 PM

I found the problem!  I knew it must've been my idiocy!  lol

 

I have an alternate constructor for Battle_Map.  It was deprecated and it passed in a variable I wasn't even using anymore.  I didn't realize my program was still calling that old constructor!

 

Let this be a lesson to anyone that runs across this in the future, REMOVE OLD CODE!  :)

 

Anyway, thank you for the help nonetheless!




#5065885 What am I missing here?

Posted by Plethora on 29 May 2013 - 12:27 PM

I've been staring a single line of code for way too long and I am very confused, maybe someone here can help me. Here's the code in question:
class Turn_Manager
{
private:
	std::vector<std::shared_ptr<iUnit>> combatUnits;

public:	
        Turn_Manager();	
 
        void init(std::vector<std::shared_ptr<iUnit>> activeUnits);
};

Turn_Manager::Turn_Manager()
{
}

void Turn_Manager::init(std::vector<std::shared_ptr<iUnit>> activeUnits)
{
	combatUnits = activeUnits;	
        //std::vector<std::shared_ptr<iUnit>> test = activeUnits;
}

The error occurs when init is called. Here is the function from which it is called:

void Battle_Map::fillUnits()
{
	std::vector<std::shared_ptr<Character>> chars = player->getChars();
	units.insert(units.end(), chars.begin(), chars.end());
	units.insert(units.end(), enemies.begin(), enemies.end());
	turnManager->init(units);
}

When I run my program, I'm getting an access violation on combatUnits. The debugger shows that within the scope of the init method, activeUnits is fine. In contains correct and accurate data. combatUnits on the other hand shows up as unreadable, and that makes no sense to me. Furthermore, when I run the program with the commented out line above instead of the combatUnits line, everything works correctly and test shows accurate and correct data (though, obviously, in goes out of scope immediately afterwards and is thus useless).

I'm just very confused as the why declaring a vector locally rather than as a class member would make any difference in this context...

Furthermore, I was just starting to implement the Turn_Manager class, what is posted above is currently the complete contents of the class. I created it in order to isolate certain functionality out of the Battle_Map class (which is too big and needs to have its responsibilities take down a few pegs). The functionality in question worked as intended when it was contained within Battle_Map.


#5065648 Officers (strategy)

Posted by Plethora on 28 May 2013 - 05:31 PM

Hmmm, let me ask you this... what is the impact on gameplay of these officers?  I feel like the difference between the earlier post about the court and this one is that I could better imagine what the court members would do with respect to gameplay.

 

At a glance I would say that getting stuck with incompetant admirals and generals should, theoretically, be less of an issue than getting stuck with incompetant people in your court.  Military organizations tend to be strictly hierarchical, and if you are playing the role of an emperor, once would imagine you must have a pretty firm grip on the military in order to have power.  Of course, that doesn't mean the emperor wouldn't have to occasionally put up with the screw up son of one of his biggest boosters wanting to be in the army, but still, I feel like you should have more impact with regard to the military than you would at court.

 

Although, here's a thought.  Historically speaking, in monarchies and dictatorships throughout history, high ranking military positions were often given to strong backers of the ruler as prestige positions.  It might be interesting to have some interplay between the court and the military.  Just a thought though.




#5064187 Battle System in a tactical battle (srpg style)

Posted by Plethora on 23 May 2013 - 10:49 AM

The same applies to multiple attacks and counterattacks: compared to the possibility of attacking once and retreating if fast enough or staying in combat only long enough to kill the opponent or until the number of received attacks is safe, commitment to an extended exchange seems highly and needlessly inflexible.

 

I tend to agree, but its nice to get a second opinion on the matter.  How do you feel about counterattacks in general, be it a regular thing that is balanced as such, or some variety of special ability?




#5063991 How to balance freedom of expression & abuse in games?

Posted by Plethora on 22 May 2013 - 07:05 PM

You can always just put in a reputation system, even a simple one.  Then allow a player to choose a minimum reputation rating to match with (maybe have some special rules about new players have to allow matching with other new players).  Prompt users to give an up or down vote to their partner after each match.  You'll have some people that downvote because they're upset for some other reason (or the immature players themselves giving downvotes just because), but those things tend to balance out once you get a sufficient sample size.




#5063985 Battle System in a tactical battle (srpg style)

Posted by Plethora on 22 May 2013 - 06:18 PM

I've been diligently working on my game for awhile now, and I have a pretty good idea of what I want to do with my battle mechanics overall.  But I'm starting to get into the details of coding it for real (beyond the very basic stuff), and there are still some aspects of it that I haven't nailed down in my design.  In this post I'm going to detail what I have decided, as well as some of the decisions I have left to make.  I'd love some feedback.

 

I'd like to say that specifically I'm trying to balance the complexity in such a way that allows for varied gameplay from one battle to the next, but also allowing a relative novice to the genre to catch on pretty quickly.  The system can have some complexity to it, but that complexity should be somewhat obscured behind a straightforward front.  Think of Pokemon... your average player probably doesn't really dig very deeply at all into the combat mechanics.  All he/she really needs to know is higher stats are better, there is a difference between special skills and physical skills, and certain types do more or less damage against other types.  Once those are down, pretty much all outcomes in a battle will "make sense".  However, for the hardcore among us, you can dig beneath the surface and see that there is some complexity to the system.  Pokemon strikes a good balance there.

 

Moving on...

 

What I've decided on to date:

  • I'm using an initiative based turn system.  This means that rather than each side having a turn in which it can move all its units, the units themselves will get a turn based on some initiative score.  Faster units will, over the course of a battle, get more turns than slower ones (this will be balanced in various ways).
  • I intend to do a lot with having different types of maps with different goals and victory conditions.  I also wish to vary size and scope of battles.  Some will be on small maps and the player will be able to use ~4-5 units.  Others will be much larger and allow 10+ units.
  • The things a unit can do will be somewhat standard for the genre.  A unit will have a regular attack, some selection of special skills with various effects, and so on.
  • A Unit, on its turn, gets 2 actions.  These actions can be used to move, attack, move twice, attack twice, use an item, etc.  I'm not against having special rules to balance things out if they seem overpowered.  Perhaps a second attack would carry a penalty, for example.  This will be tested and dealt with appropriately.
  • I intend to make damage as deterministic as possible, with little/no randomization.  Attacks will always hit, and the amount of damage dealt will be transparent and knowable to the player.
  • I'm 95% sure that I'm going with a system where a character has 4 basic stats (Strength, Intelligence, Speed, Cleverness) that will never change.  It's a big part of how characters will differ from one another when they all have access to some subset of the same skills.  There will be some additional derived statistics that will change over time.  For example, a character's Attack Level would be Strength * level or something like that.

Ideas I've had/Things I still have to figure out:

  • Make all damage dependent on the appropriate statistic directly.  I regular attack will do a characters attack level - the defenders armor in damage.  A "power attack" will do Attack Level x 1.5 - armor, and so on.  It's simple to understand, but not particularly interesting.
  • I could do the above, but throw in a weapon skill stat of some sort that would build up over time as characters use one weapon type over another.  Then throw in another multiplier based on that stat.  Still not all that interesting, but it would allow some additional differentiation of characters.
  • I've thought about adding a weight stat to all equipment.  This would effect a characters initiative and possible movement.  Going lightly armored would allow you to get around a battlefield very quickly, but heaven help you if you get caught by something big and strong.
  • Been thinking about how to balance out extra turns that some chars would get over others movement-wise.  Balancing damage output seems workable (you do half the damage twice as often kind of thing), but movement is a little more tricky I think.  Maybe its just ok to have smaller weaker units running all over the place.  Maybe I should just leave it be for now and adjust later if necessary.
  • I've thought about having multiple attacks (2? 3?) with counterattacks from the defender be the standard.  This seems like it has pros and cons.  Pro:  It allows for a diverse range of modifiers.  Example:  Burst damage, a character performs all 3 of his attacks immediately and does not recieve counterattacks until the end of combat.  Con:  It kind of clashes with the initiative based turns, where I am already trying to abstract the effects of speed on combat.

Well, that's what I have for now.  I would welcome any/all feedback and suggestions.  Thanks for reading!




#5063547 I want to learn

Posted by Plethora on 21 May 2013 - 11:09 AM

If you choose to go the C++ route, I cannot recommend SFML enough:

 

http://www.sfml-dev.org/

 

As was said above, if you really want to learn about making your own graphics engine but most would tell you that its not worth it. SFML will get you up and running with simple graphics on the screen faster than most other options you'll find.  Once you have a basic working knowledge of C++ you will be able to understand most aspects of SFML as well.

 

 

 

I will probably develop it for PC.

 

My goal anyway is not to publish it or to have people play it, I want to understand concepts of programming a game, like running states, how to setup a battle, how inventory works, characters movement... things like this.

 

If I were you, I would take an hour or so at some point and put down a concrete idea of the game you want to make.  Decide how it will work, and for your purposes, in what order it would be best to implement the different systems.  If you are careful to consider how you implement your code, you should be able to make it very modular.  Meaning, you can say, well first I want to learn how to display a couple of screens and control them with states.  Once I've done that I want to set up a battle (so you use generic characters and enemies with hard coded stats),  Then I want to implement an inventory system.  

 

Then you can just continue to add new pieces, but not until all prior pieces are in place and working.




#5063393 2D vs 3D for a solo programmer

Posted by Plethora on 20 May 2013 - 10:11 PM

I think another way to look at this question is to not talk about 2d v 3d at all. 

 

Do you have an idea for a game you want to make?  You should probably start there... if you aren't thinking of anything in particular right now, its very possible whatever idea you come up with it will lend itself well to one or the other.  Think of other games that are similar to the game you want to make.  Try to find other games that have an art style that you think would work well for your game and decide if you think you'd be able to emulate that style with some degree of success.

 

In other words, let your game dictate what you want to do.




#5062402 Massive memory leak

Posted by Plethora on 16 May 2013 - 05:05 PM

Also there is a second point, more specific for SFML users: I am using a resource manager class that loads all assets and provide them the other classes as needed or at the game boot. The resource manager holds sf::Image's and the classes that need to drawn something holds sf::Sprite's. Now, if I have two,three,four...a thousand similar instances of this class, will the resource manager still take just the memory needed for one sf::Image used by the consumer class or each instance will take more and more memory? Does this make sense at all?

 

I'm not sure if this helps, but personally I have a small class based mostly around an std::map that holds my sf::texture objects (sf::image in your case).  That's the only place that textures get loaded and they are all loaded one time at startup.  The class has a getSpriteByKey method that returns an sf::sprite with a given texture/image attached to it.  I don't create sprites until I need them (though I do try to keep them around once I have created them if I know I'll need them again where possible).




#5061309 Personnel (strategy)

Posted by Plethora on 12 May 2013 - 11:54 AM

For the 12 courtiers, having some sort of AI at work between them would be good.  What you could do to enhance this is to come up with some easily randomized backgrounds such as each one's family/faction/corporate allegience or however you want to separate it.  You then have natural rivalries based on that.

 

Then throw in a system where you, as the emperor, can bestow favor on one courtier or another for whatever reason.  This would grant a loyalty boost to whomever you chose but at the cost of decreasing loyalty among that courtiers rivals and also deepening divisions between them.  You could further fix the system such that the most competent members of your court are always members of small/non existent factions.  Thus, if you continuously reward the most competent ones, the rest of the court will likely grow to hate you.




#5060596 What an emperor of a space empire does?

Posted by Plethora on 09 May 2013 - 09:17 AM

The audience thing is good, but I think the real key to it all is to keep in mind that the emperor is inevitably going to have to deal with factions within his empire.  The emperor should realize that regardless of how he got there, the key to staying there is keeping support from other power brokers in his empire.

 

To that end, the actions you take as emperor should making your supporters happy, getting those who do not support you out of power, while simultaneously making sure that no one entity ever ammasses enough power to be a threat to you.

 

In practical gameplay terms, various factions should regularly make requests or even demands of you, you can decide whether or not to grant them, but the game should give you information on how that will effect the support you get from that faction. 




#5059530 Critique this idea for dividing up the XP! (SRPG Game)

Posted by Plethora on 05 May 2013 - 12:45 PM

Perhaps I should have explained the faster play a bit better.  I am more striving for a system where taking longer in a battle is a player choice rather than an unfortunate necessity (like FFT, for example).  When I say faster, I don't necessarily mean in terms of turns, or even time specifically.  I just mean a battle should move quickly.  I have a target goal where, if a player knows that all he/she wants to do with a given character is make a move and attack a specific enemy, there should be no more than 4-5 seconds between the start of that characters turn and the start of the next turn, attack animations included.  I won't be enforcing this on the player, and players that wish to take their time are free to do so.  Invariably, I feel like a player is going to want to take the time to use more optimal strategies, more special abilities, and better tactical planning in a big climactic boss battle than in a random encounter against some randomly generated scrubs. 

 

I thought about giving the player the ability to divide it up, and there may be some of that in the game in some context, I'd like it actually.  However, the difficulty isn't really the issue.  The player will always have access to battles and quests of all levels up to their current level.  Now, if the player wants to grind away on lowbie battles endlessely in order to get ahead, far be it for me to deny that.  But I would like to at least discourage it a little bit where possible.  I want rewards that are proportionally better for facing challenging battles, and I'd like to encourage the player to risk bringing lower level characters into the fray a little bit by offering bonus rewards.

 

Food for thought at least.  I'm definitely going to try and work in the ability to divide experience by choice.






PARTNERS