• 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

378 Neutral

About 00Kevin

  • Rank
  1. btw,  you gotta love coders who, before they even begin to make modifications, waste half the day or more changing the coding style.       One guy I worked with changed all the database commands to upper case.   I was like really?   As for camelCase or PascalStyle,  my pinky has been brutalized on this shift key because you! 
  2. This is a subjective opinion presented as an objective fact. ...and it's not even a popular opinion.   Lowercase with underscores is actually the most 'official' style that C++ has, as it's used by the standard library (and many other projects). The people who choose it would say the opposite opinion: that CamelCase is bad style and makes code less readable..   I work with one programmer who hates underscores.   So we all try to add a few extra once and a while just to hear him scream "I hate f**king underscores!'.    
  3. The problem is that this kind of convention is brittle. It encodes information about scope into the variable name, but if you refactor to change scope the encoding is wrong and the variable must be renamed.  Forget or neglect to rename the variable and now you've got misleading information.   A far more robust convention is to require the use of this-> for members and to require full namespace naming for globals.  The compiler can then help you by catching incorrect usage.  In an ideal world C++ would have had these requirements from the outset.   this, a thousand times this (pun absolutely intended). I sometimes wish c++ had gone the same route as python or rust with an explicit self/this parameter. which could also enable things like templates based on the reference qualifiers of the object.     shortly after the wheel we invented find/replace and yet things still get missed.  
  4. Actually there is. Be consistent, at least in your own codebase. If I know something is called a foo bar I should be able to deduce its name without having to check on which day it was written. FooBar, CFooBar, TFooBar, foo_bar, ... are all somehow acceptable provided they follow a clear pattern. I still wished C or T prefixes would remain in the dustbin of history though.     That doesn't happen.    The point I'm making is that readability (for the next guy) is far more important than a bunch of strict coding styles that are largely subjective and change over time.    I'm talking from years of experience developing large enterprise level systems that evolve.  Code bases developed by multiple developers often contain mixed styles. That's the reality regardless of how idealistic you are.    As programmers we deal with what IS and not with what should be.  The fact is most successful business systems contain mixed conventions and poorly written code anyway .  So unless you are the sole developer for the entire life of an application, there's no sense in being strict in regards to programming style.  For success, focus on the architecture of your product, which is the true measure of success,  and don't be guilty of using meaningless notations.    Now, I'm not trying to write a book here or publish a thesis to become famous, I'm just telling you the way it really is.   With that said, I'm frequently reminded of all those jokers in my class that couldn't code very well.   I found out the hard way that they are busy writing endless lines of bad code for us all.  :)  So in the grand scheme of things, stylistic conventions are the least of our concerns as programmers. 
  5. This reminds me that many years ago it was also common to use the prefix letter 'T' for the class definition...    I wonder what happened to that.     And the prefix 'C'?  don't remind me the horror that is MFC.       With that said, after working on a several large business system across many different languages I hate prefix / Hungarian notation with a passion.      I find that coding conventions (especially prefixes) are rarely enforced, change over time, and are usually only grudgingly accepted (if at all) by subsequent developers who inherit your work.   In the end, everyone tries to adopt their own conventions and the code base becomes a complete mess.       IMO, just make your code readable.  There are no strict standards for success.   In fact, sometimes the variable name 'i' is more readable than a long description and sometimes it isn't.  If you write your code for other people to read then you'll be successful.   If you code for yourself and include your own bullshit or the latest fad conventions you won't.  
  6. thanks for the advice.   I've actually just moved over to the Intel XDK which uses Cordova.   The app preview functionality is really great.    I can test on any device simply by installing the app.  
  7. Hi,   I've created a game using HTML5 / javascript, box2dweb and createjs.    My plan is to publish the game to the playstore and the appstore by using PhoneGap/Cordova.       If you have any experience publishing and supporting a game using any of the above technologies could you could share your experiences?   Is there anything I should lookout for?      Thanks
  8. Hi,   Can anyone here recommend a place where I can find a 2d game artist to help complete a mobile game I've developed?   I'm not necessarily looking to hire someone, but I am looking to find someone to team up with.   At this point, the game is completely functional and just needs a graphic artist to replace all my horrible programmer art.  :)     Thanks.      
  9. Having a vision for your game and a small amount of planning is definitely beneficial. You don't want to dive into a game project that is too large in scope and you want to have a rough idea of what you final game will be like but this waterfall approach has a major flaw. You cannot anticipate everything you game needs or even if it will be fun in the planning stages. If you lay out a detailed map of what your final game will be like you will find major problems with the gameplay partway through development. At this point you can scrap all the work you did in planning or just stick to the script and have your gameplay suffer because of it. Alberth describes pretty well what I try to do. Build the game in small incremental steps. Try out the gameplay early with simple prototypes. Be willing to kill an idea that will either take more resources than it is worth or just isn't fun. Identify problems with gameplay and come up with solutions as you find them. Eventually you begin to converge on your final game, which may be quite different from your original idea.     I think that if the above waterfall method is used per feature it won't have such a flaw.   I agree you can't anticipate everything.  
  10.   Those are some very critical and important steps that are often overlooked. 
  11. If you had to create a workflow to manage your development process what steps/stages would you implement?  Would you keep it small or make it as detailed as possible?   It seems to me that I need a process that starts with a user wish list and ends with a build in production.         Here are buckets I'm planing on using per feature    1. Register  2. Initial Requirements 3. Review ( Approve / Reject) 4. Detailed Requirements. 5. Approved for Development (enters the development backlog)  6. Development 7. Unit Testing 8. User / Play Testing (reject / approve) 9. Build & Release                  
  12. As anyone seen an example of rolling dice that uses 3d canvas and real physics?.      I'm looking to create a die rolling app that uses polyhedral dice.      I guess I could find a 3d physics example that uses simple objects, but I'm sure it has been done before.     I think the trick is how to determine which face value is up.   
  13. I loved battlefront 1&2 even though it had stupid AI bots.   Killing them in multi-player was part of the fun in that game.     The more stuff to blowup and destroy the better. 
  14. Sadly, may RPG's only let you create character(s) once.  It's odd that a large amount of development effort goes into the character creation process and yet it's only ever used once at the start of the game.         I guess you could handle character death like XCOM does.   
  15. Didn't Phantasy star 3 or 4 have generations of characters?    That idea is not new   Edit:  Yes, it was Phantasy Star 3: Generations of Doom    http://en.wikipedia.org/wiki/Phantasy_Star_III:_Generations_of_Doom