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

Bregma

Members
  • Content count

    2928
  • Joined

  • Last visited

  • Days Won

    1

Bregma last won the day on July 23

Bregma had the most liked content!

Community Reputation

9195 Excellent

About Bregma

  • Rank
    Contributor

Personal Information

  1. If you go to https://github.com/settings/keys you might see that you've created an SSH key. You would need that key to make changes to your GitHub repos remotely. It's possible it was all set up behind the scenes for you by Team Explorer. If you go to https://github.com/settings/security you might see that you have a current OAuth token. That means you've obtained an OAuth token (ie. logged in) at some point from your current machine and it's being stored somewhere for use by things that use OAuth tokens, like maybe Team Explorer and certainly your browser.
  2. Most definitely. In fact all of Annex C of the ISO/IEC 9899 C language standard deals with clarifying exactly where the sequence points in evaluating expressions are. Section [6.5.2.2][10] also explicitly states the following. Section [5.1.2.3] clearly specifies that the value of objects between sequence points may not be relied on. Paragraph 2 of that section defines what a sequence point is, and the rest of the section goes to great lengths in standardese to describe what a sequence point is not. Section [1.2] of the ISO C++ standard explicitly includes the C language standard as a normative reference (that is to say, it extends the C language standard). In other words, any program that relies on the order of evaluation of arguments to a function is malformed, because anything between the start of the function call and the actual execution of the function itself lacks a sequence point and the compiler could emit code to evaluate the arguments in any order, at any time, for any number of reasons. It doesn't matter what calling conventions you're using, because that affects only the way data are passed and received -- which only happens after arguments are evaluated and their side effects complete. You can not rely on the order in which arguments are evaluated in C or C++. Ever. Ever ever.
  3. Systems Hungarian notation is one of the worst cargo cults to have ever been perpetrated in programming. You should consider not bending the knee to that golden beast and so avoid prefixing the names of interface classes with the letter I. You should be programming in terms of interfaces anyway, so name your interfaces as the base concept (eg. "class MyClass" is the interface). After that, qualify your concrete classes that implement the interface (eg. "class MyConcreteClass" and "class MyMockClass" might be concrete classes implementing the interface... I try to stick to English grammatical constructs even though it doesn't group nicely when sorted lexicographically, because I can always use glob sorting if I need to). Code is literature, make it humanly and humanely readable.
  4. The compiler is just trying to save you from writing buggy code. You need to go out of your way to force your bugs into your software. Your solution does a fine job of doing that. You're implementing an operator that is not closed on the enumeration set. You're breaking the contract provided by enum. When you start getting weird errors, save yourself some debugging time and check where you use the enum first.
  5. GNU/Linux supports OpenGL ES 2 out of the box. Desktop, phone, tablet, toaster, it doesn't matter. The Mesa drivers implement a common codepath for most of OpenGL and OpenGL ES, and uses hardware acceleration where available for Intel and AMD hardware (either through the Gallium libraries or the open-source AMD libraries). The nVidia binary blob drivers do the same thing as the Mesa drivers, but through binary blobs so you'd need inside information to know that. The Mali drivers are for ARM hardware. You can, of course, run GNU/Linux on ARM hardware, and you can run Android/Linux on ARM hardware. This may be why it's confusing, and trying to install the ARM Mali drivers on an x86 GNU/Linux desktop system is just going to give you grief.
  6. The emulator libraries are conflicting with the video drivers for your host operating system. You could remove the video drivers for your host operating system (like by using --force-all) if you want, but the productivity resulting from staring at a black screen is relatively low. I'm not sure how this emulator is supposed to work, but my guess is you're supposed to be installing the driver package in an ARM image that gets run using QEMU or something. That means you'd either be building in the ARM virtual machine itself (in which case there should be no conflict, because it's a separate OS install) or else cross-building on the host in which case the packages should not conflict because they'd have different installation paths. So either the packaging for the libraries you're trying to install is completely broken for your purpose, or you're trying to set up and install incorrectly. Do you know if the Android Studio you're using on Linux does cross-compiling on the host or does it use a full system VM?
  7. Well, here's a common setup. (1) You have an off-site DVCS host (for example GitHub) to which you push you code from time to time. This gives you an off-site code backup, make the code available to team members if you're cooperating with others, and gives you a public portfolio if you're looking for paid work. This is also known as 'keeping a copy in the cloud'. (2) A commit hook on your source server causes a build to get kicked off on a build server somewhere (for example, Travis-CI). The build server checks out a pristine copy of your source and builds it in a clean environment. This ensures that your code builds from source in a clean environment, which is important if you lose your personal dev environment (which you will, at some point) and is also important if you;re working with a team or shipping software The end result should be an installable package with your software that you or your testers can install and verify.. This is also known as 'building in the cloud'. This is a process known as "continuous integration" and is a good habit to help maintain proper development hygiene. You get off-site backups, you get proof your code compiles, you get simplified distribution of you software, and you can actually get it all for free if you don't mind your work being open. You also offload a lot of processing because you can just do incremental builds locally for development testing. Of course, you need to follow good habits for it to work, and if you want to keep everything obscured for an illusion of security you'll need to either pay for the cloud services or set it up yourself either on your own local servers or on rented metal somewhere.
  8. (1) By 2060 I expect direct neural input and output for full sensation and total control. (2) The obvious corollary to (1) above: merging of the gaming and porn industries. This will be the downfall of civilization and the inevitable conclusion to humankind's dominance on planet Earth. So long, it's been nice to know ya, excuse me while I go plug in. This was actually addressed in a 1983 Hollywood movie.
  9. You must be really young.
  10. Anyone remember New Coke?
  11. Blender, UE, and photoshop? Any mainstream CPU and GPU will do. Focus on the best pair of monitors and the best keyboard you can afford. The rest of the hardware is going to spend 99.9999% of its time waiting as you stare at the screen, so make sure your screens are top quality. A good keyboard with a feel you like is next in importance, because that's your primary tactile interaction with the computer and you're going to associate that sensation with doing development. Seriously, today's average compute power is more than enough (and if you're smart you'll offload most processing to a cloud anyway). Focus on the HMI side because your challenge in game development is not going to be waiting for a build, it's going to be finding motivation to finish the game. Everything you can do to help the latter, even at the expense of the former, is a win.
  12. You seriously need to get her a CARDIAC. You can even emulate one on a modern computer but there is nothing like holding the real thing in your hands. I got one when I was 10 (back when the USA was still capable of putting men on the moon with a similarly powerful electronic computer). It made me switch career ambitions from becoming a paleontologist to becoming a computer scientist. It ended up in my hands via a one of my science teacher mother's students who also went on to earn her PhD in computer science and become an inspiration for me. Oh, sure, you have to program it in assembly. Turns out when you see how assembly works in a simple and hands-on way, grasping higher-level constructs is not a big leap and picking up things like C++ is just a matter of learning some new syntax.
  13. In bed between 22:00 and 23:00 and up at 05:55, except weekends and holidays. Sometimes you need to down a half-dozen craft beers while binging on certain games in a kind of soma holiday, but you will pay for it. I used to stay up and get up late. Once I got up at 16:30 (which was mighty wretched). After years of experimentation, it turns out out I need between 6.5 and 7.5 hours of sleep, plenty of exercise (I run a couple miles with the dog most days) and good nutrition to be on top of my game. Studies have shown most people do best with regular sleep hours, and somewhere between 6 and 8 hours of sleep per day. Try it for a week: choose your hours (start with 7.5, hours duration and choose convenient stop and start times)) and go to bed and get up at exactly the same time every day for that week. It takes at least a week for your circadian rhythms to harmonize fully with your sleep/wake cycle (trust me, I've done a lot of cross-timezone travel).
  14. "git" is a distributed version control system, a suite of software used to store and control revisions to source code. It was originally a tool developed by Linus Torvalds to help him work with his Linux operating system kernel. "GitHub" is a commercial web service that provides free hosting for remote git repositories and provides associated integrations with other web services that can be used in software development (eg. wikis, bug and work tracking, continuous integration and deployment). Yes, merges between git branches (also known as pull requests, merge requests, or merge proposals) can become complicated when there are "merge conflicts." It often requires someone to manually reconcile the conflicts. Fortunately in practice it doesn't happen often, as can be witnessed in the Linux kernel development tree which has literally thousands of contributors. OI git, every change is not a branch but a "commit", which is a collection of one or more files as changed tagged by a hash of the changes. A branch is a particular labeled commit that can be moved as more commits get pushed to it (think of it as a label pointing to whichever commit is on the top of a stack). One branch is traditionally labeled "master" but that's just a tradition, not a requirement. You don't have to learn a the command line to use git, there are graphical shells you can use instead. You may find as you gain more experience that you also gain more power using the command line, but I understand it may not be for everyone. As to using git with Microsoft VIsual Studio, and your other questions, I can't help but I'm sure others here can.
  15. I can answer that. Some people find the contemporary technology, and associated tactics and strategies, to be interesting and they derive a certain enjoyment from simulating it. They can do that without the wholesale embrace of the political ideologies of the day, including that of maintaining 'racial' purity. Turns out it's only at the level of political ideology that the colour of the skin of the person pulling a trigger or driving a tank makes any difference, and it's irrelevant at the strategic, tactical, or technical level. So, if you're playing the game to gain enjoyment from the strategy, tactics, or technology, you'll be fine with the design choices the developers made. If you're ideologically motivated or on the spectrum and filled with anxiety about the inexacting background detail in the historical simulation, then the game is not for you. There is also a sub-genre of trainspotters who gain their pleasure from finding and sharing the inaccuracies in mass-market entertainments. The designers and producers had to make choices. Additional detail means higher cost. Additional restrictions on participation means fewer paying consumers. Games are not a charity focused exclusively on your own pleasure, they're a business and like most entertainments businesses, factual accuracy takes a back seat to increased revenue every time. Really, the lack of Historical Purity you're railing against is not the result of the 'diversity' you disdain, it's the result of lower development costs and broader market acceptance resulting in ongoing business investment -- free market economics, if you will.