Right now, i work at a large company, doing boring enterprise work with Java, PHP and JS. ERP's, CRM's, ecommerce-ish apps. The last fun i remember having was when doing a mobile app with Xamarin. How can someone "stuck" in this portfolio, and with a solid carrer on this, prepare for a switch to gamedev? Start doing small games in Unity to showcase? But what if i'm not creative enough for a full game, but yet, i want to work with creative people providing my other talents in engineering and architecture?
How can someone "stuck" in this portfolio, and with a solid carrer on this, prepare for a switch to gamedev? Start doing small games in Unity to showcase?
Yes, start making games in Unity and/or Unreal. Learn C++ if you don't know it already. If your resume/CV has enterprise software on there, it proves you can write code in a professional environment so that already puts you above a typical amateur. The only thing that's missing is the proof that you can solve game-specific problems. How would you design a quest system? What about morphable terrain? Or destructable terrain? How would you approach enemy AI? Making your own side projects will prove that you can solve these kinds of problems and demonstrate your passion.
But what if i'm not creative enough for a full game, but yet, i want to work with creative people providing my other talents in engineering and architecture?
That's fine, I've worked with a lot of engineers who aren't great designers. All it means is that you probably don't want to work in gameplay. You can easily be a systems engineer or a tools engineer. In fact, being a tools engineer is probably a great way to break into the industry for you since it's probably similar to what you're doing. You could start building tools now to show them off. For example, make a tilemap editor or an XML viewer. These are fairly straight-forward tools and give you something to talk about.
Thank you! I guess i'll just dedicate myself to a small game clone, but focus on the tools and the engine, which is what gives me lot's of fun.
If you're going to practice tools work, I recommend focusing your tool designs on iteration time. A typical level designer will spend his time making small changes to the level, which then needs to be rebuilt, bundled and pushed to the game (which may be on remote hardware like a console or phone/tablet). The more time you can save them the better. A pretty GUI (whilst still important) wont make up for dog-slow iteration time. GCC has a section which gives you a good start for a level editor: using the game engine itself as the renderer for your level editor's viewport, and allowing you to query & set the values of scene actors. It's not always possible to do it that way (if you don't have a renderer that works on your dev system for example), but you can usually achieve similar results by other means.
My engine uses the ZeroMQ networking library, so I have a few connections running to pass data to and from the game, which can be on a totally different machine from the editor. The game broadcasts logging messages to the editor (and information about actors on request) and the editor pushes commands to the game to update component values, trigger events and even update assets. The last feature is my favorite - I can start the game, and whilst it's running make modifications eg. changing my shader code, or editing a texture. The file monitoring process then sends the changed file to the game, stored in the resource manager's cache and the resource handles invalidated. Then all of the systems that use the resource will re-load it again, giving me the ability to prototype my changes on actors in the game in real time as they happen. No need to even restart the app. There are limitations of course: updated files must be kept in the resource manager's cache, otherwise the original file will be re-loaded. However I can just replace the file on disk when running in windows & linux which resolves that.