HappyCoder

Members
  • Content count

    906
  • Joined

  • Last visited

Community Reputation

5054 Excellent

About HappyCoder

  • Rank
    Advanced Member

Personal Information

  • Interests
    Design
    Programming
  1. Poker-based Card Battle RPG

    I like the idea. Some potential problems you may need to solve though. Not everybody knows the rules of poker and they are somewhat complicated. For players new to your game, dumping them into a combat with poker way be overwhelming if you don't somehow ramp them up to it. I see a problem varying difficulty between enemies. Your two options are better AI and more HP. Simply adding more HP may just make the harder fights feel more grindy, and better AI is invisible to the player making it harder for them to gauge if they can take a fight. Trying to beat a harder AI is very skill based, and some players may not be willing to get good enough at poker to take on the challenge. Most games let you grind to power up your character to make hard fights easier. On the other end of the difficulty curve, if somebody really good at poker players your game, they may get bored with the early enemies or can skip straight to the harder fights. The MP system seems like a good way to solve some of these issues. Perhaps you can level up your attack power to do more damage after winning a hand. Having a power level progression would help solve the last two points.
  2. Game Idea

    For you first game, I would shoot for something you could get done in a week or two. Think something simple as pong. While it isn't very exciting it is a good starting point. You could then try to modify your pong game to make it more exciting or pick a new project with slightly larger goals. Making games is difficult. It is easy to gloss over details that end up taking a lot of time, so start small for now to build up some skill.
  3. Unique Resource Ideas for RTS Game

    I'm an RTS fan so I'll bite Faith ( You need convert followers to believe in you to increase your power. Not an original idea, but i'll put it anyway) Hydrogen or other space gases for a planetary rts Old landfills in a post apocalyptic world
  4. The satisfying aha moment happened when I figured some strategies on how to solve the puzzles but that happened once instead of happening many times per puzzle. After solving a few, I was no longer driven to solve more. I only got part way through the first loop. There may be some people who would love this kind of puzzle but I don't think I fit in that group. For me, the downsides are there is a too much mental calculation and I feel like I am just brute forcing an answer. There doesn't seem to be a way you can partially solve a loop and come back to it later. It is all or nothing since each operation depends on every other operation in the loop. There also needs to be more interlinked answers like you have in chromanatsu and hexanatsu. Those are great because they let you solve one loop and that gives you information to help you solve another loop. That only works if there is only one solution to each loop though. My main suggestion would be to shorten the loops when first introducing the concept. If you could get familiar with the concept using loops of 4 then work your way up to larger loops, then it would give players time to develop strategies to find answers while keeping them in flow.
  5. I am working on a top down 2d western with a mechanic where death isn't a game over. Instead you enter the spirit realm, pictured in the purple and blue screen shot. While in the spirit realm you need to play to come back to life. It is still pretty early but I wanted to get some feedback early to refine the style before I make too much artwork. Any feedback would be appreciated.
  6. You also need to take into account the field of view of your camera. Generally speaking the perceived size follows this relationship perceivedSize = ratio * actualSize / distance So you need to determine some ratio, normally determined by the field of view, to base your calculations on. So as n example, if you want a 1 meter to appear to be 1000px at 1 meter distance then your ratio is 1000px = ratio * 1m / 1m ratio = 1000px*m/m So at 100m the target would be percievedSize = 1000px * 1m / 100m = 10px;
  7. The reflection normal is the difference between the centers at the point of contact.
  8. I did CS and do game dev on the side as a hobby. I have more creative freedom over my own projects, even if they are small and wont be big hits. I still enjoy it. A computer science degree is a great degree to get into gaming and it is also useful as a fallback for other jobs if change your mind about gamedev. I would recommend you stick with CS.
  9. Why Unity engine encapsulate everything?

    You could always add your own method extensions.   using UnityEngine; namespace GameObjectExtension { public static class TransformHelper { public static float getX(this GameObject target) { return target.transform.position.x; } public static float getY(this GameObject target) { return target.transform.position.y; } public static float getZ(this GameObject target) { return target.transform.position.z; } } } Then to use it   // top of the file using GameObjectExtension; ... var xPos = gameObject.getX(); More info here https://msdn.microsoft.com/en-us//library/bb383977.aspx
  10. Basic RPG Attempt

    Here is some example code.   // forward declaration class Item; class IUseBehavior { public: virtual void useOn(Item& item, Player& on) = 0; } class Item { public: Item(string name, IUseBehavior* useBehavior, int levelReq); } ... class Equipment : public IUseBehavior { public: void useOn(Item& item, Player& on); } class Consumable : public IUseBehavior { public: void useOn(Item& item, Player& on); } ... // Then to create an item Item potion("Sword", new Equipment(...), 1); Item potion("Health Potion", new Consumable(...), 1); I think I may be over engineering this specific example, but supposed we wanted to add an on aquire action for items.   class Item { public: Item(string name, IUseBehavior* useBehavior, IAquireBehavior* aquireBehavior, int levelReq); } ... class Curse : public IAquireBehavior { ... } ... // Then to create items // Then to create an item Item potion("Sword", new Equipment(...), null, 1); Item potion("Health Potion", new Consumable(...), null, 1); // applies a curse when this sword is added the players inventory Item potion("Cursed Sword", new Equipment(...), new Curse(...), 1);
  11. Basic RPG Attempt

    The terminology can be confusing. You do indeed use the reference operator to get a pointer. To pass by reference you would remove the reference operator, or deference if you already have a pointer. If you look up passing by reference vs pointer in c++ you will get a lot more information.   Sorry the original wasn't super clear. Equipment, Consumable, and EdibleEquipment would extend IUseBehavior and you construct one and pass it into the item when you create it. Right now, the item only has one action. To use it on the player. If that were always the case then there would be no difference between extending IUseBehavoir and Item. However, you may decide you want to add a on acquire behavior or a on player death behavior. It is much easier to have an Item class you don't extend and simply compose with many different combinations behaviors than it is to extend Item for each combination of actions.
  12. Basic RPG Attempt

    Overall it looks pretty good. You do a good job separating code. your play function in main.cpp is getting a little bloated. You are passing by pointer in many places void fight(Player *player) { ... } Where you could and probably should be passing by reference void fight(Player &player) { ... } I try to only pass by pointer whenever NULL is a valid value to pass. You item inheritance tree could be problematic. Suppose you eventually want to have an item that you can both equip and consume. Inheritance doesn't solve this problem well. An alternate solution to polymorphic items is applying polymorphism to individual concerns of an item. // forward declaration class Item; class IUseBehavior { public: virtual void useOn(Item& item, Player& on) = 0; } class Item { protected: string name; int levelReq; IUseBehavior* useBehavior; public: Item(string name, IUseBehavior* useBehavior;, int levelReq); void useOn(Player& player); ... } ... void Item::useOn(Player& player) { if (useBehavior) { useBehavior->useOn(*this, player); } } You can then have your standard equip and consume behavior void Equipment::useOn(Item& item, Player& on) { // pass the item with the stats so the player can save the item for when it gets unequipped on.equip(item, equipmentStats); } void Consumable::useOn(Item& item, Player& on) { on.consume(consumeStats); } Then you can add your edible items void EditbleEquipment::useOn(Item& item, Player& on) { int pChoice; cout << "Use Item --> Would you like to equip it or eat it?" << endl; cout << "[1:Equip], [2:Eat]" << endl; cin >> pChoice; if (pChoice == 1) { on.equip(item, equipmentStats); } else if (pChoice == 2) { on.consume(consumeStats); } else { cout << "Invalid choice" << endl; } } You have some "using namespace" statements in header files. This is considered bad practice since it pollutes the global namespace for any files that directly or indirectly include it.
  13. Your requirement for precomputing for performance reasons and having it dynamic to respond to changes are at odds with each other. Being that the precomputing seems like a premature optimization I would do what Norman Barrows suggested and just do it real time. 100s of tiles should be no problem for computers these days.
  14. Communism the Card Game

    Excellent point. I will think about ways to include more interaction. Thanks. Noted. I will definitely explore this. Once I get the gameplay sorted out I will look for a better theme. Yeah, good point. I will toy with players retaining cards between rounds. I did do some simulations where each AI only plays one of three strategies. Overproducer - Play all work cards and any victory point it can afford Match - Play as many victory point cards it can pay for exactly Underproducer - Play all victory point cards and any work points up to their own cost I found that each strategy would beat one of the other two and lose to the other meaning players couldn't just gravitate to one of those strategies to win. I agree with penalizing non-mooching play, the point of the game is to anticipate and take advantage of mooching. Thank you
  15. Fast Character Modeling?

    If you could create a single base model with animations you could reuse it for all your characters and add variation by simply having accessories you attach to the different bones of the rig.