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

Bearhugger

Members
  • Content count

    315
  • Joined

  • Last visited

Community Reputation

1276 Excellent

About Bearhugger

  • Rank
    Member
  1.   Those electrons feel more appreciated if you buy them gold to travel in, and they will return the favor with better sound. Right? At least that's how the underpaid Best Buy clerk with a commission on the stuff he help sell explained it to me.
  2. I'm most happy with the current situation personally.   On one hand the appeal court's judgement acknowledges the creative work required to create a good API. I mean, I don't have any respect for the Java Foundation Class' APIs I think they're a mess and I hate every second I spend coding in Java, but when I think of some really well made libraries such as (IMHO) LINQ or the Roslyn API in .NET, all the new modern async Javascript libraries out there, or the thread/promise/future libraries in modern C++, I see a lot of cleverness and creativity in their design and I'm glad that the copyright acknowledges the work that goes into creating them.   At the same time, compatibility between APIs is a sine qua non condition to make software work, to promote competitivity between software providers, for free open source alternatives to work, etc. They have also been used forever, as each piece of software is built on top of another. The fact that using or copying them is fair use is common sense and I can't think of what would have happened to our industry if Oracle had it's way.   So basically if I understand right, it looks like APIs have a copyright but using or implementing them is fair use, making their copyright look kind of symbolic. If my understanding is correct, this is *exactly* how I hoped it'd be.   Also, I really have to raise my hat to the members of the jury for making sense out of very technical computer science concepts such as APIs and object-oriented programming and taking the right decision. I doubt a lot of them were technical people, if any.   Too bad Oracle intends to go in appeal again. Hopefully the appeal court will serve them a legalese translation of "Go f... yourself!" because I'd really like the current state of affairs to stay the way it is.
  3. People forget that before UWP, there was the Metro/Modern application platform for Windows 8 and now it's dead. What's telling us that Microsoft is not going to come out with some new API next year and kill off UWP? I mean, it's not like the platform has been without criticism; some big name game developers are already calling for the death of the platform, and tying the platform to the Windows Store when nobody actually uses the Windows Store or knows it exists doesn't exactly capture my heart as a developer. (Not even Apple can do that on the Mac.) As much as I dread using Qt, GTK, wxWidgets or MFC, I would pinch my nose and use those for now, and then cross my fingers that Microsoft gets things right for the UWP sooner than later. I would love to use the UWP for my project but as it is right now it's a no-go.   On a side note, I don't get why people dislike the CX language extensions so much. The objects of the UWP class library are glorified COM objects, and the CX extensions simplifies their manipulation as well as the creation of new ones, so why not make it easy on you and use those when you deal with Microsoft APIs? It still feels very much like C++ and is so much easier and convenient than the nameless mess that you have to deal with on competing platforms to get C++ to play well with the OSs. (Namely, JNI on Android and Objective-C on Apple.)
  4. Behemoth software is not monolithic in terms of programming languages. They can use more than one programming language. And heck, the .NET framework is *designed* to help making programs cross-languages manageable. Sometimes C# is better than C++, some other times it's the opposite. When you have millions invested in a project you use the right tool at the right place. I know that's kind of a boring answer in a debate, but really, that's what it is. :P   I mean, usually, yeah the core of a big program will be written in C or C++ if performance or portability matters. But what about other modules?   For automation (big software have some kind of macros support) they will embed a scripting language interpreter (usually Lua, Python, Ruby or Perl interpreter but sometimes they roll their own) and then write some of their own code in that scripting language when it makes more sense. For example, I'm pretty sure that Blizzard writes World of Warcraft's UI as preinstalled mod packs since there is a ton of Blizzard-authored stuff in WoW's addon folder.   Is your app just a thin client around a web service? A lot of mobile apps are. In that case, your server-side scripts are almost certainly not built in C++. You probably have a REST API that branches to some Java or Node.js code.   And then for updaters Adobe likes to use Java even though Photoshop is obviously not written in that language. Not quite sure why but they do.   If your place uses automated developer support tools such as build machines scripts or Q/A services -and if you're working on huge software you bet you're going to find those- then nope, you didn't code those in C++ either.   For games, a lot of studios opt for a mixed C++/C# solution for their content authoring software such as level editors. Seriously, think of Unity 3D.   So yeah, big software projects can use more than one programming languages. Actually, scrap that: it's not only the big software that does. I worked on a small program (only ~20,000 LoC) for a CNC automation solution and we used C++, C# and Ruby.
  5. You need to take what you read with a grain of salt and evaluate whether it makes sense or applies to your project. ESPECIALLY when someone starts calling something always evil like in one of the linked URLs in the original post. At this point, I don't think there is anything that is always evil. I think I actually even have a good case for a goto in my rendering engine's code, which is the pinnacle of the NO-NOes in programming. (And I'm still looking to get rid of it.) So if you tell me that something as ubiquitous and proven as getters/setters are always evil, no, just no. Misused? Yeah, I think people often write a lot more getters and setters than they actually need to. But always evil? No. (And only a Sith deals in absolutes. :P)   The truth is that there are a lot of people in the programming circles that would like to make themselves a name by calling well accepted practices "evil" just because it's bad by some completely unpragmatic point of view, or because once upon a time someone misused the pattern or principle. Now it's get/set, last week singletons were evil. Next week if someone calls having a main() function an antipattern... well, remember I called it first here. :P   Don't ignore what you read, just have critical thinking. If you're a seasoned programmer, you know more about how to go with your project than some blogger with a book so listening advices and new method can never hurt, but in the end you're the one who can judge how to go with your project. A lot of those people writing about programming practices are academic Java programmers looking to sell their books or conferences. Probably the same type of people that state completely obvious things, wrap them in silly catchy acronyms like KISS, GRASP and SOLID and write PhD thesis around those, but I disgress...   I do think though that if you're going to write a data object with full read and write access and know it's going to remain that way, just write an old-fashioned plain-old-data struct. It's not "prettier" to have to write my_object.GetXXX() instead of my_object.XXX and for setters it's actually annoying if you like to do chain assignments or swaps. Qt is guilty of that a lot: you need to pass through methods to set the values of a vector or a matrix. It's just annoying. Don't do that.   This is kind of why I would like to see properties in C++: you can expose naked properties if you don't need to control reading and writing, and if you change your mind later and need a getter or setter, you can write them without breaking any code. But again, I disgress.
  6. The locations you listed have in common that they're either read-only or in a folder created in NSIS.   Look at the access rights of the folders created by NSIS in your User folder. Is it restricted in reading or writing? There may be an error in your NSIS script that makes it create folders that require admin rights, and therefore your app can't write in them.   Program Files and Program Data should be read-only so even the NSIS created folders should be read-only. (They're the equivalent of /usr on Mac/Linux.)
  7. This is great news. I don't care about the cloud, big data, Azure or all that nonsense, but Bash on Windows? Shut up and show me where to put my signature? :P   As far as I'm concerned, they may as well go all the way and replace the NT kernel with Linux and then port the Win32 API and the Universal Windows Platform. I don't actually dislike Windows, I think it's a great platform and gets blamed way too often when anything goes wrong, it's just that Unix-based platforms tend to get generally better development tools outside of Visual Studio, so if I get to run VS natively on Linux I would be one hell of an happy developer!  :)
  8. The point of C++ style casts is to specify your intent, so that the compiler can ensure that you're actually asking it to do what you meant to do. If you use C-style casts the compiler won't help you unless what you're writing is actually illegal code.   The way my C++ teacher taught us over a decade ago: static_cast<T> = "I know that type is naturally convertible to T." reinterpret_cast<T*> = "Yeah, I REALLY meant it." (T) = "Convert and shut the f... up!" Personally, I don't use C++ casts in my code, but I don't have a strong opinion for or against using them: I just don't use them today, and perhaps I will start using them if it bites me in the face tomorrow. I don't really care.   EDIT: But I think having long and annoying to type keywords like reinterpret_cast<T>(...) hinders the use of C++ casts. I know it's supposed to encourage you to write code that does not need casting in the first place but I wonder if it's really working the way the C++ people saw it. If you could do a static cast by writing something like (static int) and I dunno maybe (mutable int) for a const cast I think there would be less lazy C++ programmers out there.
  9.   This. A thousand times this.   Why is it that so many C++ programmers choose a Java style and (often) also throw out any and all uses of the standard library...      I would not use the C++ standard library coding style as the definite coding style for C++. It's not that simple.   Stroustroup, for example, recommends to capitalize the first letter of your class names to distinguish them from the standard library names, which is not what the C++ standard library does. He also recommends using UPPER_CASE for macro names (if you can't avoid them in the first place) to emphasize on the fact that they are alien in C++ and do not respect language's grammar, even though standard macros like assert(...) are in lower.   So no I don't think the C++ standard library standard is meant to be a hint of how you should name your things. (Unlike Java which tries to impose the JFC naming on your own code to the point where Eclipse generates compiler warnings if you don't use the prescribed style!) Boost uses lower_case everywhere because its libraries aspire to be part of the C++ standard library so it's different from your game engine.   But by all means, if you like the all_in_lower_case style go ahead and use it! My point is just that the C++ standard library coding style is not necessarily meant to be imported in your code, the way the JFC coding style is meant to be used by all Java programmers.
  10.   Yeah it's mostly opinion-based because neither C nor C++ recommends one, so people usually import the naming convension of whatever language they used before. If you learned from Java you are probably going to import it's naming convention (Yuck! I hate lowerCamelCase! ) as did a lot of C++ library writers because Java was the hot new thing from the mid 90s to the mid 2000s. (Qt and Ogre3D are examples of C++ libraries that imported Java style.)   Personally, it was VB6, COM and MFC that were the hot new thing when I started programming, and I mostly skipped Java, jumping straight to C#, so my style is very Microsoft-influenced.   The Linux/GNU guys will probably use all_in_lower_case because that's how the standards look over there.   Really, style issues like naming are more like a programmer's signature so use whatever you want in your own projects. (Obviously, use your organization's standards at work.) As long as whatever style you're using is readable and understandable, and you stay consistent, your coding style is fine.     EDIT: I forgot to mention that the big names of the C++ community came up with a guide in late 2015 that recommends a style, but that's the "Stroustroup" style, which is a style that pretty much nobody uses, so I wouldn't recommend that one as the definite style for C++. (The rest of the guide is pretty good though.)           In most of the case, it's Doxygen, although if you ever do .NET, SandCastle (or whatever the new one is called) is a bit better because it will generate docs that looks consistent with the one on MSDN.
  11.   A few points.   It takes time to make an RPG. When I dabbled with RPG Maker 2000, me and my brother both had our own RPG Maker games that lasted about 50 to 70 hours (which is about where it's acceptable for selling IMHO), but they took us years to make. I remember spending an entire summer just for a chapter of my game. Making interesting dungeons takes a bit of planning, writing good dialogues takes some time to reread yourself and ideally a few other pairs of eyes, making bosses that aren't either damage sponges or cheap shot spammers needs a good balancing eye, etc, etc, etc.   Considering the abysmal return on investment of the crushing majority of paid-for iOS games, spending that time flipping burgers at McDonalds will likely be a lot more profitable. If you're doing this to get super rich, the flaws in your idea is right there. You also forgot to add $100 per year for your Apple dev license, so your production costs are minimum $180, plus whatever licensing fees that your extra songs will cost you.   Yeah, you can bundle it with the premade assets, but if you actually take the time to make a good game, other people will have already flooded the App Store with cheap ass 2-minute games and people will be used to those assets. When I was in the RPG Maker community, whenever I saw games with RPG Maker "Alex" (or sprite rips from Squaresoft games for that matter) as the main character I hit ALT-Left and browse the next game. Although this is personal opinion, I also think that the current RPG Maker assets are fugly. You can use RPG Maker XP's graphics instead, but they are more work to use because the auto-tile function doesn't work very well with them.   Also, just in general I don't see the appeal of epic RPGs on iOS; I think it's silly to expect me to "game" seriously on my phone with a 6 inches screen and touch controls, and when you look at it, a lot of big companies (lol Sega) broke their neck on mobile platforms, thinking it had place for "true" games. Personally, I have owned Final Fantasy Dimensions on my Android phone for two years, and I am a huge fan of the classic Final Fantasy games, and I consider FFD this to be the best game titled "Final Fantasy" since FFX-1... and yet I still prefer playing Solitaire than Final Fantasy on my phone. (In fact I wish I could just play FFD on my PC.) I just don't care about "serious" gaming on my mobile phone, I want to play quick games on that platform. Things like Three!, Solitaire, Angry Birds, etc. So I'm not going to buy your RPG Maker game knowing that I didn't even finish Final Fantasy Dimensions... And I don't care about your epic storyline on my tiny mobile phone screen, I don't have the attention span for it when I'm playing on my phone. You could have the next Lord of the Ring or a story about a distant future where bionic toilets have overrun humans after a zombie invasion and it would be the same to me. Perhaps other gamers have more tolerance for tiny screens than I do, but to me gaming on iOS is a joke. Maybe I would on an iPad Pro but at that price I would put a Titan X in my PC instead.
  12. Microsoft has already done the hard job of adapting their Direct3D 11 API for use in apps that require high performance 2D graphics for which GDI+ is insufficent, and it is fully-featured because it's the rendering technology of WPF. The result is what we call Direct2D and DirectWrite.   If you don't mind C++/CLI interop code, I would recommend that you write a C++/CLI wrapper around the D2D features that you need and use that. That is what I did for my game editor in Windows Forms and it's order of magnitudes faster than GDI.   If you don't want to write C++/CLI you can access Direct2D via SlimDX or SharpDX but I had issues with those libraries.
  13. These days all I see in other people's code is var * type? Apparently some programmers are fed up with being told where to put the space and put it on both sides of the asterisk.    As for my opinion, I think all has been said: var* type unless you are declaring multiple variables on one line.
  14. At this point I'm simply exploring my options.   Right now I'm at the bottom of the barrel when it comes to serializing game data. To give you an idea, in the current system, the game data is serialized directly to a big ugly "db.dat" file using the .NET binary serializer and 10 year old code that I probably wrote right after noticing that C# had properties. As you can imagine, this is a pain in the ass because if you change anything in any of the classes that you serialize, the .NET serializer may refuse to load it, and then you have to write serializer handlers to read the data and initialize it yourself. Many times I was afraid I would not be able to recover the game data.   Since I'm rewriting the data sub-system of my editor from scratch, I'm also implementing a better way to serialize that data.   A relational database is not my only option, but it interests me because it will make it much easier for me to modify the data, and it would let me recover the data if something goes wrong. (Most are ACID.) In addition, I figure I could use something like Entity Framework or NHibernate to help me deal with data. Installing a DBMS on a system (though I would far prefer SQLite) is not a big deal to me because this is only for the game editor.   My other options would be to serialize to JSON or XML. I will take a more serious look at those CTE, but I'm not quite at ease with the SQL language to do those recursive queries right, so right now JSON looks like my preferred option.   But I will look at those NoSQL databases.
  15. Ok, so to do that in pure SQL, you need have a table that stores the schema, and then you have to store each value of each property of each object in a separate table. You can't have a clean table that lists all simple properties and leave them to NULL if they're not assigned? That's a bit more complex than I hoped it would. I also intend to use SQLite as I have no need for a DBMS powerhouse, and I don't think it has the most complex SQL features if MySQL doesn't. I suppose I could use SQL Server though.   Given a table that has a parent_id field, is it simple to write an SQL SELECT query that will simply walk up the tree and return me the lines in the order that they are encountered? (First line is the leaf, then it's it's parent, then grandparent, all the way to the root.) And then I could sort out the actual properties in software.