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

gg405

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

102 Neutral

About gg405

  • Rank
    Newbie
  1. As this is a religious debate in many cases, I would direct the OP to do his own research. Here are some links to get started: "Advantages of Using DLL's" - straight from the Horse's mouth: [url="http://msdn.microsoft.com/en-us/library/dtba4t8b.aspx"]http://msdn.microsoft.com/en-us/library/dtba4t8b.aspx[/url] Read this page carefully and consider how many of the "advantages" actually are true in practice, or apply to you at all. These may be not very in-depth, but if you read the comments they all make the same basic point. The only time it is beneficial to break code into deployment packages if you really intend to share that code among applications. [url="http://stackoverflow.com/questions/2881296/one-big-executable-or-many-small-dlls"]http://stackoverflow.com/questions/2881296/one-big-executable-or-many-small-dlls[/url] [url="http://stackoverflow.com/questions/1592644/which-is-better-one-dll-for-all-or-many-dlls"]http://stackoverflow.com/questions/1592644/which-is-better-one-dll-for-all-or-many-dlls[/url] [url="http://forums.asp.net/t/461506.aspx/1"]http://forums.asp.net/t/461506.aspx/1[/url] [url="http://www.codeproject.com/Questions/259523/Multiple-DLLs-Vs-Single-DLL"]http://www.codeproject.com/Questions/259523/Multiple-DLLs-Vs-Single-DLL[/url] I got these by googleing "one dll vs many" or similar strings. I did not cherry pick, but you'll see in most cases the answer is the same. One DLL unless you have a good reason. In the end, this decision, like all programming, comes down to trade-offs. Know what it is you're trying to do, evaluate the benefits and costs in light of your goals, and then make an educated guess. Don't spend too long on it, because it's holding up your development efforts. ;)
  2. It seems we could get into a very heated religious debate on this topic, and I don't really see the point in simply rehashing all the written material already on the web, but I'll try to focus my response: [quote] Simply using a DLL instead of a static lib won't cause problems. [/quote] Simply using a static lib instead of a DLL won't prevent bad programming practice, which seemed to be what the first 2 posters implied. Your response, on the other hand, seems to revolve mainly around improving link times. This statement: [quote] [left]If the devs of chrome had all of their code in a single dll, a single change would take hours to re-link![/left] [left][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][/quote][/size][/font][/color][/left] Seems to me to be just blatantly false. The application I work on is significantly larger than Chrome (total size of our DLLs is 746 megs (debug), so guesstimate half for release. total size of "chrome.dll" is 28 megs). I can build my entire project from scratch, including compile and link time, in about 20 minutes. Why would you think it would take "hours" to re-link such a small DLL? EDIT: [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left]Also, visual studio does incremental linking to speed up the process by default in debug builds anyway, so you're probably not re-linking the whole thing... [/left][/size][/font][/color]
  3. Also, sorry to spam, but if you're thinking about using DLLs anyway, and you need to pass stuff across DLLs or across processes, you can start here: [url="http://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.80).aspx"]http://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.80).aspx[/url] I had a case where I needed a static variable inside a class in a DLL (it was used to prevent dialog re-entrancy). Unfortunately, this DLL was being used by two different apps (a desktop app and also a browser plugin), so they were two totally separate memory spaces, so two different static variables. The only way to fix this was to use solutions from the above. Really kludgy. Hate it. But again, this was because I had *multiple processes* that needed to run the same code at the same time, so it actually was the right solution (short of using some kind of OS-based semaphore). Most games (or apps in general) don't operate like this, and aren't well served by the additional complexity.
  4. The biggest purpose for DLLs (or "shared libraries") is when you plan to share your library (go figure) among multiple applications/processes, not multiple developers. Don't confuse something designed to improve programmer efficiency (the use of OOD, well-defined interfaces, code reviews, etc.), with something that was originally designed to address distribution and support of multple programs that want to use the same shared code (VC runtimes are a great example). What is being discussed here is really two different beasties. First Important Point: Whether you have 1 mammoth DLL or 270 tiny DLLs (like the app I am Lead Dev for does) has nothing to do with the fact that the right way to program large apps is to come up with solid, generic interfaces and code to them. This makes your code more modular, more reusable, and allows you to put more people on the project without breaking each other on a daily basis. This is one of the fundamentals of OOP, and has nothing to do with how you link your stuff. You isolate programmers by having them change encapsulated implementation details. No one cares if the code they are writing ends up in a static library, a dynamic library that gets linked into a DLL, or how many DLLs there are. What they WILL care about is that you had a call yesterday that took 3 parameters, and today it takes 4, and they have to change their code in 150 places. DLL's don't touch this issue at all, for good or bad. The way to enforce proper programming approaches is through solid interface design, and code reviews to make sure people are sticking to it. Second Important Point: There are many, many, many problems with DLLs, and many complicated systems have been invented to try and resolve them (start your learning journey with the search phrases "Windows COM", and "DLL hell"), and the problems just keep getting more and more complex as the solutions do. Deciding whether you want a bunch of DLLs is really an easy ask: would you rather manage 4 files to distribute, or 400? DLL's serve a purpose, but most of those purposes remain down lower than you need to worry about. VC runtimes make great DLL's. OS code makes great DLL's. Things that a LOT of apps need access to, and need frequent updates - THESE make great DLLs. Now, let's say you're building a game engine. Unless you plan to a) use that engine in several games; and b) want to be able to update the engine with application X and allow application Y to benefit from the improvements - then you don't need a DLL. In fact, it can cause a lot of problems if you TRY to share a DLL between two different apps like this, when they end up being incompatible (see "DLL hell", referenced above). In general, what really happens is you have version 1 of an engine that you ship with App X. Then when you make App Y, you improve the engine, and ship Engine version 2 with App Y, and so on. If you now try to run App X and it loads Engine 2, well, unless you're World-Class good at forward-design (also known as "psychic", "lucky", or "liar") - then you will have not anticipated something. Then you've either got multiple versions of the same interface all doing different things, or some other kludge - but all to the same effect: different engine code for different apps. Current best practice is to create a small bootstrapper exe, and then gob as much stuff as makes sense into a single DLL. For a great example of this, see Google Chrome. They have a few DLLs, but most of their code ships in one (relatively) large chrome.dll. I've come down pretty hard on DLLs, so I'll try to advocate for them at least a little. A great use for DLL's is if you are creating something that you want to sell to someone else, like an SDK. Then, you package your stuff up in a DLL, give them the header files and (hopefully) expanded documentation, and then they can use your code without having access to it, so you can retain the IP.