Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Ravyne

Member Since 26 Feb 2007
Online Last Active Today, 03:55 PM

#5177577 Making 2D Images

Posted by Ravyne on 01 September 2014 - 10:42 PM

Vector or raster?

 

Vector images are mathematically-encoded lines laid down as strokes and fills. They can be scaled up or down perfectly, and animations are typically accomplished through a skeletal-style animation system -- Many flash games are examples of this style. Adobe Illustrator, Inkscape, Flash, and AnimeStudio (I believe) are examples of vector art tools.

 

Raster images are 2D grids of pixels, typical of a bitmap or similar. Sometimes called pixel art or sprites. They can scale well taking into account the size of the source image and the range of sizes it will appear as on-screen, and can be combined with mip-maps for better scaling. Animations are typically accomplished on a frame-by-frame basis. Adobe Photoshop, GIMP, Paint.Net, GraphicsGale, and Cosmigo ProMotion are examples of raster art tools.

 

Some Raster tools are geared more towards high-resolution, high-color work (Photoshop, GIMP) such as photo editing -- but can also be used to create such images from whole cloth. Others are geared more towards low-resolution, low-color work (Cosmigo ProMotion, GraphicsGale) and often include built-in support for frame-based animations; these are great for the kinds of 2D sprite-based games typified by the SNES, GBA, or 2D arcade games.

 

I personally really like Cosmigo ProMotion for 2D pixel art in that retro style, which is what I like. I'm not a big fan of 2D vector art, so I've never looked at or considered those tools. 




#5177558 Types of Programming

Posted by Ravyne on 01 September 2014 - 08:05 PM

You're not really talking about programming at this point, but domain-specific knowlege. If programming is carpentry, then being a AI programmer is like being a carpenter who specializes in building stairways, or being a network programmer is like being a carpenter who specializes in installing windows. They're trades based on the same foundations, but with some additional specialized knowledge, tools, and experience.

 

I would suggest that going into your second year of university might not be the best time for you to choose a life-long specialization; instead, look at it as an opportunity to grow as a *general programmer* through pursuing *specialized problems* that interest you. For now, choose something that interests you to help motivate your studies, rather than trying to set your life's path. Besides, there are very few people of any occupation who make a living strictly from a narrow specialization, especially in technology. You need to be a strong generalist as well as having one or more areas of specialist knowlege and skill level. Don't be afraid to spread yourself out while you're young, it may be the only time in your life that you're free to change your own direction without having to justify your decision to your obligations -- it may not be possible to change course in the future to pursue a life as a game programmer if it means having to leave your well-paid but unfulfilling life in data mining when you have student debt, a mortgage, or a family to support.

 

If you don't already have a strong feeling that there's one of these that you want to do, don't feel like you have to make a decision now. Try out different things until something draws you in. 




#5176800 Why don't gaming companies release past SDKs publicly?

Posted by Ravyne on 28 August 2014 - 06:57 PM

Servant has it pretty-well covered -- For console development, in the past, the development kit was comprised of both an SDK (software which you run on your workstation, system libraries, etc) and hardware elements -- for example, on the XBox 360 there was a hardware unit that plugged into where HDD would normally sit on a retail console and the purpose of the unit was to emulate the optical disc drive, among other things.

 

Companies would have to bare the cost of manufacturing and supporting all this hardware long after it made financial sense to do so. Usually, software development for a platform stops ~10 years after its launched, and in the meantime the next-generation platform has already been out for 3-5 years and all major third parties have moved onto that platform -- most customers by that time, too. Releasing development tools free and clear, even unsupported, would be a nice gesture but it still entails some effort on their part -- they would still need to operate and offer their quality assurance and disc-signing services in order for you to create retail discs, they would need to provide developer support for the times you had questions about the hardware or software. Those things cost quite a lot to do, and occupy resources that could be better spent supporting the new platform.

 

