Sounds like a mixed bag at the moment. Do you think Vulkan has the potential to be a direct alternative to OpenGL? I've no idea if one or the other is easier to program for - but given the long life that OpenGL already has had - I guessing it has a much wider and accepted user base?
I might have a dabble on mine - see how it fares. Put another hour into it just now - it is a cracking game!
Vulkan is not so much an alternative to OpenGL, it's more an evolution of the API to bring it up-to-date and in line with modern hardware and architectures. Originally, Vulkan was referred to as OpenGL Next Generation (or glNext, or [wrongly] OpenGL 5) but at some point the decision was made to make a clean break to a separate entity. OpenGL will be around for a long time to come; it is an industry standard, is extensively used by businesses around the world and continues to have a lot of support. OpenGL will continue to be developed but it is very much a higher-level API (making it easier to work with for the mainstream software engineer or non-specialist programmers out there).
Vulkan is a very much different beast to OpenGL (in much the same way that DirectX12 is very different to, say, DirectX11). It's not so easy just to jump into Vulkan and write your application as it requires a much greater understanding of the hardware you are working on and experience in working safely and robustly with multi-core/threaded and asynchronous architectures. The main advantage to developers of games (and other high-performing applications) is the fact that they have a much lower-level of control. It allows the developer a much finer-grained view of the system at a level much closer to the hardware, and allows for very specific optimisations. However, this necessitates a greater amount of development effort up-front along with an increase of the complexity of the software being written. The developer is, in effect, taking over the role of the driver and writing optimised routines for their application rather than relying on a generic driver routine to do the grunt work on their behalf.
The Vulkan API is based around the asynchronous creation of command buffers over multiple threads and then the sequenced processing of those buffers to a command pipeline. This very much reflects how modern hardware works. However, with Vulkan the driver does NOT handle any of this stuff for you. The developer has to take care of thread and memory management in a much more hands-on fashion, etc. The details are beyond the scope of this discussion (and I've not looked into the API in any real depth as yet) but I do expect it to gain popularity. It's important to note that Vulkan is not just a 'graphics' thing; it's as much about general computation as it is rendering performance. Remember, as GPUs become faster and more advanced they also become more and more general purpose-like, opening up their incredible processing capabilities to more advanced use - for physics, deep learning, fluid dynamic computation, audio processing, etc. Vulkan is as much about supporting the 'compute' side of things as it is the 'rendering' aspects.
