• 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

132 Neutral

About sss_abaker

  • Rank
  1. Yah this is all good advice, and its something I have been trying to hammer home with my hobby team. It's especially important if you lack experience. My team and I are creating a disposable game at the moment just to see if we have the people to do it. After that we'll decide if we want to make somethign more serious at which point we'll start from scratch and plan it using the mistakes we made as a guideline to creating something a little more all purpose. (Reuse, refactor, rewrite, etc). We'll also have a better idea of what kind of game we're capable of making, besides it being fun ;p
  2. I'm building my own engine because engines like Unity are unappealing to me.... And not because of the fact that it does or doesn't provide me what I need, but simply because I want to get something more out of it and that is knowledge and experience. If I build an engine, but I stop there and I don't make a game, I'll be happy.
  3. [quote name='bimmy' timestamp='1341597811' post='4956403'] Decompose functions. Every function should be short (2-10 lines) and every statement should be at the same level of abstraction. This will do wonders to avoid duplication and (if you name your functions well) dramatically improve readability. If you have a long function, and you're not sure how to split it up, first just chunk it into blocks, then look at what each of those blocks does. Whenever you end up with two short functions that are similar, try to make them identical and then remove one. [/quote] That's a little extreme. You shouldn't break a function up into many smaller functions unless you need to. You seem to be advocating doing this for the sake of doing it.
  4. I figured. Thanks for the confirmation. I was nodding my head throughout this thread until I came across that claim and was pretty sure that's not how it worked.
  5. __declspec(align(16)) seems like a simpler option, but will that translate over to video memory? You're aligning it in system memory just fine, but I'm not sure if it is treated the same way when you map it. Please confirm.
  6. I suppose I came in half cocked. I don't optimize as I code myself and I use polymorphism pretty liberally. I simply code with those thoughts in mind. But I was of the mind that polymorphism's cost was still a determining factor when deciding whether or not to use it and I never did any experiments to confirm. Thanks for setting me straight guys.
  7. Except that the strategy pattern comes with a significant cost and that's the cost of virtual look up every time you call a Strategy's method. Optimized code is not necessarily the best looking and most manageable code. So ask yourself and clarify for us, do you want performance or convenience? With that in mind notice that the examples are written in JAVA. Most Java apps don't care too much about performance on the level required by a game.
  8. [quote name='Cygon' timestamp='1340101692' post='4950531'][list] [*]Forfeit logging altogether. I've done this in my code. I'm going all-out with assertions for pedantically checking internal states and exceptions for any usage error. Since the point of logging is to help you find the cause of errors quickly, by not letting any inconsistency, bad return code or missing capability slip under the carpet you remove the need for logging. [/list] [/quote] This is what I do. It's easier to find bugs in the debugger, go figure. And Asserts make your program stop and tell you why IMMEDIATELY. There's no combing through log files to find out why your geometry isn't showing up. Simply add an Assert. You can easily remove asserts from release code when you know your stuff works, by using #define.
  9. I guess hating on globals is the cool thing to do here. LOL Standard function call is the way to go. Hell you can even use your Logger class if you want. Except you keep that hidden. [source lang="cpp"]//basic example yo. void logMessage(string message) { static Logger log; //post log message here using log object. log.log(message); }[/source] This is only really required if Logger keeps any state, such as the file its logging to among other things.
  10. Without university you'll only ever be a run of the mill software developer that can write rudimentary engines. When doing university you go from being overwhelmed by the concepts in these articles and articles like these to being able to understand the concepts almost right away. Like someone here said, its a great foundation.