Some of this might change with this generation -- arguably, the fact that you can still publish and sell XBox Live Indie Games on Xbox 360 even though the XNA platform is dead shows this -- but I expect the current generation will be more open soon, and stay that way. I also would expect that a vibrant indie community will outlast the support of major 3rd-party developers in this generation's twighlight years. 




#5176552 Legality question concerning a program and cars

Posted by Ravyne on 27 August 2014 - 06:15 PM

I'm with Tom 100% on this one. A very subtle question that depends on details of what you're doing. One possible outcome would be that you're effectively a journalist, which gives you a certain degree of leeway, but also doesn't protect you from things like libel if a car manufacturer believes you've misrepresented their product. But much depends on what exactly you're doing.




#5176534 Abstract away the API?

Posted by Ravyne on 27 August 2014 - 04:48 PM

Abstraction is a sane approach, but a complicating factor here is that D3D12 is quite a lot different than D3D11 -- More different from D3D11 than OpenGL is, in many ways. The threading stuff and more-manual resource management is very different than previous graphics APIs. In practice, this means it will probably be impractical to unify the two styles under a single low-level or mid-level abstraction, there's just not enough wiggle-room there to hammer out the differences -- I mean, you could almost certainly implement a D3D11-style low-level API in D3D12, but you'd loose many, if not most, of the benefits of D3D12 in doing so.

 

A better approach would probably be to have a higher-level abstraction that's possibly based on multiple lower-level abstractions itself -- think of one low/mid-level graphics abstraction over D3D10/11/OpenGL, and another low/mid-level abstraction over D3D12/Mantle/Console APIs, and both of those abstracted together under a higher-level rendering API.




#5176533 How does one create flexible pixel art?

Posted by Ravyne on 27 August 2014 - 04:37 PM

With 2D raster art (or 3D voxel art, for that matter) there's very little you can do to stem the sort of combinatorial explosion you're describing. You can reduce the number of base variations by imposing certain standards -- say, "the hands are always placed in this position when the player carries a two-handed weapon, and in this position when the player caries a one-handed weapon." and then you animate the weapons, individually, based on that. 

 

Another trick you can do is to reduce the number of variants by not encoding final colors into the images directly -- then, you only have to animate the wizards' robe once, and you can color it differently inside a pixel shader, or with palette tricks.

 

There's no way to avoid the combinatorial nature of the number of assets you have. Its just math. All you can do is A) reduce the number of variables in the equation (fewer axes of customization), and B) reduce the magnitude of those variables (fewer customizations within each axis). The above are two ways of doing that.

 

 

3D rendering can help, because you then have 3D objects and animations (eliminating the need for rotation as one of the axes), textures and shaders can be changed independent of geometry, and skeletal animations separate geometry from animation. Still, it has its own set of problems -- for example, if you animate a character for using a sword, but he's holding a long staff instead, the animation might cause the staff to awkwardly impale its holder mid-animation -- in other words, even though you have the benefit of skeletal animation, you still might have to have a set of animations for wielding a sword and a different set for wielding a staff. You still might have to have different animation sets for different characters, depending on how different their body styles are. In general, 3D is less affected by combinatorial explosion, but its not a magic bullet.




#5176523 Spritesheet or single-sprite files?

Posted by Ravyne on 27 August 2014 - 04:12 PM

On thing here is that you're conflating content creation workflow issues and runtime issues.

 

For runtime performance, you want to minimize the number of draw-calls you have to issue, and a good way to do that is to collect together a bunch of small sprites that have the same or similar properties into a single, large texture -- then, you can feed a list of triangles with different texture coordinates to draw various sprites from it. Same idea with array textures, it just depends on what your hardware supports -- Sometimes you might know at build time what's best for a platform (say, on a console or other fixed platform), sometimes you might know at deploy time (say, from the AppStore where you know (IIRC) what device the package is being deployed to), and sometimes you might not know until runtime (say, on a PC). For best performance, you want to defer the decision of runtime formats until you know what your hardware supports, but you might just pick a good middle-ground like texture atlases, sacrificing some performance to regain some simplicity.

 

