• 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

4794 Excellent

About dmatter

  • Rank
    1st place - Week of Awesome IV 2016

Personal Information


  • Twitter
  • Github

Recent Profile Visitors

15567 profile views
  1. Yep I do that too. But there can still be good reasons to use an interface. For example it's good for unit testing purposes as it allows for mocks/fakes/etc. I also regularly export interfaces as part of the public facing API while the concrete class is held back. (Disclaimer: Mainly I'm doing this in Java. C++ does have alternative ways of achieving that without using interfaces like the Pimpl idiom).
  2. I don't use the "I" prefix on interfaces. But if I can't come up with a better implementation name (e.g. because "there is only one" implementation) then I will use an "Impl" postfix on the concrete class. I.e. class FooImpl : Foo { }; But wherever possible, no warts on names at all: class GreenFoo : Foo { }; class BlueFoo : Foo { };
  3. What does that achieve? (Those pointers point to the same address) As long as your MsgProc member function is virtual then it will dispatch to the correct implementation.
  4. The original objectmentor PDFs about SOLID are now hosted here: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Definitely read them. Understanding SOLID is the beginning of a journey away from just being able to write code in C++ and towards being able to architect software and software components. Then to do so on a larger scale without even getting hung up on the specifics of any particular language. SOLID is often touted as modern pillars of OO and the PDFs are certainly presented from an OO perspective. In actuality you will find that a number of the lessons there can and should be applied to other programming paradigms too!
  5. I too would really like a markup-based editing mode for crafting posts in offsite text editors like Notepad++. I also find managing quotations to be a lot easier with explicit quote tags. But more importantly I can't craft a post that involves quotes in an external text editor. I expect that writing posts with bad comms (e.g. on the train) is a lot harder/scarier now but I hope that if I click Submit and it fails that it will retain my text in the editor. Edit: Interestingly my quote tags were honoured by the editor. I did not know that!
  6. As long as the name isn't bad then I don't think it will hurt your profits. A memorable and simple name is good IMO and it doesn't have to be particularly representative of the mechanics of the game but it should be somehow evocative of the game. One case study is World of Goo. It's a great name, simple and evocative. But they could have also called it 'Planet Goo' or 'Save The Goo' and I don't think it would have hindered their success at all. However had they named it 'Goo Game' or 'Goo Physics' or 'Ball and Spring Goo Simulator' then they would be facing an uphill struggle to get their game recognised.
  7. Quite right. Certain kinds statements are only valid inside of method definitions. Other kinds of statements can only exist only outside of methods. These rules are defined by the language 'grammar'. Many/most language grammars will define a concept called a 'statement' and a concept called an 'expression' (possibly they will define multiple kinds of each!). Along with rules about when and where these statements and expressions can be used. In fact any language whether it be a natural language such as English or a computer language such as C# is governed by a unique grammar. A grammar basically descibes how words/tokens/symbols may be composed together to form various kinds of statements/expressions/sentences/etc. As well as how those constructs can be further composed together to define the language overall.
  8. That's not wrong but it's also quite vague. The terms "statement" and "expression" are actually technical terms that are strictly defined by the language in question. I think jpetrie's latest post above is a good succinct rule-of-thumb about what these things are.
  9. 'What' qualifies as an expression vs a statement actually varies across different languages. In some languages the distinction is that expressions evaluate to a value while statements do not. In some languages expressions are just a certain type of statement which happen to return values. In some languages everything is an expression because everything has some kind of a value. For what it's worth you can go a long, long way without ever needing to know the difference between statements and expressions. This is not something most programmers need to think about day-to-day. It's more a concern for compiler authors and language designers and not really something programmers are required to know in order to actually 'use' the language. You mentioned C# though so the rest of my answer is more towards the C# way of thinking... An expression is one or more 'operands' strung together with 'operators'. Operands include things like literal values, variables and function calls and operators are things like +, -, /, *, &&, ||, etc. An expression can consequently be evaluated to a value. E.g. 1 + x * y - func(10) Meanwhile a statement is like an "action" or "instruction" to the computer. E.g. "Declare a variable", "Call this function", "compare this value", "loop over an array", etc. Statements include things like declaring a variable, control-flow statements (if/for/do/while/return/continue/break/etc), declarations of types and methods, etc. Statements as a whole are very often constructed out of expressions. Such as when you declare a variable and initialize it with the value of some expression all one one line: int x = 10 + 2;
  10. Right. But I only said Microsoft may own some Intellectual Property there ("IP" is broader than just copyright and includes patents). My earlier post is simply saying that owning copyright over the original work does not grant you complete and total rights over the resulting generated artifact. It's not that simple. The nature and extent of your 'ownership' and freedom of use are still potentially limited or diluted. There's a lot of possible examples, but here are some... The licensing can restrict various uses (e.g. not for commercial use). The storage format may be closed/proprietary (e.g. the DWG AutoCAD format) and consequently could even be subject to further restrictions that you will have agreed to along the way such as disallowing you from reverse-engineering it. The resulting file may be an explicit composite of multiple works. Such as if you statically link 3rd party libs into an executable. The tool may imbue additional IP automatically. e.g. if MSVC always statically links a certain amount of Microsoft-owned boilerplate. Or that various media-editing tools will overlay a trademarked watermark logo until you pay them.
  11. I don't really see why not. For example, the binary is written in the somewhat proprietary PE format and Microsoft potentially own some IP for that. (They may NOT do, in reality, for this specific format. Other formats are owned however). Yep fair enough. Well, that's not really true. Lots of non-trivial optimisations happen at that stage and there could be plenty of potentially patentable aspects to that. Whether Microsoft really own any of that IP is another thing entirely though.
  12. As long as the license you have for it grants you commercial use then yes.
  13. I'm generally inclined to agree with the sentiment here. But I just want to challenge the idea that you 'own' more than just the original work. I'm not sure that's a clear-cut thing... For example you mentioned the binary generated by VS belonging to you. The sourcecode might belong to you and the resulting binary might contain several of your copyrighted assets but the exe file itself also has many proprietary aspects to it that belong to Microsoft and not to you. The generated assembly itself is a weird derivative of both your work (sourcecode) and their work (compiler black magic). I suppose the copyright there is jointly shared? Unless Microsoft are unable to stake a claim in it due to the compiler being an automated process and not a human. Copyright aside I expect Microsoft take the view that you don't have the right to redistribute an executable generated by VS unless you have a valid license for VS. In that sense it's not "all yours" anyway.
  14. The obvious one that springs to my mind is TAR. They are very simply just file archives (no compression) but in the wild they usually will be compressed by gzip and given a tar.gz file extension.
  15. This entirely depends on a case-by-case basis and you absolutely must check the license you have for these softwares. For GraphicsGale they clearly state that any commercial use is fine without license or royalties (because it's freeware). For FL Studio it looks largely fine, so long as you have a valid license and are not adapting from any of the pre-bundled assets. See "Can I make money with songs/tutorials made with FL Studio?" in their FAQ.