Jump to content

  • Log In with Google      Sign In   
  • Create Account

Ravyne

Member Since 26 Feb 2007
Offline Last Active Yesterday, 06:28 PM

Posts I've Made

In Topic: Do you usually prefix your classes with the letter 'C' or something e...

Yesterday, 02:07 PM

I've simplified to the essentials over the years. I prefix for interfaces, cause C# still rolls that way and I like it. (Non-pure abstract base classes are suffixed with Base, usually.) Single underscore to label _private or _protected class variables*. And g_ for globals because those should look gross. That's pretty much the extent of it.

 

* The underscore thing also works great in languages that don't HAVE private scoping, or when I don't actually private scope them but they're considered implementation details.

 

I follow this kind of minimalist approach as well. Prefixing classes with C, or variables with their atomic type, or similar things doesn't really tell you anything useful with modern tooling. Even people who work with text-mode editors like emacs or Vi(m) will have CTags or some kind of IDE-like intellisense-thing going on.

 

Scope is still something helpful to know so I do 'g_' prefixes for globals and 'm_' (or sometimes, just '_') prefixes for private/protected members. I also like to know things like whether a variable is static or volatile at a glance, so I use 's_' and 'v_' prefixes there -- these are rare though.

 

As far as general naming, I use plural word-forms when dealing with collections of things, and boolean variables/functions are almost always prefixed with a word like 'is' or 'has' to reveal the question being answered -- like 'is_dead' or 'has_children()', among other things similar to what DonaldHays quotes above.

 

In C++ (as are all of my examples above), I defer to my own personal axiom of "do as the standard library does" regarding naming and other externally-visible conventions. For example, this is the reason I now use lower-case-with-underscores style, rather than CamelCase or pascalCase as I did at different points in the past. When I'm doing C#, my naming conventions follow the style of its standard libraries. My rationalization for why this axiom of mine is a good approach is that 1) these standard libraries represent the only style that has any credible claim that it "should be" the universal style, and 2) they've seen every odd corner case and combination thereof, and have laid down an answer; I don't have to waste brain-cells thinking it through and then being self-consistent on each rare occasion it comes up, months or years between.

 

Of course, if the place that makes sure your paychecks don't bounce has a house style -- and most do -- then you follow along with that because its part of what you're paid to do.


In Topic: Are Third Party Game Engines the Future

Yesterday, 01:06 PM

@Ravyne

Though if you look at Unreal Engine 4, you will see a huge variety of different types of games being made with it. UE4 is very different to UE3. It supports large open worlds out of the box and small studios are making very big games with it. For example, Ark: Survival Evolved was created by a virtual team of indie developers. The engine is very flexible and although it may not be optimal for a specific genre, the source can be modified to make it optimal. An indie team starting out will not be making boundary-pushing games. If the team is successful and grows, they can hire more programmers and heavily modify the engine for more ambitious projects. UE4 is a lot more flexible. The Oculus team replaced UE4's renderer with their own for VR optimization and used it in the games they are making. They've also made this branch of the engine publicly available.

 

For sure, and UE4 is worlds better than 3 ever was -- I just meant to say that FPS is more-or-less the only "turn-key" option that Unreal gives you, or at least the one that's most turn-key. For all its flaws and over-engineered inefficiencies (keeping in mind that their "inefficiencies" are still faster than anything you or I would likely crank out without a ton of iteration), no one can deny Unreal Engine has powered one of the top-tier FPS series. I'd wager there's still a lot of code/design decisions in there stem from its FPS roots, though, obviously, they're going to be a lot more subtle and a lot less limiting than having an FPS-centric API surface.

 

On the topic of derision, what's popular and what's good are often barely-related axes. When last I interviewed for games positions before my current full-time gig of 5 years, it was a popular interview practice to show you some piece of shipping code and point out the bugs, or suggest ways it could be improved. After a time, I realized that every single one of these exercises, at several different studios, all used source code from UE3. That tells me two things: 1) that UE3 was not held up as any sort of paragon, and 2) that despite this, it was still popular enough that all these studios were familiar with the engine and cared that new hires could follow its source code.


In Topic: Are Third Party Game Engines the Future

26 May 2016 - 12:26 PM

I think these engines are here to stay,and will improve over time; Unity is especially dominant in the indie space now, and Unreal is making inroads there (slowly) but has more mindshare among pro studios. Cryengine doesn't seem to have much uptake at all. Also in the indie space are simpler engines and frameworks like Cocoas, Monogame, DXTK, and others.

Every single one of these has their own point-of-view, quirks, and warts. All of the engines have their own way of doing things that you need to learn to work with. Frameworks are sort if similar, except you're not so locked into doing things "their way" just by virtue of the fact that they do less and have fewer intertwined systems.

"Jack of all trades, master of none" as they say--most people take that to be an insult, but the full quote goes on to end with "--but better than a master of one." These engines are a great value proposition, but they don't fill that need for masterful execution (well, unless you're using UE4 to make a shooter). That's why in-house engines will always be a thing on the high-end.