For your content creation workflow, you want to focus on what's the most efficient way for you to work with the art assets, and to get them into your work-in-progress builds. You might prefer to work with individual image files, or there might be technical reasons for doing so -- like image characteristics or version control. Sometimes you might prefer to work with sprite sheets containing tightly-related images -- like a single character, or even a single animation of a single character. How you or your artists work on your game's assets is about 75% preference, tempered with 25% technical considerations.

 

But the important take away is that these things don't have to be (and probably shouldn't be) the same. That is, just because your game might run best with a texture atlas doesn't mean you have to create your art assets in a texture atlas -- all you need is a little command-line tool to assemble the texture atlas (or, your game could do it on the fly, if you're willing to give up some load time) from smaller files containing fewer images, maybe just one. You can make this a part of your build system, so that the assets are assembled together when you build your game.

 

I like to think of code, assets, developers and artists as being "on the near side" of the build system, and software builds, "run-time", and end-users as being "on the far side" -- Often what's best for the near side is different from what's best for the far side. The build system is everything that automates the process of going from the near side to the far side.




#5176073 free private SVN with biggest disk space?

Posted by Ravyne on 25 August 2014 - 03:42 PM

You're probably not going to find that for free.

 

I use Dreamhost for my web-hosting plan -- I don't use them for Version Control, but they do have 1-click SVN install as an option. Disk space / bandwidth limits are high enough to be effectively unlimited for any reasonable purpose. I pay around $10 USD / month.

 

Another option would be a VPS or similar. There are many options for hosts, but the one I like best is Digital Ocean -- you can get an instance with 1CPU / 512MB RAM /20GB storage / 1TB traffic per month for just $5 -- and they actually bill hourly, so you don't pay if you take it down for any reason. For $10/mo, you get 1CPU/ 1GB RAM /30GB storage /2TB traffic. Either plan would be enough to run a version control system and then some -- maybe webhosting, a bug tracker, and a nightly build system if you were so inclined.




#5175590 How are retro-style games like Papers Please and The Escapists made?

Posted by Ravyne on 22 August 2014 - 10:07 PM

You can do a relatively retro-looking game just by using low-res art assets, limiting your total on-screen and per-sprite colors, and by choosing an appropriate (smallish) color palette. For example, if you want a game to look distinctly like an NES title, the single biggest thing is using just the ~56 colors that the NES could display -- the NES palette is particularly distinctive because its not an RGB palette, and hence its a little odd (e.g. there's no really good 'orange'). That alone evokes the feeling of an NES game, but to really drive it home you would want to place further restrictions on yourself, like only using 3 colors + transparency in each tile making up the sprite (8x8 or 8x16 pixels), or in each 16x16 pixel area of the background -- these were hardware limitations of the NES hardware, other hardware had similar restrictions; it wasn't until the Saturn/Playstation era that only memory, not hardware, was the primary limit on 2D graphics.

 

Aside from that, just avoid doing things that would have been impractical or impossible on the old hardware -- no smooth sprite rotations on an NES, so use the same work-arounds the old games used. No alpha transparency either, again, use the same work-arounds the old games used.

 

Then, you can go a step further still and use the really neat hardware effects that systems like the NES and SNES could do -- change the color palette entires between frames or scanlines to perform palette animations, gradient effects, or to use more colors than is possible in the naive way; scale and shift the scanlines to create perspective in the same way that old racing games like Pole Position did them.

 

Basically, you imitate the limitations, quirks, and clever hacks that all the old games had to live with.




#5175159 Own ruleset - how likely do I violate others?

Posted by Ravyne on 20 August 2014 - 09:06 PM

I am not a lawyer, so do not take this as legal advice -- that being said, here's what I think about your question...

 

You're being paranoid.

 

Not just about yourself infringing on others, but of "protecting" your own ideas as well. This stems, bluntly, from a complete lack of understanding about what can even be protected and of how valuable or not something is, just because it's 'protected'. The symptoms are evident in the way that you think you're working around D&D rules by using different stat names, etc -- and in your being overly secretive about your own specific rules. If anything at all can be protected, its certainly not the generalities -- its the specifics, in concert. That is to say, using different stat names affords you none of the 'protection' you seem to think it does, and by not revealing your complete ruleset no one here can formulate any idea at all about how vulnerably you might or might not be to litigation. I'm not saying to never think about it -- certainly you can't just clone existing rules outright and get away with it unchallenged -- but protection of creative works doesn't typically afford each element in isolation (e.g. rules, archetypes, themes, a'la carte) protection, it generally protects the sum total of those things, possibly together with *specific* people, places, and things (that is, nouns that begin with capital letters.)

 

