• 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

12048 Excellent

About Nypyren

  • Rank

Personal Information

  • Location
    Eugene, OR, USA
  • Interests
  1. [redacted] I missed the part where you're doing axis+angle rotation.
  2. Each dot is a "commit" - they represent changes made to one or more files. A single line between two commits means that the upper commit was created from the lower commit. In other words, the person who created the upper commit had the lower commit checked out when they committed their changes. The lower commit is called the "parent". A commit which has more than one parent is a "merge". These happen because two people can begin their work at the same time on different computers from the same (or different) starting points, make commits separately which don't know about each other, then try to push later. When the second person tries to push, git will tell them that they need to pull first. When they pull, git will merge the other person's work into their branch (and possibly need to resolve conflicts). This 'merge' step creates the multi-parent merge commits. After that, the second person can push. At any time, you or someone else can check out any commit in the history they want, and start making commits at that point. You can then merge those commits into any branch you want, if you feel like it, or leave them separated if you decide not to merge them (perhaps they are an experiment that you want to keep separate, for example). Clarification about 'local' and 'remote' branches: The branch you see on your own computer called "origin/master" is sometimes called a "remote tracking branch", frequently shortened to just "remote branch" and represents where your computer last fetched/pulled that branch from the 'origin'. 'origin' is the default name of whatever host (github, bitbucket, visual studio team services, etc) you cloned from, and where you push/pull to by default. The remote branch on your computer can differ from where the equivalent branch is on github/bitbucket/etc. It only updates when you fetch, pull, or push that branch. When you commit, you only update your local branch.
  3. Hashes, Databases, Sockets, States... These are all *completely unrelated things*. I'm worried that you're misusing terminology. Can you clarify your question by describing what you think those terms mean so that we don't misunderstand what you're trying to ask? Hashes are a lossy conversion of data. You can't get the original data back. So, no, you should not use them to store game states. You can use them to quickly FIND game states, but you should not use a hash for the state itself.
  4. Yeah, 53 languages is a lot. The games I work on only support 16. I'm not sure how many strings-per-language we have, but it's definitely in the thousands. We don't support third party mods, so that's a distinct advantage. As far as finding the longest strings, we have a mode in our UI editor where it will will automatically look up all of the strings for a given widget, measure their size, and display the longest one. Then the UI designer lays the dialog out so everything fits. Then we have another mode where we rapidly cycle through all languages while rendering the dialog, and the UI designer interacts with the dialog while it's cycling through languages to make sure nothing breaks.
  5. For my own UIs, I generally prefer to avoid the "localization can change things size" idea - instead, I find the widest possible localized string and lay the UI out for that size by hand. This guarantees that nothing surprising will happen due to automatic layout. For user-entered data or things like large data sets, I prefer to build in WinForms/WPF-style vertical/horizontal splitters (draggable separators which let the user control the width/height of the two adjacent UI elements themselves). I also prefer the WinForms style of using left/right/top/bottom Anchors to control child size when a parent size changes. This allows for the user to customize the UI for what they want to see, instead of being at the mercy of your automatic layout code and the UI design team. In this approach, *nothing* changes size other than when the user explicitly changes it.
  6. When you say "immediate-mode" I immediately think of Unity's "OnGUI" approach. It's simple for doing a few buttons, but gets massively slower the more you do - this is due to the OnGUI function hierarchy being called multiple times in different 'states' - layout, input handling, rendering, etc. I *much* prefer OOP retained-mode UIs - WinForms, WPF, NGUI and UnityEngine.UI for example. You construct an object hierarchy and separate methods on those objects can handle input, rendering, layout. You can split things up by component like Unity does, keep objects monolithic like WinForms does, use visitor patterns, or however you feel like doing it. As far as your layout concern goes, what I usually see is the layout is only recalculated if something changes - when a control is resized, it propagates the layout change up and down the hierarchy. On frames where the layout is not changing, no layout code is executed at all and rendering simply uses the cached layout rects of each control from the last time layout was recalculated.
  7. C# 6 and .Net 4.6 Good, GOOD.
  8. Seattle and SF have ridiculously high cost of living, high competition, and lots of companies that go bust quickly. You might try Oregon or Texas, if you can find any jobs in those states. (I'm in Oregon.)
  9. Memory bandwidth on modern x86-64 class hardware is usually a few gigabytes/sec. But keep in mind that the more of that bandwidth you use for allocations, the less you can use for actual work. I've seen 'surprising' things that on the surface don't LOOK like they would use a lot of memory bandwidth in C#, such as concatenating strings with the + operator. I ran into one case where someone was creating a 100K string one character at a time and estimated that the combined memory access was in the dozens of gigabytes. The operation was mostly RAM-speed-limited due to this and took about 10 seconds. Changing to a StringBuilder instead limited the operation to less than a meg of memory access and took less than a millisecond.
  10. Improving performance means reducing computations, and memory management is computations. But if you know that you only need 30 steps per second, you have a well-defined budget for computations: You have 33ms worth of time to do whatever you want, and if your memory allocations and GCs still fit within that budget, then you're fine. That said... megabytes per update seems a bit high to me. If you look in unity's profiler, what are the majority of those allocations?
  11. VS2017 has a mode where the solution explorer browses folders before you've opened a solution - Perhaps this is what you're seeing? Make sure you actually open a .sln file.
  12. Programming languages let you organize code by building things out of small, well-defined pieces. Larger pieces of the program are built by combining smaller pieces. The way that these pieces are allowed to be combined are defined by the language's "grammar". For example in the C# code: X = Y + 1; "X" and "Y" are identifiers (which can be used anywhere an expression is allowed). "1" is an integer-literal (which can also be used anywhere an expression is allowed). "Y+1" is an additive-expression (which is a type of expression). "X = Y+1" is an assignment (which is also a type of expression). "X = Y+1;" is an expression-statement (which is a type of statement). A function can contain statements. A class can contain one or more fields, properties, functions. Classes can be put inside namespaces. A program can contain multiple namespaces. You can see the entire set of what pieces are allowed to be combined in its nitty-gritty detail in a formal grammar. Usually this is too hard to read for day-to-day purposes but sometimes you can find something that you didn't know was possible by reading through them: https://msdn.microsoft.com/en-us/library/aa664812(v=vs.71).aspx?f=255&MSPPError=-2147217396
  13. For hard drive encryption, you've got BitLocker and other full-disk-encryption systems. For RAM encryption, there are things like AMD's SME or Intel's SGX.
  14. Do you have edit-and-continue turned on and you're looking at the JMP thunk?
  15. I'm guessing that the C# thread has already called CoInitializeEx itself. I believe this is what the [STAThread] and [MTAThread] attributes do on the default Program.Main function that a new project template has. If your C# entry point doesn't have [STAThread] on it, try adding it.