On the low end, the mental lock-in and quirks of engines can be more hindrance than help for very simple or very unique small-scale games. Especially using those frameworks I mentioned, it can be less headache to roll your own purpose-built engine than to fight against an engine's natural currents to modify it to your needs; or simply to sidestep all those engine abstractions that are more complex than your game needs.

Where engines are worth their while is really in the middle ground -- your game is complex enough that rolling your own tech is more costly (money, time, risk, market opportunity), but not so unusual as to be a poor fit, and also not so complex or boundary-pushing that it risks outgrowing an off-the-shelf solution. Many games great and small fit into that box, and that's why Unity and Epic can staff hundreds of people behind these offerings and make healthy businesses of it.

Another side-effect, for good or ill, is that these engines instill a certain amount of liquidity among developers, and particularly those who aren't ninja-level engine developers. Unity and Unreal are concrete skill sets that you can recruit and hire on--before these engines became popular, every new hire had to spend time picking up the house engine, house scripting language, house toolchain, house pipeline. Nowadays that's still true many times--but not at the same rate it used to be. Part of the attraction for using Unity or Unreal among larger studios is that they gain a significant hiring pool (even including people who may not have a traditional CS background) and that those people can hit the ground running, more or less.

In Topic: Why Are Fantasy RPGs so Popular?

19 May 2016 - 01:35 PM

Its kind of a trope -- same as "space marines". We tend to like and make these things because they're established enough to be familiar, yet they're not closed systems so we can change and expand without alienating people. Fantasy also spans a wide berth though, so probably seems bigger than what's objectively Tolkien-esque -- for example, I wouldn't say that the Final Fantasy or Dragon Warrior franchises have much in common with Tolkien's world, even if they took some inspiration from it; but they do very much fall under the heading of Fantasy.

 

I do agree though that there are other worlds and mythos and real cultures that are largely untapped. There are relatively few games that tap Norse mythology, for instance, or (especially outside of Japan) the Japanese feudal period or themes of, say, Bushido; almost no games have explored African themes, Native American themes, Central American themes, or South American themes. Very few games have explored a more-or-less contemporary setting for game styles most-closely associated with fantasy or historic settings (Earthbound is a notable example). American West themes are pretty untapped (check out Boot Hill Heroes).

 

There's inspiration everywhere and its a shame games haven't branched out more.


In Topic: Best gaming platform in the future with marketing perspective.

18 May 2016 - 04:43 PM

I hate to rain on the anti-Microsoft parade, but all this advice to avoid Microsoft or vendor lock-in is tangential at best, and at the least seems outdated. But to start from fair ground, I'll throw out the disclaimer that I'm a writer (docs and such) on the Visual Studio team.

 

If you haven't been following along lately, Microsoft as a whole is really leaving the our-way-or-no-way mentality behind. To be frank, today's devs have more options that are good than was the case years ago, so there's a lot more mobility in dev tools, platforms, languages, etc -- they don't accept our-way-or-no-way anymore. Microsoft's continued success and relevance actually requires them to get with that program, and so they have. Today, Visual Studio is already a damn fine IDE for iOS, Android, Linux, and IoT development, in addition to the usual Microsoft platforms -- even just a couple years ago, Eclipse would have been basically the only "serious" IDE for those scenarios (and its still got inertia today). For example, you can do your programming using Visual Studio on Windows today, and the build/run/debug commands will talk to a Linux box where your code will be built (using your typical Linux development stack), launched, and hooked to GDB, and GDB in turn talks back to Visual Studio and looks just like a local debugging session of your Windows apps. And that's basically the same scenario for Linux-based IoT, Android, and iOS as I've described for Linux on the desktop and server; The android stuff can target a local emulator running atop Windows Virtualization, and is actually considered to be better than the stock emulators provided by other Android development environments, even if that sounds a bit unbelievable. Soon, you'll be able to run an entire Ubuntu Linux environment right inside Windows 10, so that developers will have all those familiar *nix tools right at hand.

 

Believe it or not, "old Microsoft" is basically dead and buried, especially in the server and developer tools division. They're pretty hellbent on making sure that Visual Studio is everyone's preferred IDE, regardless of what platform or scenario they're targeting -- and for those that like lighter-weight editors there's Visual Studio Code. Stuff is being open-sourced left-and-right, all our open-source development happens on GitHub, and a bunch of our docs and samples are already on github too.

 

By all means, people should find and use whatever tools and platforms they like; they should target whatever platforms they like, and as many as they like. Odds are, Microsoft and Visual Studio are relevant to where you are and where you're going, or will be soon. It's silly to dismiss them just because they're Microsoft. I use lots of tools every day in my work here that came from the *nix world -- Vim, Git, and Clang to name a few -- and they serve me well; partisanship between open/free and proprietary software isn't a very worthwhile thing IMO, unless you're talking about the very philosophy of it all.


PARTNERS