• 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

855 Good

About NickGravelyn

  • Rank

Personal Information

  1. My little company Brushfire Games released our first title "Shipwreck" today. It's a top down adventure game inspired by classic Zelda titles.   It's available on Windows via the Humble widget and Xbox 360 via Xbox Live Indie Games. You can find the trailer and buy it via the Humble widget on our site: http://brushfiregames.com/shipwreck/. There's also a link below the widget if you want to buy it on Xbox 360.  
  2. I've used the GameTime passed to Draw for visual effects that don't need synchronizing with the main game. For example, I want a sine-wave based pulsing glow around some object. If I wanted to track time for that in the Update method, I'd need another variable somewhere. Or I can just use GameTime.TotalGameTime and be done with it.   You certainly don't want to mix in critical gameplay-impacting rendering this way, but for any visuals that need some long running time variable, it's a free way to have that handed to your drawing code.
  3. Notice in that thread they're using the width in both the x and y calculations whereas you swapped in the height. I believe that could be causing you issues.
  4. I would make two notes here:   1) The default constructor for Random already handles seeding by time; you don't need to do it yourself. 2) Because of #1, you want to reuse the same Random instance as much as possible. For example if you ran this:   for (int i = 0; i < 100; i++) { Random r = new Random(); someVectorList.Add(new Vector2(r.Next(0, ScreenWidth), r.Next(0, ScreenHeight)); }   You would find that quite a few (if not all) vectors would have the exact same values. This is because each new random instance would have the same seed and therefore generate the same sequence of numbers.   So in general you want to create one Random per method at the least, but most people generally just make one Random instance as a public static member on some type and reuse that everywhere.
  5. If you don't mind a more ActionScript/JavaScript style syntax, you could look into Haxe: http://haxe.org/. In my limited toying with it, it seems rather nice. They have NME, HaxePunk, and HaxeFlixel for getting going on 2D games. Not sure what 3D support you could find. Haxe is nice in that it cross compiles into other code (C++ for Windows, JavaScript for the web, etc) so there's no runtimes to worry about. Seems like a good idea for someone looking to use the same code across a lot of platforms.
  6. You can use #if/#endif in C# for using preprocessor directives.   You can also add files as a link, so you keep the file in a common directory and any number of projects can include the file as a link which means they'll all share the same C# file, but it will be compiled into all the projects. As long as the projects don't reference each other you should be fine (if the projects reference each other, you're likely to get an error for having the same type compiled twice).
  7. According to an email sent on 31 January 2013, XNA is no longer actively being developed, and it is not supported under the new "Metro interface" layers of Windows 8 nor on the Windows RT platform.   Right but it was never supported on WinRT (which is the Windows 8 "metro" environment) so it's not as if they are removing support. XNA is still a supported framework for all platforms on which it was ever supported. If its current feature set (including supported platforms) meet your needs, there is no need to avoid using it. Lack of future updates does not automatically render it useless.
  8. XNA isn't dead. Dead implies it doesn't work, isn't available, and isn't supported by Microsoft. None of that is true. The only truth is that there will be no more updates to XNA. If the current feature set of XNA meets your needs, there is no reason to avoid using it to build your game.
  9. I'd toss out that C# can be a good language for studios. Lots of C# used for tools, build systems, etc. You may not be directly engineering the game, but while on a tools/pipeline team you can learn a lot about the studio, the code, and build familiarity/skills over time that will enable you to move into a different engineering role if you want.   I'd also mention that Unity is becoming more prevalent of an engine which uses C# for scripting (technically also UnityScript and Boo). It's obviously not taking over the AAA spectrum yet, but a decent number of companies are starting to use it and I expect that number will continue to rise.   And lastly, in my experience, the really hard core C++ needs are deep engine work. Many studios (especially as you get away from the smaller ones) have dedicated engine teams leaving many of the remaining devs to write higher level concepts. Even if you're still in C++ and not some scripting language (some studios break out Lua or another language for scripting) the requirement of knowing the nitty-gritty C++ stuff starts to loosen as you're writing more game-specific code (so you don't have to have a general solution that works for 100% of scenarios) that can start being less performance critical (such as simple UI backing logic).   Everyone starts somewhere and it usually isn't the role of most knowledgeable C++ engineer in the company. You need to learn enough C++ to be competent and show an aptitude for quickly learning new skills. That's what I'd recommend, anyway.
  10. If you want to go OpenGL use OpenTK. It's a generally solid wrapper, though you'll find it's much lower level than XNA.
  11. Here is some more good reading on the subject of references and pointers in C#. Not necessarily directly related to your question, but good reading on the topics, nonetheless. [url="http://blogs.msdn.com/b/ericlippert/archive/2009/02/17/references-are-not-addresses.aspx"]http://blogs.msdn.com/b/ericlippert/archive/2009/02/17/references-are-not-addresses.aspx[/url] [url="http://blogs.msdn.com/b/ericlippert/archive/2011/03/07/references-and-pointers-part-one.aspx"]http://blogs.msdn.com/b/ericlippert/archive/2011/03/07/references-and-pointers-part-one.aspx[/url] [url="http://blogs.msdn.com/b/ericlippert/archive/2011/03/10/references-and-pointers-part-two.aspx"]http://blogs.msdn.com/b/ericlippert/archive/2011/03/10/references-and-pointers-part-two.aspx[/url] A slight aside, List<T> in C# is more analogous to std::vector in C++. It's not a linked list; it's just an indexable collection of objects. Generally speaking a List<T> in C# is just implemented as a raw T[] under the hood, handling resizing the array as necessary. If you wanted a linked list there is the aptly named [url="http://msdn.microsoft.com/en-us/library/he2s3bh7.aspx"]LinkedList<T>[/url] class.
  12. The first thing that pops to my mind is to not treat the player as a square (or rectangle) but rather as a circle. By interpreting all the player collisions as a circle hitting a corner, if you implement the resolution properly he'll naturally slide around the object. It also creates nice collision resolution between the player and other characters and so on. I haven't played a classic Zelda in a while, but I'm fairly confident that's how the SNES version handles collisions.
  13. You can't programmatically turn of the controller, and with wireless controllers it's actually a pain to turn off when using PC since there is no consistent UI to turn off the controller as there is on Xbox. Generally I just quickly pop the battery out and back in which will shut it down. Elegant? No, but it saves my batteries from dying.
  14. I actually really like both of your separations as I think the two generally could go hand in hand (after all, how is killing ten bunnies going to get me closer to defeating the uber dark lord?). I think there are other things you could use to further differentiate, depending on the nature of the game and how far you want to take it: - Favors increase goodwill with townspeople, leading to lowered prices for goods or increased selling rates. - Quests give more sizable rewards such as new weapons and armor, whereas favors yield smaller amounts of money or items. - Favors could lead to side quests. Perhaps you do a couple favors for a townsperson afterwhich he mentions a friend in a nearby town. Upon visiting his friend, you're given the opportunity to do more favors, quests, or side quests. (In this context the "side quest" would be identical to a standard "quest" other than it doesn't progress the main story arc but would still be large and potential yield good rewards).
  15. Looking good. I've always wanted to see the block world "genre" expand beyond the "create whatever you want" into "here's an actual game". Nice work so far!