• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

HappyCoder

Members
  • Content count

    902
  • Joined

  • Last visited

Community Reputation

5052 Excellent

About HappyCoder

  • Rank
    Advanced Member
  1. 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.
  2. 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;
  3. The reflection normal is the difference between the centers at the point of contact.
  4. 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.
  5. 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
  6. 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);
  7. 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.
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. double previous = getCurrentTime(); double lag = 0.0; while (true) { double current = getCurrentTime(); double elapsed = current - previous; previous = current; lag += elapsed; processInput(); while (lag >= MS_PER_UPDATE) { update(); lag -= MS_PER_UPDATE; } render(); } This approach will give the same results on different devices. Rendering can only happen so many times per second. You usually target 30 or 60 times per second. However, if the framerate lags then you don't want the simulation to suffer. Using a fixed independent timestep will ensure that the game runs consistently no matter what framerate is. Have one update for each render means if the game starts to lag then you will have larger timesteps in your simulation making the simulation depend on the framerate. This can introduce bugs that only show up when the framerate drops or on slower devices.
  13. Unity

    You could write your own raycast trigger   using UnityEngine; public class RaycastTrigger : MonoBehavior { public float raycastDistance = 1.0f; public LayerMask mask = -1; public void Update() { RaycastHit hit; if (Physics.Raycast(transform.position, transform.TransformDirection(Vector3.forward), out hit, raycastDistance, mask)) { gameObject.SendMessage("OnTriggerStay", hit.collider); } } } As a warning that is untested code, it may not even compile but hopefully you can get it to work for you. I didn't implement OnTriggerEnter/OnTriggerExit but you should be able to figure that out.
  14. I recently got addicted to a game called Alcazar on Android. The premise is simple, you draw one continuous path inside the player area, pass through every square once, then out the player area. It was very simple to learn but had a good depth of strategy. It was one of the best puzzle games I have played. I would recommend taking a look at it. 1. Easy to learn the basics but it should offer interesting gameplay. The puzzle should be decomposable meaning you can solve the puzzle in parts. Solving one part gives you clues to solve another part. Think of a Sudoku puzzle. Solving one 3x3 square gives you information to solve another 3x3 square. The parts are interconnected. This lets you work in a part, if you get stuck you look at other pieces. 2. I don't know about trends but for my personal taste I don't like puzzles that mostly take a simple strategy and brute force. I should be experiencing "aha" moments while solving the puzzle. 3. Just a good core puzzle mechanic with enough diversity to not get bland. I don't need fancy visuals, although its hard to market a game that doesn't look good. 4. Not that often. I usually play when I have a few minutes where I need to wait, so I can't commit to long puzzle session.s 5. Paid in advance. Alcazar was free to download but you had to pay a one time price to unlock all the puzzles. 6. Not sure, I don't play much. 7. I like to concentrate and do some deep thinking.
  15. X = 1/2 * a * t ^ 2 V = a * t -> t = V / a // Looks like you dropped an 'a' here X = 1/2 * a * (V / a) ^ 2 = 1/2 * V^2 / a 2 * a * X = V^2 And the result V = sqrt(2 * a * X);