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

zeidrich

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

125 Neutral

About zeidrich

  • Rank
    Newbie
  1. One thing that is important is, if you want a programmer to do something, make sure it is something that's possible. Think it through to the end. I worked on a project once on a system for a boarding house where beds were assigned to patients. Sometimes patients would check in before other patients would check out, and they would be assigned the same room. The customer wanted to have a report which would show all of the patients in the rooms. They wanted it to show the patient that was already checked in to the room some times, and in others they wanted to know the patients that were newly checked into the room at other times. They didn't want to see both names at once, and they couldn't provide me with a reasonable explanation of when they would want to see which. They just wanted the computer to mystically understand what their intention is when they went to open that report. They didn't want additional options or controls or reporting options because that was too complicated. In the end I wasn't able to implement it as they wanted because what they wanted was only half-conceived, the rest was just magic. They needed to either compromise on the amount of information they were willing to put in to the system, or in the amount of information they were willing to be served by the system, but they couldn't expect the system to magically determine what was in their mind.
  2. c++ doesn't do graphics. It depends on what libraries or whatnot you use to do your graphics. When you change your resolution, generally some kind of event is triggered carrying information about the new resolution. You then respond to that event by changing your layout to appropriately deal with the change. Do you show more? Do you scale up? Do you do neither and paint it on top of a background? A good way to deal with variable resolutions might be to use relative screen space coordinates instead of absolute pixel coordinates. For instance, x=0 would be the leftmost side of the window, x=0.5 would be the middle, and x=1 would be the rightmost edge. This would make your image always fill the screen, but as the above poster mentioned, you'd have distortion when the aspect ratio changed. You could then worry about detecting and correcting that distortion. But in all, exactly how you do it is really dependent on what tools you are using to get anything to show up on the screen at all.
  3. You are using immediate mode, which is deprecated. Is GLuint LoadTextures(const char* filename) returning successfully? You have it return false when it fails, but you never test to see if it failed, you just assume that it succeeds. It could be something as simple as not having the correct file path or format of the texture being loaded, and since you just ignore it and try not to set the texture if it fails, you never know. I don't know enough about the bmp format you're using for "Crate.bmp", how SOIL is used, or where the file is located to make a judgment, however I am certain that if you were to fail to load the texture properly and SOIL_load_OGL_texture returned 0, you would experience the issue you are noticing.
  4. I agree with slayemin, Either do one of two things. 1: Design around concepts that you have been taught to demonstrate understanding of those concepts. Consider your data structures and why you might use one over the other, explain the reasoning. 2: Design around a concept that you've been taught, but improve or customize it to your use case to demonstrate mastery of the concept, or extension of the concept. In my own university experience I was asked to write an AI bot that mapped a maze given only local cues to its surroundings (IE: you couldn't look at the whole map). My implementation did better than pretty much anyone else in the class, however, I only got a marginal score because many of the heuristics I used, when asked "why" I couldn't give a great answer. Often it was just "I tried doing it these 3 ways, and of them, the third worked better". And while I did well on any maze generated, I couldn't explain exactly why. Later I realized that I was using certain concepts, some properly, some less effectively than I could have been. I am certain that if I had been able to demonstrate my understanding of those concepts I would have received a better grade. University isn't about making it work, it's about understanding concepts.
  5. An engine is 3 parts. See http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller You have the model, which keeps track of the state of the game that you're making. This is going to be where you would manage things like your physics and AI. You have the view, which is the component that takes what information is stored and generated in the model and displays it for the user. This would be things like your renderer and sound system. You have the controller, which is where you're going to be taking inputs from the player, and deciding how you're going to manipulate the model based on those inputs, or how the view describes the model. Generally, you have a main loop. This loop repeats until the game is ended. What happens in the loop is you capture inputs from keys, you perform any ongoing calculations based on the state of the game and the inputs recieved, and you update the view to reflect the current state of the game. An map of it might look like this Main Loop: HandleKeypress Function DoPhysics (affected objects fall based on time elapsed since last call) MoveCharacter (based on keypresses recorded maybe? Check for collisions? Whatever.) RenderScene Repeat The tricky part honestly comes down to doing those things efficiently. If you want to run at even just 30 frames per second, you have to spend no more than 33ms on calculations between frames. When you want to work with voxels, you have a large amount of data, so you need to find ways to work on that efficiently, when you want to work physics into it, then you have a large amount of points interacting with a large amount of points, which gets even harder. If you want to start, find out how to make a 3d scene that accepts inputs. Use OpenGL or DirectX. Just getting stuff on the screen is a challenge if you've never done it before. Then come up with a way to represent your data, put that data on the screen, come up with a way to handle user input, use that input to change the data or move the camera. Finally, find a way to do it quickly enough to be acceptable, and eventually write it to (and read it from) permanent storage if you want to be able to save games.