Besides that, you say it took you three years to develop -- so, either in those three years you've done something amazing with and around those rules, creatively, which serves as a moat around your castle (good); or, what you have isn't all that special and neither affords or deserves the protection you think it does (bad). Game mechanics of any kind, as a general rule, are difficult or impossible to justify protecting -- ideas alone are not afforded the benefit of protection out of hand, there are requirements that have to be satisfied first.

 

And even achieving your own special snowflake of a game, guess what? Anyone can sue you at any time for any perceived toe-stepping at all -- and to the degree that their allegations have any semblance of a reasonable reality at all, their charges will either be thrown out, force you to settle, or drag you through a trial. That's not just a threat, its a legal tactic that IP holders use *all the time* to keep would-be competitors out of their scrapyard -- sometimes the bark is just as effective as the bite.

 

Despite my hyperbolic tone -- there's no bad news for you here, unless by "not copying D&D" you actually meant "I'm TOTALLY copying D&D!" If you can put your game down in front of any role-playing group worth their salt and they don't immediately shout "Dude! This to totally F*cking D&D!", you're probably about as safe as you can expect to be.




#5175067 So... C++14 is done :O

Posted by Ravyne on 20 August 2014 - 11:38 AM

Am I the only one that thinks that all those new features makes C++11 look and feel completely different than C++?

Seriously, that's practicality a different language, why keep calling it C++?

 

Thankfully -- nay, intentionally -- you're not the only one and its honestly the best thing that's happened to C++ since its original standardization (C++98).

 

