Disclaimer # 1: this is my personal opinion. It doesn't reflect the opinion of the companies I had or I am working for.
Disclaimer # 2: Most of these principles doesn't make sense for situations where the ratio between the number of developers and the number of active projects is greater than one. I had been involved most of the time in the opposite situation: a single developer by project or even worse, a single developer with more than one project under active development. If you are in the first scenario, lucky boy, just stick religiously to the development guidelines and good practices documented by your company (they have documented that, right?). But if you are in the solo arena (indie, freelancer, start-up?) perhaps you will find one or two principles of value for you.
- The OS is the IDE.
- Stay away from the "new thing" fever
- Reuse with libraries, not with frameworks.
- Shell is your friend. Automate your art pipeline.
The OS is the IDE
and yeah, by OS I mean Linux.
Stay away from the "new thing" fever
yes, I use makefiles and shell scripts.
Reuse with libraries, not with frameworks
Reusability is one of the golden goals of software development. "don't reinvent the wheel" is the mantra of framework supporters. I agree with that. But, know what? sometimes, when someone had created a popular framework the need to support more and more side cases transform a simple tool (a wheel) in something that looks more like an Autobot or a portal to another dimension. it barely maintains its round shape (yeah, thinking in angular.js again). At the end of the day, a framework is a highly-opinionated set of libraries that pretend to cover a lot of use cases. In order to keep reusable, the rules to configure and use it grows in length and complexity. You will discover yourself digging in stackoverflow to understand if a bug in your application is yours or comes from the framework. and don't even think in check the source code of the framework: it will be hundred of times more complex than your own code. say bye to productivity.
Libraries, on the other hand, don't presume of you attaching to a single way to use them. libraries encapsulate functionality generic enough (think of Three.js, cannon.js, D3, Processing ) and you will have plenty of opportunities to mix them inside your project. usually easier to debug, inspect and learn from them. Libraries also offer you the adventage of replace them easily that when they came pre-bundled and tight-coupled to a framework.
A final reason why frameworks tend to be complex: to avoid the label of "highly opinionated" they favored imperative configuration over "convention over configuration". the last one is ridiculously fast and productive if you work in internal projects, i.e when you are a framework user and not a framework developer. "convention over configuration" makes easier to roll your own scripts because you can make safe assumptions about the location of resources, output dirs, naming conventions and share them with your team.
disclaimer #3: large frameworks should be used for big projects, projects with long lifetimes and high rotation of developers. see disclaimer #2
Shell is your friend. Automate your art pipeline
A particularity of videogame naming conventions and standars of the art assets in order to be properly integrated into the project. Dev teams tend to produce large documents of technical specifications for the artists, who generally are not fond of study them in detail.. Playing with the saying of "a picture worst most than one hundred words" I would say that "a script worst most than one hundred words". Instead of writing spec documents, write scripts that actively validate the application of the specs automatically each time the artist submit a new asset.
That is easier that it sounds, if you start with the right mindset and choose the right tools. Opensource projects like Blender, Gimp and Inskcape (the tools I use in my projects) offer you mechanisms to run scripts directly inside the tools, and even better, you can run the tools in command line mode (headless) and that means that you can integrate the exporting of the asset in your toolchain. Mix that with git and continous integration techniques and you will never worry again about that artist that thinks that including emoticons in the name of hers assets is cute.
Note: An example of the headless scenario that I use is to execute from Make a Blender instance that opens a 3d model (.blend file), exports it using a custom python script, and store the output as json for reading in the assets folder of my web project. I expect to write another entry with details on that technique.