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

AgPF6

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

165 Neutral

About AgPF6

  • Rank
    Member
  1. You are creating a pointer to an object of size float, but you are never creating memory to store the actual float. When you dereference the pointer you are accessing memory that is not available to you. Becareful also that the memory you create stays within scope for the entire duration that the function you are calling requires it or you will get an access violation. These are difficult to track down.
  2. Hello rAm_y, It also depends on the accuracy of your simulation. If you just need a number to get an index into something, for example some bonus item, then speed is more important. Look into XorShift.
  3. One of things that you have to remember is that your concept of "mouse" is really just an area in video memory being written to in a certain way which would produce a recognizable image as "cursor". this is accomplished by operations at the cpu level that produce a value that the video output understands to be a certain "color". The reason why I use quotations is because these concepts dont exist to the computer, but are manufactured so that you as the user can intetact with the system to produce meaningful results. Assembly is just a human readable form of binary data, and what a higher end compiler does is translate its easier to read langauge into binary instructions for the cpu to assign memeory locations a value that can later be used to do something.
  4. I would imagine that each point.z is a function of the radius. As the distance from the mouse cursor increases, height decreases.
  5. [code=auto:0] class a { public: class b { public: virtual void something() = 0; } } [\code] Not sure why you would want to do this.
  6. I'm not sure i understand.  When the object is built only one copy of type is included, and set to the appropriate value.  Each object in your design needs to have this to be recognized.  How is this redundant?   If you're concerned about redunant menory, why not just make multiple instances of the collections object and use them to roganize specific entites?
  7. You would access it by the same way you access anything:  by the way you defined it in your struct, except that you don't use this "->" you use this ".".    buffer [index].x
  8. I would imagine that most architects and drafters can't imagine the entire building they are creating either.  But that doesn't stop them from doing it.   Try to remember that programming is really a translation of an idea into machine language.  The first thing i try to do is imagine and write down what it is i want to do:   I want to have a box that rotates.   then I try to imagine and write down the steps that are involved:   Intialize a window intialize a system to draw objects create a cube draw the cube   I then break down each step into more involved parts.  The pattern here is to start with a simple idea and progressivly make it more detailed, before you wirte a single peice of code.   The more pedesign you do the easier it is to write your code.  I cannot emphasize this point enough.  Great buildings are designed before they are built, and are not trial and errors.  Architects don't stand at the site and direct where to put each support, only to change their mind if it doesn't work.  If you write code by trial and error, your systems will be small and trivial. But if you can learn to design your code before you start to program, you soon realize that you debug less, create more intersting and thoughtful programs, and it will be less stressful and more fun.   BTW, people who write code using one letter variables write code that is usually hard to read, difficult to debug, and probably took a long time to write.  Try using more meangingful names when designing your code.  It will make debugging less difficult, it communicates to the human much easier, and is easier to read by more people. 
  9. Instead of having a seperate class to list the members of the array, it might be easier to call a mthod in your buy class which lists the items in the players array.    Something like     //Lists the contents of the players inventory Buy.ListPlayerInventory();   Consider abstrqcting your classes a little more.  The buy class, which i think you intend to be some sort of portal with which the player interacts to purchase items, would not hold the inventory of the player, but would instead only add or remove from it.  A design solution might be this:     //holds items class Inventory; //has an inventory class Player; //holds items for sale //interacts with the Inventory class that it gets from the player. class Buy;   This way you do not need to be creating memory, but need only create objects and pass by reference.
  10. You can create a base class the has static members which pertain to the input aspects.  Because static memebers are visible to all the members of the class, these static members only get intialized once, but are available to all classes that derive from the input base class.    To destroy this class you could do several things.  Call a function called TerminateInput() that shuts down all the static members, or out the code into the destructor.    In all honesty though, input is usally just  a player thing.  I don't see why you would need to do this.