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


  • Content count

  • Joined

  • Last visited

Community Reputation

467 Neutral

About Azaral

  • Rank
  1. I must prefer functors. Don't have to deal with any extra weird syntax. Plus, they can store data.
  2. I would create a header file with a namespace like Tools or something. Inside this namespace I would have the collision functions. I would also have another set of headers that define the collidable types, IE AABB, a circle, etc. I would have these have NO default constructor to force their initialization upon instantiation. I would also have as much data possible in the collidable type be pointers to the relevant data. For example, an AABB would have pointers for the position that point to the position of the entity it is for. Then if possible have the width and height be pointers as well, but they would probably just be non-pointers. I would define a function for each type of collision possible. For example, I would have three functions, one for AABB vs AABB, one for Circle for Circle, and one for Circle vs AABB. They would all be overloads of HasCollided (or in your case, isCollided). Then when I run collision detection, I just take the collidable data from each object and the correct function will be ran. It would require minimal code at the front end of it, just a simple function call. The collidable data should also not be inherited but be part of the regular data for the object. By having as much as possible in the collideable data be pointers, they will automatically have the current values without needing to be updated manually. You could end up with a lot of collision functions to define and that can be alliviated somewhat by more involved programming, but this I think is the simplest way to do it and it is quite effective. For handling collisions, this could be another piece of collision data, which I would also have separate from the collision detection data. Then you would have the same function overload process for how to handle all the different collision types. With this you would call HasCollided( a.GetCollisionDetectionData(), b.GetCollisionDetectionData() ); and if that is true then run HandleCollision( a.GetCollisionData(), b.GetCollisionData() ); I apologize in advance if this doesn't make any sense and I sound like I'm rambling. One too many beers and it's bedtime as well lol.
  3.   Ideally, a class knows nothing of another class. Two classes should interact via an interface class or some other means. Instead of having the player call a function from collision to determine if it is colliding with the wall, have a function that takes the player and the wall as arguments to determine if the player is colliding with the wall (and expand this for all the things that can collide). This way, player doesn't need to know anything about collisions or walls, player just needs to know about player and wall just needs to know about wall.
  4. http://www.youtube.com/watch?v=sRn9lhkVaxw
  5. Interesting stuff.   Combining this with your other video on ditching diffuse maps could yield some startling visual effect I think. If only I knew more about shader programming (I've done precisely zero).
  6.   You are correct that users have no right to mod a game, they also have no right to not mod a game. They can either do it or they cannot do it. They couldn't sell it or distribute it legally without permission from the copywright holders of the software that they based their mod on (as far as I understand). This does not stop them from doing it for themselves. Modding could possibly be in the form of creating/performing a cheat. In the context of the discussion, it is cheating. What I am saying is that in a strictly single player game, where what one player does in their game has NO bearing whatsoever on a player playing their copy of the game, cheating is irrelevant and you are wasting your time trying to prevent it. The only one you are satisfying with your attempts to prevent cheating is yourself.   The idea of creating a game is to make something that someone will have fun with. I fail to see the problem of players altering a game so that they enjoy it more is a bad thing, and such alterations have zero affect on the other players of said game. I see it as a good thing. Are they altering the experience I planned for them? Yes. Is this bad? No.   You are trying to give a ball to a group of kids so they can play basketball, but get upset when they decide to kick it around and play soccer instead so you run out and say "No! You must play the game I want you to play, basketball!". I give them a ball with the intent for them to play basketball, and when they start playing soccer I would be estatic because they are having fun with something I gave them. My point with all this is to save you time by having you not worry about something in your design I think you should not worry about and to help you create a game that will be more fun for people. I think you have placed your game/idea on a pedestal and think it a kind of personal insult to yourself and your creative idea for anyone to not interact with it in the way you want them to.
  7. OR they fail and fail and fail and since they can't do anything but start over or give up, they give up and call your game crap out of frustration. Actually, 'fail and fail and fail' won't really be possible in my games, neither will checkpoints nor cancelling autosave be possible. You fail, you face the consequence, move on and . . . There'll be different things in my games and if isn't implemented before i start making my games, it'll be new things. One more thing, shouldn't the player play within the developers programming? If not, i would have loved to keep going straight in the gtavc but unfortunately, you get magically turned around in the water. Should you let them implement what you didn't program into a game? What if what they implement your idea for a sequel? I'm just asking.     If they want to change the game that they bought from the original, I don't care (speaking of strictly single player games). They are increasing their fun. Sure, I put out a game and I intended it to be played a certain way, but if they change it to make it more enjoyable for themselves then who am I to deny them that?  That would be like deriding anyone who ever writes any fan fiction. They are taking something you made and making it more enjoyable for themselves. You are treating the player as an adversary instead of a partner. As far as implementing my idea for a sequel, they are more than welcome to do that. However, their version of a sequel could be vastly different than my idea of a sequel, and if I the, the original creator of said universe, denounced it, then I doubt anyone would put any credence to it. It could even be spun off as a sort of split in the timeline. It would force me to do a better job. It would be like if someone made a Mass Effect 3 that doesn't have a balls ending that turns the entire series to poo soup. Also, see fan fiction example above.
  8.   [b]OR[/b] they fail and fail and fail and since they can't do anything but start over or give up, they give up and call your game crap out of frustration.
  9.   Fixed.  Also varies depending on the type of snow: dusty and dry snow vs more moist snow.     LOL yeah
  10. 10 inch of snow = 1 inches of rain. There is far less water in snow than there is in rain. Unless you have a ridiculous amount of snow happening, no. You have to figure that the rate of snow would have to be greater than the rate at which the fire can melt and then boil the snow, and given the small amount of water in each snow flake that rate is pretty fast.   edited for snow to rain correction
  11. I think the more pertenent question, from a game design standpoint, would be if it is a signle player game, then why care? You are only being evil towards the player. It should be an option, not a requirement. The player is not your enemy, they are your friend. If they want to cheat, then so what. The only person it affects is themselves. Save yourself the trouble and time and just simply don't worry about it. That's my opinion at least
  12. I use SFML 2.1 and I think it is fantastic. I use all parts of it and have not had any issues thus far.
  13. Sharing. Wasn't quite sure what to call it, hence the Overview? part.
  14. Here is a link to my blog in which i lay out the background? overview? for the game I am making called [i]The Merging[/i] http://themerging.blogspot.com/