Visuals are a big challenge for the solo programmer developing a vision is the first challenge and probably the easiest you will face. Sorting out your vision however also the most important; you need to be aware of your limitations, what tools you have available and perhaps more importantly time. Tooling can make or break the process; not only do you want a tool that fits your mind set but you are going to want to find one that fits with tutorials that are applicable to your needs.
Many will probably disagree with me but for a programmer Blender fits the bill nicely; while its UI is complicated and does take a bit of getting used to your probably already comfortable with complex development tools and the scripting for Blender is very open and accessible. There are also a ton of tutorials for Blender (as well there are for others) in particular I found the Blender community to have the most applicable tools, tutorials and plugins for my particular project coupled with the price point and a small bit of prior experience with the tool I went this route.
Be sure to review each of your tooling options remember you will be working with this tool a lot, you will be working outside your comfort zone and you will need reference material (tutorials, demonstrations, etc.). For note I went with The Gimp for my raster editor; again some prior experience, available plugins and tutorials, etc.
Once you have settled on a set of tools stick with em; unless you find you have a hidden talent for picking up new graphics tools and running with it that is. Next you will want to explore your limitations; start by roughing out key and common visual assets that you will need. You will want try your hand and making these your self even if you can find a kit or tool that helps you along these assets likely reflect the bulk of our content need, should be vivid in your mind and offer you a chance to explore your tools set, develop your skill set and refine your vision for the project.
During this phase I discovered that 3D assets where far easier for me to develop than 2D; up to this point I had assumed the inverse and was planing a 2D top down experience discovering this early on allowed for changes to be made with minimal loss of effort.
Now that you have your tools, some familiarity with them and have had a think about your visual direction your ready to go a' hunting for resources. There are loads of graphics artist out there that have built kits/plugins/etc some even offer the resources openly (i.e. little/no cost). You will want to use these to derive your work from not as the finished product in most cases. Keeping everything looking like it belongs together is key in my opinion; its far better to have a consistent style and level of quality than to render the best you can manage on each item; remember immersion is important to most games and your gamers imagination will fill what gaps it needs to, presenting a world of stylized actors with 1 realistic object in the scene will break that suspension of disbelief and hurt the game farm more than aligning to your weakest element I feel.
Sorting out your time line is next; by now you should have sorted out your tool set, identified you limitations, adjusted your vision accordingly and located foundation resources from which to build off of. Review your level or mission concepts and identify roughly what will be needed for each in terms of assets; just like attacking a programmatic problem break this down to its primitives and identify similarities i.e. objectify it then simplify. You should be able to identify groupings of assets such as in Project Fury's case we have Ships, Planets, etc.. The ships account for the majority of the unique assets and so I set about simplifying them while keeping there style inline with the vision.
An example of how you might simplify:
With my ships I had originally wanted animated turrets in fact it was a early focus point during concepting even in the 2D phase. While I certainly can do this it will add a considerable amount of time to my asset creation; I could simplify the turret system however that will take time as well and the return on investment just isn't there given the scale i.e. the majority of the time my gamers will be looking at big ships from far away and moving fast and the turrets while some what visible don't account for much of the visual experience and so I went for static turrets. These turrets are visible for fly by shots where the camera is close but don't move; they are shaped such that at a distance its difficult to tell what direction they aim and in my game lore rounds from them aren't visible right out the muzzle but fade into and out of view as they spawn and destroy.
During this process Project Fury evolved from a 2D top down capital class space shooter to a 3D (orbit camera) shooter where the player can fly a range of ships. The visual vision adapted from a flatter stylized high saturation look to a darker bumpy visual with shiny accents to draw the gamers eye, leverage my strengths and down play my limitations.
Most importantly the visual direction has evolved such to keep it manageable time wise leaving me more time to focus on what I do do well with game logic and game play.
Finally save some budget if any; once you have the bones of your game in place you can contract resources to fill your gaps and smooth out the bumps.
Project Fury is still under development; and this article is entirely my opinion which will undoubtedly change and grown as the project drives on. Leave your feedback; tips suggestions and let me know how you approach your limitations with game development.