Its still C++ -- save for the old meaning of 'auto' and some difficulties with primitive sizes, all your old C++ code should mostly just compile. From that same source code, the object code generated today will be vastly superior to what would have been generated at the time of its writing. But writing non-trivial, well-engineered programs in C++ has always been something of an obtuse exercise -- the mechanics of lambdas, for instance, have always been there (I spent a solid month some years back 'back-porting' code with lambdas to a compiler that didn't yet offer support); building them into the language is so much better. For years, C++ has hobbled along with villainously-clever, mostly-working library implementations of what are language-features in other places (See: Boost). This has had an effect of making 'serious engineering' in C++ mostly a domain reserved for experts. There are several sub-themes to C++11/C++14, but the one unifying theme is making all that expert-level engineering stuff (simplifying call-backs with lambdas, simplifying template code with auto, decltype, variable templates, etc) accessible to the non-expert.

 

C++11 *is* a different language -- one better than previous incarnations of C++, but one that is (previous exceptions noted) basically a perfect superset of its older self.




#5174803 Weapon statistics visualization

Posted by Ravyne on 19 August 2014 - 12:57 PM

Don't make it an explicit and permanent part of the interface, or at the very least bury it under the pause screen somewhere.

 

The best possible way is to allow the game to demonstrate it to you -- perhaps because the first time you encounter it is in the hands of a friendly character or foe. Or, maybe you infiltrate a laboratory where the weapon is developed and the results of its tests are visible. It could be part of a cutscene, even. Be creative, and keep in mind you don't have to do it with 'standard-fare' weapons -- the machine gun, "bfg-9000", and shotgun/"spreads" are well-worn tropes.

 

If you are compelled to have a slick animation in game, have it interrupt gameplay with a modal dialog, but only the first time you pick up that weapon -- furthermore, as best you are able to within the confines of your design, try to ensure that this first time the weapon is picked up happens during a lull in the gameplay as to not break up the immediate flow or intense action.




#5174800 What game companies hire remote programmers?

Posted by Ravyne on 19 August 2014 - 12:49 PM

Remote positions at big studios are almost unheard of -- they will sometimes allow for existing employees to work remotely, but as a new hire this is pretty much limited to those with an especially high level of skill and an established track record. In general, game development at a scale of larger than a dozen or so people is a very collaborative process where daily face-to-face communication is a necessity. Complicating matters further are technological issues, wherein it might be very difficult for a remote worker to have a workable network connection for all the high-bandwidth things he needs to do -- a developer like yourself needs either the bandwidth to download regular, full builds (which could be in the 10s of GBs, daily or more) or needs to maintain a local copy of all in-progress art and code assets, along with a fully replicated build system. Even further complications arise if you do console development or must work under NDAs that prohibit documentation and/or physical dev-kits from being stored at non-commercial work-sites -- I'm not sure if its that way with the just-launched generation of consoles, many of the companies seem more open about it, but at least in past console generations none of the manufacturers allowed you to have a devkit if you worked from a home office.

Certain roles are more amenable to remote work -- Audio in particular, where the workflow permits and where few companies have enough demand to justify a fulltime composer or sound designer (even large ones). Most of that is contract work. I imagine art is the same, to a lesser extent.

Companies that work relatively exclusively on PC titles, or smaller indie studios are typically more amenable to remote situations -- many of the better known indies studios started as -- or still are -- largely remote affairs.

 

Small contract work is sometimes available, but it takes a lot to build up a reputation and unless you know someone, usually requires working your way up from the bottom. One of the best ways to fast-track your reputation is take on an open-source project to work on -- remember that any code you write under contract isn't something that you can just slap into your portfolio.




#5174793 So... C++14 is done :O

Posted by Ravyne on 19 August 2014 - 12:27 PM

My understanding is that range-for isn't strictly syntactic sugar, because iterators can fall down (or at the very least can be unwieldy, possibly requiring otherwise unnecessary specializations) under template code. It might be the case that std::begin / std::end alleviated those problems (IIRC, range for utilizes them), but I also believe it was the case that std::begin / std:: end were proposed after range-for had gained steam -- besides that, I like that range-for specifies intent exactly "visit each item in the container once, from front to back", yes the iterator idiom is common, but if the loop body is more than a few lines long I have to parse it to make sure there's no funny business going on with the iterator.




#5174534 So... C++14 is done :O

Posted by Ravyne on 18 August 2014 - 02:14 PM

You also missed extended constexpr Nevermind, no you didn't, but regardless -- for a complete rundown, see https://isocpp.org/wiki/faq/cpp14-language

 

The new auto return type is more than just extending it to functions, it also has more capability with respect to multiple return statements and recursive calls -- basically, as long as the first return statement's type can be deduced, you can now have subsequent return statements, including recursive calls, as long as they all agree on the type.

 

decltype(auto) is a new refinement of type deduction that is mostly useful to preserve the reference-ness where simple auto wouldn't -- My understanding is that it performs the same function as auto-with-trailing-return-type-of-decltype, but without the trailing part. It can be used anywhere a declaration can be used, which might be useful but early guidance is that this would be an anti-pattern. This is super important, but mostly for library-implementors.

 

There's also a new standard [[deprecated]] attribute to mark deprecated APIs, and you can now use the single quote (') character anywhere in numeric literals to separate digits to make them more readable, in any of the literal formats -- e.g. 0b0110'0011 to separate out the nybles in a byte.






PARTNERS