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

Topics I've Started

I'm holding a raffle for a pretty cool item. Want to take part?

05 June 2014 - 06:26 AM

Hello there, I'm posting this to announce a raffle I am running related to the game that I am making, called Spellbook Tactics.  I am fortunate enough to have a friend who hand makes plushies in a pretty cool way I've never seen before.  She made one for me based on a character from my game and now I am raffling it off as a way to promote both her work and my game.  The details for the raffle can be seen here:

 

http://infinityelephant.wordpress.com/2014/06/03/twitter-contest-awesome-prize-courtesy-of-artist-llama-details-inside/

 

To be entered, all you have to do is retweet this tweet:

https://twitter.com/InfinityEleph/status/473922052987322369/photo/1

 

That's all there is to it!  :)


Code samples?

23 May 2014 - 10:29 AM

So let's say I have an interview and I am asked to bring some samples of code I have worked on. What sorts of code would be ideal for this?

I figure ideally I would want to showcase something relatively concise but complex, perhaps an elegant solution to a fairly complex problem, but what of other considerations? If I am proficient in several languages, would it be advisable to bring samples of more than one, even if I would consider most of my best (most recent) work to be in one language? How big a sample is too big? Other considerations?

What am I missing here?

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.

Storing/Loading Randomly Generated Terrain.

28 May 2013 - 10:59 AM

I'm working on a 2D top-down RPG with a free and open world (to some extent anyway).  As you explore the world, new terrain is generated for you in the form of chunks.  I have the terrain generation working using the Diamond-Square algorithm and while is pretty simplistic right now, it works.

 

I'm trying to work through how I'm going to save that data once it's been generated, since, after its generated it should remain constant in further sessions.  Within the engine right now, I simply treat each "chunk" like a tile and I have a vector that stores them in order, however this only really works when chunks are uniform squares, and I do not intend this to be the case in the final version.  I have two thoughts about how to proceed:

 

1)  Continue doing it as I have been but add some supporting data where a given chunk holds pointers to all of its borders.  If the player approaches the edge of a chunk and there is no border data, then generate a new chunk on the border.  Else, load the desired chunk from memory.

 

2)  Go brute force with it and don't even store data as chunks.  Have an absolute coordinate system where the player starts at 0,0 (or some other arbitrary coordinate), and store individual tile data just as individual tiles are stored within chunks.  I could still use chunks to generate new terrain, but I wouldn't store them as such.  Seeing as all that really needs to be stored is a couple of ints per tile I could store and load everything from memory at session start/finish for awhile before starting to see a performance hit (I would think anyway).

 

Either of these methods would probably work, but I'd love to have some input on which would be best, and I'll definitely consider suggestions for some alternate method.

 

:)


Battle System in a tactical battle (srpg style)

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!


PARTNERS