• 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

9197 Excellent

About Bregma

  • Rank

Personal Information

  1. C#

    Well, I would think that something like combat is not a property of either the player or the enemy, so I would not make it a member function of either. If your programming environment does not allow things like free functions, then perhaps create a combat object that provides a function taking the two objects involved and arbitrates the results. Such an object can also be handy for other state tracking, like driving animations or sound effects.
  2. There is one key not used. I change things remotely so I assume this was set up behind the scenes? I have two sessions and I have logged in from two computers so i am assuming whatever these tokens are, they are being handled by both of my computers : one for my browser and one for Team Explorer. Under recovery tokens there are none. You can check to see what protocol you're using to push to GitHub. I don't know how your GUI tool would handle it, but from the command line "git remote -v" will tell you all you need to know on the topic. You can also examine the text file .git/config in your local working tree and check the "url" line in the "remote" stanza. GitHub supports two protocols for a push operation: HTTPS (which will ask for a password each time) and SSH (which will use the public key you saw at https://github.com/settings/keys. There may be one more possibility if you're not using the SSH key and you're not getting prompted for passwords: somehow an OAuth token has been set up and is in use by Team Explorer. Look at https://github.com/settings/developers and https://github.com/settings/tokens to see if there is anything there. OAuth acts as a sort of persistent login. It's like having a key to your hotel room: you need to authenticate once to the hotel desk clerk by showing your passport and leaving your credit card imprint, they then hand you a key you can use to come and go as you please until your registration expires. WIth OAuth, you're prompted for your password once through your browser, and then every time you return to the web page, you (silently behind the scenes) show your token to prove you had the right credentials at some point. So, you were probably prompted for your password at some point in the past and have been using your OAuth token since then. It will expire at some point and you will have to use your password again. Either way, unless you take extraordinary measures, no one can push to or delete your repositories at GitHub unless you have explicitly granted them permission to do so either by adding them as a team member or adding them as a collaborator. No one can change or delete your local repos unless they have physical access to your machine (which is not specifically a git problem) or you have incorrectly set up a git server running on your machine. Note that it takes a lot of time and effort to set up a git server, it's not something you could accidentally do.
  3. 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.
  4. 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 [][10] also explicitly states the following. Section [] 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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.
  10. (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.
  11. You must be really young.
  12. Anyone remember New Coke?
  13. 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.
  14. 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.
  15. 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).