Jump to content
  • Advertisement

HappyCoder

Member
  • Content count

    909
  • Joined

  • Last visited

Community Reputation

5055 Excellent

About HappyCoder

  • Rank
    Advanced Member

Personal Information

  • Interests
    Design
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. HappyCoder

    Translation, in the shader?

    I'm not sure what version of DirectX you are using, but here is an example in DX11 http://www.rastertek.com/dx11tut04.html
  2. HappyCoder

    My first Game level in Unreal

    The outdoor scene is too noisy visually. I feel like there are too many unimportant details competing for attention. I do like the overall feel. There is definitely a unique style here to set you apart from other games.
  3. Sounds like motion sickness will be a problem. The best you can do is make a prototype and try it out. Google earth for VR has a mode when you move the edges of the view fade to a non moving grid and that helps combat it pretty well. You could make that a setting for the user. Good luck.
  4. HappyCoder

    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.
  5. HappyCoder

    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.
  6. HappyCoder

    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
  7. 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.
  8. 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.
  9. 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;
  10. The reflection normal is the difference between the centers at the point of contact.
  11. 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.
  12. HappyCoder

    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
  13. HappyCoder

    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);
  14. HappyCoder

    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.
  15. HappyCoder

    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.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!