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

yckx

Members
  • Content count

    738
  • Joined

  • Last visited

Community Reputation

1298 Excellent

About yckx

  • Rank
    GDNet+
  1. Can you post what information the debugger gives you when it stops there? It should give you a stack trace and a detailed message of why it stopped there.
  2. Really? I always assumed the shader only had access to the current vertex. Although, I guess if your generating all the vertex data within the shader, you could do it for any arbitrary vertex /instance index. Interesting, but I don't immediately see an application. My brain isn't over the post-Halloween fug.
  3. Have you tried a debug build? Debugging should give you a more detailed error message. Are you sure the error occurs in this file? You're missing a main() so I'm guessing you have more code. Also, your if conditions in Game::Exit() and Game::GameLoop() don't do what you think they do. You're setting game State instead of testing it.
  4. Please post your relevant code for better help.
  5. Avoid this. Your code may be coming out nice, but if you keep rewriting sections of code as you finder better techniques then you'll never actually finish your game. Write code. Once it works, leave it alone. If you don't like it, make a note of it, but move on. Once you've finished your project, then you should go back and re-evaluate the code you noted earlier. Try to find more elegant or appropriate techniques. Then, use what you learn in your next project. Otherwise, you may be improving your coding skills, but you won't have anything to show for it.
  6. I did a little looking around and found https://github.com/ejmr/Luvent, which might be of interest to you. It bills itself as a simple event library and was written with love in mind. What I've been advocating is basically an event system, and I figured that if you haven't quite figured out how it all fits together then it would likely be easier to use a library than to write one :) And studying the code may help you understand the concept better.
  7. Well, the grunge/grime doesn't need to be heavy enough to actually be grungy and grimy ;) Unless you're specifically going for that look, just aim for a lived in and we'll used look. Few things are new in a nursing home. There might be scuff marks on the walls from the wheelchairs. Wear patterns in the carpet would follow high traffic paths. Maybe the back door has a discolored spot on it from where those staff who smoke tend to push on it with their nicotine stained hands. Dawoodoz's suggestion of nearly transparent layered textures is a good one. You don't necessarily want the added layer(s) to stand out, Maybe they're so subtle you can't immediately notice them, but they still manage to provide some visual interest and break up large sections of flat color.
  8. I totally get that this is a big paradigm shift, and that it takes some time to process and get comfortable with it. I wish you luck in finding more concrete articles, but I doubt you'll have much success. Articles tend to have example code to illustrate an approach rather than exact code from a specific game. Each game is different and each programmer or coding team has individual conventions and ways of doing things, so there isn't really any chunk of code that can just be dropped into any given project and be expected to work. Hence the abstractions. Admittedly, this can cause difficult in understanding the article, but them's the breaks. If you come up with any more specific questions I'll try to answer them, but otherwise I'm not sure what else I can tell you, other than give yourself some time to study it and let the concepts marinate and sink in. In my experience I've had to struggle with some concepts for a while, and finally everything clicks and makes sense during a moment when I'm not even actively thinking about the subject.
  9. Do you have experience making simpler games, or are you jumping straight into the 2nd platformer? I'm guessing the latter. Writing simpler games and working up to what you want to do may seem like the long road, but typically it's the better way to go. Because trying to write a program that's significantly above one's skill level is intensely frustrating. It's just not worth it. Believe me--I was one of those guys. The typical progression I'm seen is something like Pong, Tetris, Pacman, 2 platformer. Pong should be doable, or be an attainable goal if you don't currently have the skill for it. After that, follow the list in order. Each game builds on concepts learned from writing the previous one, and introduces new ones. Don't worry about writing perfect code. Write working code, and if a section of code feels clunky or you just think that there must be a better way to do this, use big obvious remarks so you can find that bit easily later on. After you've finished the game, go back and take a second look at the sections of code you flagged. Now is the time to research better approaches. After that, move on to the next game. It's quite likely that you will discover that some of the code used on the previous game will be useful for the current one. Some more code could almost work but would need to be tweaked a bit, or reworked into a more general approach so that it can accommodate both games. As you work your way from game to game, you'll gradually develop a code base of things every game needs and things frequently useful in many different games. There's your engine.
  10. Okay, I'm less familiar with lua than I should be, and I'm out of practice as well, so with that caveat... The actions to be mapped shouldn't really correspond to how the input is received, but rather just to things the player can do in the game. So instead of "attackbuttonpressed" there would just be an "attack" action. You may also have actions such as moveleft, moveright, jump, useonject, useselectedinventoryitem, selectnextinventoryitem, selectpreviousinventoryitem. You get the idea. By "factory" I mean an object or function whose purpose is to create certain objects. You may or may not find it helpful to have a GameObjectFactory. By registering game objects I mean that, when a game object is created it can be added to a table of objects that will handle a given action. In lua, you can create callback functions so instead of having a table of objects that handle an action you can have a table of callbacks to iterate through and call. So what I'm thinking is this: For each action in your game you have a callback table. When a game object is created, you add a callback function for that object to the callback table for each action that object should handle. I'm thinking an object factory can help automate things here. When a player presses a key, instead of just adding that keypress to an input queue, look up what, if any, action is mapped to that key and add that action to an action queue. (Maintaining both an input queue and an action queue would be redundant.) Then during your update, iterate through the action queue, and for each action in the queue, iterate through its callback table calling each callback function in turn. Does that make sense to you?
  11. Does every game object need to handle every keypress? I'd consider mapping the key presses to valid actions (which would allow for configurable controls), and then iterating through the action queue. Game objects can then either register themselves or be registered by a factory to listen for when an action is broadcast. This could be done action by action or actions could be grouped into types and game objects could listen for specific types of actions. Also,http://www.gamedev.net/blog/355/entry-2250186-designing-a-robust-input-handling-system-for-games/ might give you some ideas.
  12. I used to do something like this, but it's risky and error prone. If GameServices is global, then you are exposing these systems to your entire program. It becomes easy to use that access point in places where one really shouldn't, tightly coupling disparate systems that really shouldn't know about each other at all. And tracking down a bug can become extremely difficult since function calls aren't localized to a well defined subset of code. If your passing your GameServices object around, it's somewhat better, but then why not take the even more better approach of passing these Manager classes specifically to the objects and/or functions that need them? Not that your approach doesn't work. It does and can be okay for small projects, but it allows the introduction of some nasty bugs, and can become a crutch. I couldn't see how to structure my code any other way until I finally scrapped my entire code base and vowed not to go down that path for my next project. And now I'm a better coder and my code has no hidden dependencies, and is easier to understand and maintain.
  13. Maybe some detail textures and decals here and there. You needn't go for full on grunge/grime unless it suits the scene's mood. But some subtle physical texture (normal mapping or similar effect) and a little dirt or faint old stain or thread worn patch here and there where it makes sense can turn a room from a model into something that's been lived in. Or even provide narrative clues to whatever story you decide to tell.
  14. Basically, a game goes through an initialization phase setting up everything it needs, then enters the game loop, which repeats until an exit condition is satisfied (such as the player choosing a Quit option from a menu). Several things can happen in a game loop. Typically there's a means to keep track how how much time has passed since the start of the previous loop. Input can be polled from the player (also any AI routines for enemies or input from the network if your game is multiplayer). The game updates based on this input and what state the game may be in (menu, ingame, paused, win/loss. . .). Game objects may be moved, stats may be altered, physics may be simulated, the game may enter a new state. A lot of things can happen here. Graphics and/or audio is updated and rendered based on whatever logic has been updated. Rinse and repeat.