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

Xai

Members
  • Content count

    2809
  • Joined

  • Last visited

Community Reputation

1838 Excellent

About Xai

  • Rank
    Contributor
  1. languages like c# handle property / data member and type names being the same extremely well (cause they have a simpler parser), while c++ has more trouble with ambiguity partially just because there are so many cases the programmer can't guess which of an identically named concept will be the one selected in all of the various cases that can arise. So for that reason alone, I typically stick with using 2 different naming convention in c++, 1 for types and another 1 for methods and data objects (in my case PascalCase for types, and camelCase for method/data members) .. however all_lower_with_underscores would work just as we for whichever case you prefer, as long as you have 2 total naming conventions to use, all likely c++ cases can be unambiguous enough. As for interfaces, I usually use ITexture, etc. Because it works well with PascalCase ... however in 1 code base I just left it off ... so that my base interfaces just took the core name ... ie: Texture, GameObject, DrawBatch, etc. And in this code base when I had single implementations for the interface I just used warts usually picking either "GeneralXXX"/"StandardXXX" or "SimpleXXX" depending on the case. Also I try to follow the convention that abstract base classes have the word Base at the end "XXXBase" etc. But ONLY abstract classes, not non-abstract base classes. So you can see the 1 thing this makes me do is for certain cases where I could have an interface, and a non-abstract base class (ie in C# terms an IGameObject interface and a GameObject base classes that all game objects would inheirit) ... then I am in trouble. But I honestly considered this a good thing, becuase doing both of those things is almost a sort of design flaw in itself. You should either do you contract as a contract only requirement (GameObject is an interface) or as a requirement that includes some implementation (GameObject is a base class) ... but you really shouldn't do both.
  2. Rutin's answer is how Bethesda handles this with the fallout and skyrim engines ... just loot at: http://www.ign.com/wikis/fallout-3/Item_Codes for an example. Everything's "item id" is just a 32 bit integer, which they write as 8 HEX digits (0-9 or A-F) so that you can recognize they are a game id at a glance.
  3. I was in a little summer school class that "taught" logo after 4th grade ... but I taught myself to program in gwbasic at 11 years only. By simple randomly pulling a command out of a reference manual, looking at the example, and trying to imagine a way to use it. Sometimes i'd have to skip 2-3 commands that didn't make sense to me immediately ... something I would think of something "cool" ... and then i'd do it. In this way I created a D&D character editor, a script that played a piece of sheet music, and a randomized shape coloring screen saver all in 1 summer at 11. But the key to me was - 1, it was exploratory for me, a fun hobby for me - more "coolness" oriented than outside goal driven. And 2, there system didn't put a lot of road blocks in my way. I didn't have to learn to write 200 line "skeleton" programs to be able to see the output of my work. Now I personally use C# (and used to use C++), and I don't like javascript or python much. But ... I think javascript or python are your 2 best choices here. With ruby next, and C# next. And I recommend C# over Java .. because there seem to be more "simple" things for beginners in C# than java (unless you are learning CS more like a student). Console programming with a language like python or ruby ... will be able to feel like basic used to ... fast and immediate responses. There are soooo many good resources for beginning python ... and a few great ones for ruby too. I assume they must also exist for javascript, but I haven't read any myself.
  4. I've been a programmer (professionally) for 19 years ... and I did the "roll a ball" unity tutorial. And I can't do it all from scratch without the video right now ... because right now all I've done in unity is basically that tutorial and about 2 hours other playing around. Not enough to know anything yet. But I can honestly suggest a strategy that will work given some time. Don't just watch videos and follow along, 1 after the other. Also don't just jump into an empty project and aimlessly click things. Instead here's a pattern for learning development things: 1. Find a resource to follow (the roll a ball is one of many good places to start). Follow the video exactly as is, just practicing the art of doing what you are shown ... not learning it. 2. After every few elements in the video or tutorial guide (as small as 15-30 minutes to as large are 2-3 nights of tutorials) .. stop ... and think of how you could use the IDEA or SPECIFIC TECHNIQUE you just say, in a SLIGHTLY DIFFERENT WAY. The key is that it must be similar enough to use what you were shown, and different enough that once in a while you'll totally screw it up and be completely unable to figure out where it went wrong. Don't worry if some ideas are too simple, don't worry if some ideas never work out ... Just try to think of 1-2 "uses" for the thing you watch ... then use it. 3. Move on. This is how I learned GWBASIC in 6th grade ... I read 1 command in the language ... looked at an example usage ... tried to think of a usage for me ... and if I could, I did ... and if I couldn't I skipped it and returned to the command a week or a month later. In this way I learned to build a D&D character editor, played a piece of sheet music, and made a randomized colorful screen saver all in 1 summer at 11 from a book. All because I learned 1-3 commands every 1-7 days. And put them to use, each and every time I could. To expound on this with an example. Maybe you know how to do something simple like shuffle a deck of cards in a computer data structure. Well, how about trying to have a unity scene with a playing card instead of a ball. How about trying to rotate them different ways. How about "dealing" 5 cards into the "ball positions". How about adding a stack/pile to be a deck ... how about animating the dealing to pull them off the deck and move them into position. How about changing the collision logic so that it adds the card to your "hand" and you "win" if you total 21. and loose if you go bust,.,.,. etc etc etc
  5. Here's this: http://rogerdudler.github.io/git-guide/ or simple google "git for beginners" ... And NO you do NOT need to use gitflow or some other pull request, branch heavy strategy to use git with SMALL teams. But if you are going to use ANY source control with other people AT ALL ... then you really need to learn to make small commits (and push them) very often. the default branch in git is called master. that will be the branch that you and everyone else either commits to ... or merges into ... that will show up on the sites (ie githubs) web portal as the "current" version of the code. anytime some new person downloads the code ("git clone" a repository - in git lingo), they will initially be on the current version of the master branch. The absolute minimum workflow on git is basically like this: 1. ONCE - Clone a repository to have a local working copy. "git clone https://PROJECT_URL_HERE" 2. EACH TIME YOU START WORKING - pull the latest code "git pull" 3. MAKE A SET OF CHANGES 4. COMMIT THOSE CHANGES - "git commit" via a graphical tool that selects things for you, or "git add ." followed by "git commit -m "your checkin message here"" (this saves all your change as a commit, that you can see in your history and such) 5. UPLOAD THOSE CHANGES TO THE TEAM "git push" (this sends all your commits to the server - usually the place you cloned from). Repeat step 2 whenever you want to update your local code with the latest version that every has pushed. Repeat steps 2-5 whenever you want to do more work and then share it. DONT EVER FORGET STEP 2 before you start working on a new change set. DONT EVER FORGET STEP 5 when you finish a good set of changes that has any value anyone might ever want (including yourself) don't be afraid to break code, you can always go backward. it is better to commit and push bad code a few times a month, and spend a few minutes or hours making it good code ... then to forget to pull or commit or push good code and spend hours and hours in merge conflict hell!
  6. Look at the first few games all of the most successful studios made. Blizzard, Id, Bethesda, Microprose, etc. Compare everyone's first game, to their 3rd. And their third game to their 5th or 10th. You will see that these "games of old" that everyone remembers. Done on a mobile app, with online support backed by cloud servers ... are all very light and easy on the spectrum of games that are made nowadays. But they were beyond the scope of a small inexperienced team back then. And they are still beyond the scope of a small inexperienced team now. Back then, only the best of the best could slave away and make a game work well. It didn't take long (by today's standards) ... many games back then were written in 3-9 months, some took longer of course. But even then, most games never worked, most never got finished, most companies never made back the money their founders put in. And now people expect art, and quality. High quality graphics (very very time consuming and expensive), high quality sound assets. Original ideas. or GREAT execution of old ideas. And high quality production values. An experienced game developer with the right tools can create in a weekend game-jam something a college team cannot finish in a semester long project. But that game jam winning entry, still makes NO MONEY. It would still not pay the developers even for their food and hotels for the 3 days they spend making it. Small, indie games are labors of love, not money. So unless you want to go broke creating a game that is never as good as the vision in your head, and never gets the reviews it deserves ... you really should just start somewhere, making something very very small. With a very small team, of unpaid people whom share a passion for working on the same things you do. And work to make something happen. If you can't make a formal game design doc, a detailed plan for the team to build it, a detailed marketing plan for advertising and monetizing it, a super great web portal all about it, etc. Then you can't possibly make the game you are talking about. So get your idea smaller, and smaller, and smaller ... until you can make it happen. Not in 3 years, not in a year ... in 3 months or less. Once you prove you can finish ANYTHING worth doing in less than 3 months. Try something bigger. Once you have done anything, you will be able to get help doing another thing. And then another. And after 6 months, a year, maybe 3 years ... if you find you really wanted to keep going this way ... and pursuing this path you will wake up and realize you now know the path forward, and you have the friends and contacts and experience to give it a real shot.
  7. So also, realize that what the game uses while running can be different than what the programmer/level designer/content creator/modder uses while creating. It would be quite normal to have some form of (possibly partial) mapping of strings to IDs for items. So let's start with the assumption that the game itself uses IDs for all of the game objects, including object templates (which is pretty much what an "item type" is. We'll assume these are integers (16, 32,or 64 bit depending on scale and computer arch). Now we can then assume that there can exist a map table of unique tokens or names, which references this ID, which can be used by modders, designers, with a simple call to a method like: int ItemTable.LookupIDByToken(string itemToken); and you can optionally add overloads to 1 or more other methods that accept an item ID, to accept an itemToken and perform the lookup for you. Even more than that, you can create a rule that the token/name of an item cannot start with a numeric character, and therefore any string which contains a number in the first character can be assumed to already be an item token ... so if a modder passes a string to a method expecting a token, that lookup method can simple do a super fact 1 character check, and then parse the string without any lookup at all. And this is the trick that then allows you to use only a partial map table and not require all items have names. Say you have a database with 4000 items, all of them can be easily referenced by ID (if it is known) .. but you could have a much shorter list of perhaps 300 common items, and maybe 50 "special" items that modders / designers could use for the 95% of them time they are just doing something simple putting a chest with a cache of money in a chest, with an options health potion or whatever. Also, this technique of "first letter (or prefix) denotes how to interpret the token" can be built upon in the future. So say you start with the ID that numbers are object, but maybe only tokens starting with "I..." are items, then later you can add simple routing to support passing through "S..." elements which may be skills, or "X.." loot which may be experience. etc.
  8. I really don't see how GameDev.net can allow these posts to continue.  I am personally (as nobody other than a long time forum member) calling for a ban on Rasmyslov's account and anything PVS-Studio related after he has continued to post simple click-bait advertisements for his product disguised as "articles" and with misleading headlines that do nothing to announce their true nature.  Secondly, this post actively violated the terms of service of Cry Engine V (at least as I read it, although perhaps these snippets are fair use). Plan an simple a headline about a commercial product (PVS-Studio) should not be allowed to use the name of another commercial product that they have no rights to.  If you want to allow him to create a PVS-Studio tag or title his article something like "PVS-Studio analysis results of XYZ" I am perfectly fine with him continuing to "educate" us all on the grand wonder that is his product and the horrible pitfalls that exist in all real codebases.  But to allow him to use GameDev to advertise his product in this manner in clear violation of any reasonable concept of propriety, fair use of trademarks, and simple honesty and respect of the reader ... I just cannot stand it any longer. So my proposal is:  Force Rasmyslov to go back and change the title of each and every advertisement he's posted - to be honest and direct, and to use only such titles in the future, or to have all of his articles removed from the site.  If you agree with me, please let me, or gamedev or Ramyslov know.  If you do not agree, then please also make that known (your opinion on the appropriate conduct on gamedev.net should count either way).
  9. I agree with most of the responses above, including those that tried to help you with what you asked, and those that told you don't worry about it too much.   But I want to add this perspective:  * If you enjoy "finding the best way" and this is a hobby ... don't ignore the fact that this may be the part of it that keeps you going.  I actually spend over 50% of my effort on "improving" stuff that is already "good enough" .. because that's what I like and this isn't a job (like the other poster, at work I ship code where "perfection" is not a goal, just "high quality") - but for my hobby I don't achieve perfection, but I pursue it.  * If your tendency to spend most of your time circling and circling in pursuit of your perfection is stopping the other half of your enjoyment (ie making actual working / interesting product).  Then either use the techniques to keep on track mentioned by many posters (like daily lists, etc) or separate yourself into 2 explicit modes:  work mode, polish mode.  This version is where you tell do things like have a list ... and you make yourself spend "x" amount of time moving forward on the list (or something like "i'm gonna knock out item 1 and 4 first") ... then you let yourself work on unnecessary improvements for X amount of time ... then "back to work"   Its a technique I use on my architecture and designs at work.  Cause while at work I can easily get code "good enough" designs themselves are harder to judge ... so I force myself to first get a design advanced forward to a certain point, then I let myself explore alternatives and improvements for a certain amount to time, before forcing myself to pick and move forward again.
  10. Hex is mostly of use when BYTE (8 bit) or NIBBLE (4 bit) boundries matter.  All real programmers i know instantly know that 8 is bit 4, 3 is bits 1 and 2, 128 is bit 8, etc.  What they can't do is tell anything about number like:  986895, 16777215 or 8388736, which happen to be the same as 0F0F0F, FFFFFF and 800080 in hex, which can be instanly an obviously recognized for things such as the RGB values of a middle grey color, full white, and a middle purple color respectively.  Or for things like ASCII or Unicode values, or OPCODES of a computer.
  11. No wrong answers ... i recommend C# for learning to program ...and something like either monogame (open source XNA clone) or an opentk or SDL wrapper type framework for playing around with a bit of graphics, controller input, audio, etc.   Here's a slightly longer thread i responded to:   https://www.gamedev.net/topic/685064-c-or-c-for-2d-and-3d-game-creation/page-2#entry5330244
  12. I'm not 100% sure why this topic is causing me to want to respond and express my opinions so much ... but ... here goes:   Background - I am not currently a game programmer and have not been a game programmer for over 15 years.  Back then I used ASM (3 months), then ANSI C (9 months), then C++ (3 years) to create embedded gambling games (like quad 6 lotto, blackjack, etc) ... my last game project was a Direct X 5 2D 8-line slot machine running on an embedded intel i815 chip around 2000.  I then worked in embedded audio using C++ for 3 years.  And then I sold out / went corporate and started writing database backed, server based C# web applications - which I have done very successfully for about 12 years.  (I've also used perl, ruby, lua, javascript and others).  I have played with Unity, XNA/monogame, SDL, tao and about 5 other pretty much dead libraries through the years.    * There is no right or wrong language (except ones almost noone is using - where you can't find help)  * There is no right or wrong library or platform (except ones that are no longer supported)   HOWEVER, NONE of the current languages, NOR libraries/engines, NOR game types are even REMOTELY like each other when you think about the following:  * Community culture  * Initial experience when not having a mentor  * Availability of online materials and support  * Availability of print material and support  * Most likely directions to take for "successful" experiences  * Number of hours to expect to spend before you know you are making progress or perhaps should change direction  * Ability to get something satisfying done quickly if you want to make PLAYABLE games  * Ability to get something satisfying done relatively quickly if you want to learn to be a "real programmer" (TM)  * Ability to translate the beginner experiences and learning forward into real jobs  * Ability to use the early experiences to contribute meaningfully to indie or beginner unpaid projects  * Ability to translate your experience forward onto other languages or platforms  * Ability to translate your experience forward onto a long term career as a professional software developer (not necessarily making games)   And by way of specifics:  * C# and Javascript are WAY WAY easier languages for starting programming in than C++ (although both are far more complex now than they were 5-10 years ago)  * C# and Javascript are the 2 languages most likely to get a junior programmer hired as a professional programmer, followed by Java and Objective-C (in nearly any industry except games)  * C++ is far and away the most dominant language used by the software and engine developers for AAA titles, C# with Unity is working to close the gap  * Mobile games are primarily built in either native Objective-C (ios) or Java (android) or on javascript based cross-platform engines.  * C# and Java are the 2 most dominant languages for colleges teaching computer science, and are very similar.  Both were very simple 10 years ago, but both have become quite complex over the years.  Javascript is the 3rd most common CS degree language.  * C and C++ are 2 of the only remaining languages that are still in heavy use that normally require manual memory management (although smart pointers do exist) and teach good low-level programming fundamentals if you want to do things like write device drivers, graphics or physics engines, operating systems, IoT devices, etc.  * Almost no-one outside of games or embedded systems pays anyone to program in C or C++ below the Senior Developer level of experience (in other words, its hard to get started in these career paths, but you can make great money once you are a proven expert).  * Anything you are doing that you are having fun doing, while also learning something, is always the "right" way to do it ... and what is "fun" is impossible for someone to predict for you.    * I recommend C# if you want to program (in general) - or if you want to make games quickly and not take years building "engines".  I recommend C++ if you have more fun with the idea of programming than in the completion of actual programs and would like to tinker with core things until you understand them deeply.  * I recommend things like XNA/monogame, SDL, or other simple frameworks if you want to mess with simple 2D sprites.  * I recommend Unity if you want to work with 3D stuff in the next 2-3 years (cause 3D game engines are CRAZY HARD and C# with Unity is just about the easiest to get started with).   Good Luck  
  13. Unfortunately, I haven't done real professional C++ development for many years, working with C# mostly now.  For C#, I can say that Visual Studio 2015 is great (a memory hog and slightly slow to load - but doesn't bog down randomly like both C# and C++ used to in Visual Studio 2008).  C# is of course enormously simpler than C++ for a compiler ... so that makes the Intellisense way less of a bear.   Also my mac coworkers use Visual Studio Code fairly well.   I was planning to play around with CLion (I have a copy as part of their ultimate tools bundle) but haven't had a chance yet.   And last up on the honorable mention list ... have you looked at C++ Builder? (https://www.embarcadero.com/app-development-tools-store/cbuilder)   I haven't used it since about 2004 ... but back in the Visual C++ 6 days, Borland C++ 4.52, 5.01, 6 and then C++ Builder 4 and 5 just beat the pants off Visual C++.  I had to use both for work and I ended up just never using VS except to compile final output from the command line.  Borland was faster, more language compliant (back then ... not now) ... and had a way way better debugger for multi-threading ...   However I suspect that the sticking point with pretty much all non-visual studio IDEs is going to be lack of or at least poorly done debugging support for MSVC compiled output.   Let me know if you find a better option.  Also, I do recommend using Visual Studio 2015 over 2013.  2008 is a strait improvement on 2005 ... and 2015 is a strait improvement over 2013 which replaced the horribly bad 2012 ... 2010 is ok too.  So the Only Visual Studios I would EVER install again are VS 2008 (for XNA game studio), VS 2010 and VS 2015 (for all my real work).   EDIT -  Also wanted to mention Visual Assist plugin (http://www.wholetomato.com/) and that some people realy like Net Beans for C++
  14. I wanted to let you know that multiple of early product advertisement / analysis articles didn't feel right.  Not terrible useful, not terribly direct in being an add for the product from an outside who had no involvement with the code, and a bit preechy with too many "kinda not ideal code" cases being called errors.   This article was different.  It was full of useful examples, a useful dialog explaining them ... and should be useful if either the actual coding team who wrote the code read it, or any other C++ programmer looking for common coding mistakes.   This article seems quite useful on its own, even without the product you sell (which also seems useful, but that's another topic).  Good job sir!
  15. Also, don't forget to that you can download REAL working game code that has been open sourced.  Almost all of it is "bad" as in, you won't want to copy it ... but just skimming the layout and main files can help you think of things you may not have considered ...   There an Open Source RTS Engine (Spring), John Carmack open sourced Quake and I think some newer ones too.  If you look at what games are available as FPS packages on most linux's you'll find 3 or 4 Quake 3 / Unreal Tournament clones.  All of which are open source I think (just google "linux first person shooters" to find a quick list).   Good luck.