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

Shakedown

Members
  • Content count

    558
  • Joined

  • Last visited

Community Reputation

230 Neutral

About Shakedown

  • Rank
    Advanced Member
  1. Fortunately, you don't need to know any of the things you've mentioned to make a text-based game. Don't think about graphics yet - making your game graphical will add lots of complexity and require that you learn another API. You can make plenty of cool games that are text based, and doing so is a natural step in the progression to bigger and better (and graphical) games. As far as timing, you're right - it is a simple concept to grasp, but it's not necessary yet. Multithreading most likely won't be needed for the games that you will be making, so again, don't worry about it. These are all good concerns, but for basic games they're typically not needed. You should definitely start with text games as you'll still have a lot of work to do, for example how you're going to architect your system, how you're going to represent your game entities (i.e. class hierarchies), etc.
  2. If you're a student (and can prove it), Microsoft has the Dreamspark program that allows students access to professional-grade software for free, so you could get a Visual Studio Professional edition.
  3. When it says "implementation should be hidden from the users," that simply means that the process of object construction is encapsulated within a function call (i.e., WndFactory::CreateWindow). Obviously this hides the implementation from the users because they don't see (nor do they need to) the construction of an IWindow object. So there really isn't anything that you need to explicitly do to hide the implementation, rather that is what applying the pattern will do for you.
  4. I've got the book from my university library, but of course there's no CD. I've scoured the web for the CD content/source code and found a few links that point to the author's website, ronpenton.net. Unfortunately, the site no longer exists. And in case you're wondering, the author states in his book that you're free to do as you please with the source code. So, does anybody have the source code/CD content available? Thanks!
  5. If you're getting redefinition errors then it's obviously already defined for you, so why do you need to forward declare it?
  6. No Gmail? Then you could use the oh-so-great Gmail chat!
  7. Quote: I've taken a look at the book MUD Game Programming but it didn't seem too good... I disagree - I think Penton's book is a great starting point for your own MUD. I'm sure others will disagree with me, but why are you avoiding it?
  8. Quote:Original post by Fruny As it's been said before in the thread, yes, that's the way to do it. Watch out for object scopes when using references. Ah, I meant was it still possible to do row-major ordering when using an inner class for the row. I assume so... Maybe I should stop asking questions and start implementing it!
  9. Quote:Original post by gekko If you want to implement [], I recommend storing your matrices in row-major order... If I'm going to use an inner class to represent a Row, does this approach still work? In that case, I'd overload the [] operator in 2 classes: - My2DArray class, and - My2DArray::Row class
  10. Quote:Original post by Captain_Thunder Quote:Original post by Shakedown I understand the performance costs, but I've got to make my class work with existing code. Since no one seems to be addressing this - what exactly is your existing code doing that forces you to use [][] instead of ()? Haha, the existing code is doing this: their2dArray[][] And I need: my2dArray[][]
  11. Quote:Original post by Sneftel I think you missed the third clicky. No, I read that as well - hence my 'idea' for the inner class. I guess my question is: Is that the best way to do it?
  12. Yes I just read over that article before making my post! I understand what it said, but it didn't tell me how to implement [][] functionality, only not to do it. I understand the performance costs, but I've got to make my class work with existing code.
  13. I need to implement my2DArray[][] functionality in my class. I've found several articles online suggesting to use the () operator instead, but I want to figure this out using [][]. Since there is no [][] operator, there must be some 'trickery' or indirection happening behind the scenes to provide this indexing functionality. Here's what I've thought of so far: - Create an inner class representing a row in my 2d array class - Overload the [] operator to return an instance of this inner class - Overload the inner class' [] operator to return the correct element I don't see any obvious problems with this approach, although I'm not sure what I'd do if the user wanted access to an entire row (i.e. my2DArray[]) since I'd probably want to hide this inner class from the user. So, are there any other ways of achieving this functionality? Are there any problems or difficulties with my approach? Thanks
  14. Get a degree in Computer Science.
  15. What needs explaining?