Strewya

dunno if it's just me, but that picture link is broken.

also, why not use Git from console? more control that way.

Ah ok, my bad, i honestly thought that would work, and had no way to check until now.

 

Theoretically you could use an std::vector<D3DXVECTOR2> and just push back values as needed, and then draw them by passing the address of the first element (&vec[0]), and it would work the same, and would be exception safe too, as right now if you get an exception in between the new and delete calls by any chance, you leak the memory.

I have to agree that the rule should be the Rule of Two. If you need a unique assignment or copy ctor, then you really need both of them. If you have smart pointers (and you should, instead of raw pointers) or const members, the autogenerated destructor does the job right, but the assignment and copy ctor need to be custom.

It's because you're updating the position of one copy of your paddle, and drawing another.

Doing a push_back() in your ObjectManager makes a copy of your LeftPaddle object.

You should either change the list to be a list of (smart) pointers, or somehow retrieve a reference/pointer to the paddle object from the ObjectManager and update it when input occurs.

There was one last thing I thought out but its on the more technical side and most players wouldn't see it. Its a "anti-macro" code built into the game. Essentially it works on the principle of algorithm detection. The code will constantly and passively monitor command inputs and will catch patterns when they repeat. This code posed a programming hazard because after a long period of recording the information has to be dumped or else the load is too much for the engine to process. I figured I could set a timer (its set for about 24 minutes or an ingame day) to dump the recorded commands and start monitoring all over again. This means a player (if they found out about the 24 min aspect of the code) would have to record a full 24 minutes worth of actions into a macro. If the code detects anything fishy, all stat gain (both passive and active) halt until the end of the 24 minute cycle. That means if people even try to grind in a cheesy exploitive way they get the boot lol

This will actually punish legit players as well. When they find something that works for them, and they start manually repeating those actions because they dont have access to/dont know how to make macros, but find those actions are easy to repeat often for moderate gains, your script will see that as a repeating action, mistake it for a macro and deny the player any gains for their efforts, which to them will seem for no apparent reason (as it's hidden from them). And those repeating actions even might be a perfectly legit playstyle. I doubt you can ever predict all the actions every player will ever perform in your game, and build code to prevent exploits, but not actual player performed repeating actions, in a consistent and smart way. If you're trying to frustrate players, go right ahead

As for your health/healing systems, you're basically punishing players with long wait times between combat actions because they 'might' use exploits. I'm assuming here that a sizeable part of your game is combat itself (assumption based on your introduction post), and having to wait a long time to continue playing that part of game because you're too beaten from the last fight is the wrong approach, and will turn players away from the game. Even legit players who are just not that good at fighting are forced to wait over 2.5 hours before their next combat encounter. And you said it yourself:

The other choice would be afking but who really wants to keep doing that because theyre failing at not taking damage?

People will rather play a fun game, than a game that punishes them for a seemingly normal (albeit unskillfull) play style. And judging by your proposal for combat in the introduction post, combat controls seem really complex (emphasis on 'seem'), which would only make the problem bigger, and because of that people will most likely either avoid combat altogether, or quit your game out of frustration/boredom.

I do believe that without a prototype, your systems are too undefined and open for interpretation, which is why i'm giving you both legit players and an exploiting players perspective.

just a thought here, gaining stats just by wearing stuff opens you up for exploits such as "i'll just equip this sword and shield and go afk for 2 days, and when i come back i'll have a large amount of stats gained", or something my friend did in Skyrim, "i'll go to a low level dungeon, find some weak monster that has lower damage than my regeneration, go afk and gain huge amounts of permanent health".

You need to be really carefull with passive stat gains because players *will* find a way to exploit that system. If the stats are gained on use, then you need to clearly define what that use is so players can't do the 'use' while afk.

For instance, walking isn't a valid 'use' as it can also be easily exploited (think walking into a wall or walking in circles, which can be done using some smart keyboard/mouse macros). Casting a spell alone also isn't a valid 'use' because players will cast spells into empty space/walls in some safe environment and gain stats easily without any risk.

TMove::TMove(int Index, int Moves, int Parent)
{
	index = index;
	moves = Moves;
	parent = Parent;
}

 

is this an error in copy/pasting, or does your actual code has the 'index = index;' line? (note the missing capitalization of the rhs value, you're essentially assigning index to itself here)

might want to look at libconfig, which i discovered because of this topic, and on first glance it might be just what you're looking for.
http://www.hyperrealm.com/libconfig/
(check out the documentation link on their site)

http://www.cplusplus...cctype/toupper/
toupper only works on a single char.
do something like this:

std::string uppercase(const std::string& s)
{
   std::string ret;
   ret.resize(s.length());
   std::transform(s.begin(), s.end(), ret.begin(), toupper);
   return ret;
}