POSTMORTEM
Alrighty, the Jam is over, time to take a look back and see how things went, but first, since my game is HTC Vive only and therefore not many people will be able to check it out, here's a trailer and a gameplay video, just to give some context about what this postmortem is about
What Went Well
- Concept - although as I stated at the start of this worklog this concept was not entirely my own creation, but more of an adaptation of an already existing concept to the medium which is Virtual Reality, I am still very proud of it, creating and played this rough prototype did nothing but confirm my initial hypothesis about how such a concept would well work in this medium and offer an enjoyable experience to the player
- Scope - my hope was to be able to create a first basic prototype of the game to build onto, unfortunately trying to build it in an engine I never used before resulted in a longer development time that I had wished for, however by being farsighted and scoping properly at the start of the project, I was able to still deliver a product containing the core experience
- HTC Vive - I was very pleased with how easily I was able to work with the HTC Vive, granted I had been working in Amazon Lumberyard and CryEngine, and both engines had native HTC Vive support (really out-of-the-box for Lumberyard, in CryEngine it was slightly trickier getting it to work properly), if I had to actually write code myself to add HTC Vive support to my game that would have been a very different scenario, but as a technical designer I only aim to gain enough knowledge to be able to prototype my own games without a programmer holding my hand, and now I achieved just that for the Vive
- Flow Graph - working with CryEngine I realised, while Blueprints in Unreal were created to offer a developer all he needed to create a full game experience, Flow Graph in CryEngine is simply aimed to allow you to make quick interactible elements and gameplay events, with the intention that bigger features such as main game mechanics should be written in C++, which I can understand as it is know visual scripting is very inefficient performance wise, however for this jam I wanted to create something quickly, so I avoided getting into C++ programming, and despite encountering several issues I had to find hacky solutions to, I achieved my goal of developing the experience I intended, entirely using Flow Graph
What Went Wrong
- Amazon Lumberyard - let me get this straight, I do not mean to say that Lumberyard is a bad engine, actually Lumberyard seems very promising, they have a lot of cool features, and Amazon has shown an incredible amount of effort into this engine, I do not want by any means, try to demolish all their effort just because I had a bad experience with what is just a beta release of the engine they are putting so much heart into, however this postmortem would be incomplete if I did not talk about this experience, so here we go, when I started Amazon Lumberyard looked VERY promising, much more than CryEngine would when I started working on the latter 4 days later, Amazon Lumberyard had straightforward, out-of-the-box support for HTC Vive, and even came with a working project sample for it! And to top it all, there were tons of video tutorials, it was basically heaven, unfortunately tho, the latest version of the engine at the time (it was 1.9, currently the latest release is 1.10 already) had dropped their visual scripting tool, a.k.a. Flow Graph, in favour of the oncoming Script Canvas... which as I write has not been release yet, yes technically flow graph was still supported in the engine as a legacy element, however every time I tried to open the flow graph editor the engine crashed, yes I could have got an older version of the engine were flow graph worked properly, but if the whole point was learning a new engine, what good would do learning an already outdated scripting method? Meaning the only way you could script gameplay was in Lua, problem is, all the video tutorials I just mentioned were for Flow Graph, and in three days I was not able to find any documentation nor tutorials for Lua scripting in Lumberyard, I had two weeks to make a game, and now idea how to learn how to create this game, to put the cherry on top, when I looked into how to make a build of my game I could submit at the of this jam, I found the process to be a little bit too complicated for my taste, and even after trying it out a few times, I was never successful, I had to give up on that horse that is Lumberyard, but I will give it a new shot once it's out of beta
- UI - as I replied to Jaxcap earlier in this thread, UI is very important in my concept, much of the anxiety and therefore fear in my game is conveyed by having the player be careful with his ammunition, my initial fancy idea was to have the Vive controller in-game model shine depending on the amount of ammo left, as that would have been what I would have done if I were making this game in Unreal, I was aware that I might not have been able to recreate something I knew how to do in Unreal in a new engine such as CryEngine, but I thought worst case scenario I could resort to use some floating text to achieve the same result... last of the project, I knew I could not do the dynamic flowing, since I had major issues importing materials into Cryengine, and it was a miracle I was even able to have the default material for the controller shine in the dark, it was very likely the game would have ended up with the controller being virtually invisible, but when I started looking into doing stardard UI in Cryengine, used to Unity and Unreal I assumed it also had a nice UI tool like them, I was so wrong, it turns out to do UI in CryEngine, I needed to create in, and import it from, Adobe Flash... Adobe. Flash. I had like 15 hours left and I was supposed to learn a software I never opened before in my life, just to add a bullet counter... no need to say, the final game does not have a bullet counter (I also tried using the debug show message to print the number on screen, but it was not optimised for VR Rendering, so I removed it)
- Flow Graph & Schematycs - what are these exactly? They are visual scripting languages/systems/whatever you call them, having started as a Java programmer and then then Unity technical designer, I was once very reluctant to use visual scripting, but after one year of developing with Blueprints in Unreal, I just cannot go back- okay I can, like it was not that big of an issue typing code in Lua for the first three days when I was using Lumberyard, but overall I just find Blueprinting more organised and straightforward, granted that is not nearly as efficient, but for making prototypes I find visual scripting the better option, now from what I understand, I did not actually do any research into this, so it is just an assumption, Flow Graph was one of the first visual scripting languages to be made, later came Epic with their Blueprinting system, however unlike Crytek, Epic was more open to iterate on their visual scripting language according to users' feedback, and now Blueprinting stands high as the pinnacle of visual scripting, nowhere as precise and smooth as C++ coding, but providing everything needed to allow even the less tech savvy designer out there, to bring their concept to (digital) life... unfortunately Blueprinting also creates an expectation in what visual scripting should allow you to do, but while Blueprinting was made with the idea that you can make a full game out of it, CryEngine is less of jack of all trades, and more focused to games with big open spaces, and a mission based system, as a result Flow Graph is aimed at allowing you to create scripted gameplay events (think like "if you kill the 5 guys, the door will open" or "if you step into the room, the light will turn off"), and it just felt lacking when I tried to use it to create basic game features like shooting, however Crytek seemed to have been paying attention to what Epic has been doing, at least judging from what Schematycs look like, now I am not saying that Schematycs is gonna replace Flow Graph and is just a copy of blueprints, I actually have no idea what is going to happen, but for what I saw, Schematycs seems to be complementing Flow Graph: as I said Flow Graph is only about scripted events, basically the equivalent of the level blueprint in Unreal, except you can have more than one and- actually forget that, comparing it to Unreal would just confuse you more, but that's it, Flow Graph is just logic which can be triggered and in return affect stuff, in a relatively limited manner, for more complex interactions you will need some C++ programming, Blueprints on the other hand allows you to create game objects from scratches and give them components like meshes, physics, and so on, in CryEngine to do create a new game object you can use in your game you'd have needed to either write it in C++ or Lua, however Crytek decided to switch to a more user friendly approach, and here it comes Schematycs, a visual scripting tool which allows you to create new game objects, and give them components such as a meshes and physics, in a visual environment, it looked very promising, but as beta feature it was still sometimes buggy and could not really take advantage of it, in the end I felt however that even by using these two visual scripting tools together, they were still designed differently than Unreal Blueprints, they say you should pick an engine depending on the game you want to build, and while Unity and Unreal both try to give you the buildings blocks to create virtually any kind of game, Cryengine was my first experience were I really felt like I had been giving tools which I could use to build something, but did not really fit with what I was trying to build
- Quick Art - another goal for this Jam was for me to getting started with tools such as MagicaVoxel and Asset Forget, I did try out the former, however due to how long I spent figuring out how to solve technical problems, I just did not have the time to do anything art wise for my project, in the end I added some basic blockout shapes to the immediate area surrounding the player, as to give the player a better feeling of "this is a real place", and I justify this as I am mainly interested in improving as technical designer than as a art person, but I do wish I could have done more in this area
What I Learnt for the Future
- CryEngine V - my knowledge in CryEngine V increased drastically, 2 weeks ago I would have been lost and scared if I were presented with the interface of the CryEngine Sandbox, now I can navigate it relatively comfortably, I also learnt how to make a shareable build of the game in CryEngine
- Scripting in CryEngine - I also know how to make basic and advanced scripted events through flow graph, even using game tokens, and I can detect collision (I still can't believe I only figured out how after working in the engine for 10 days straight), and I can used debug tools, I also took a look at the oncoming Schematycs system
- Importing assets in CryEngine - I can import meshes (but not materials, so far I got corrupted ones every time I tried), I can also import audio and play it using the standard SDLMixer (although probably I can still only do basic things with it, and everyone online seems to be suggesting switching to using WWise), seems promising, but as a beta it was still too buggy to use it properly for my project
- Approaching new game engines - so far I only had worked in Unity and Unreal, both "jack of all trades" engines where you are given the tools to create virtually any game you want, with Lumberyard first and CryEngine later, I discovered how that does not apply to every engine as I expected, CryEngine for example really gave me the vibe to be an engine targeted to games with big open linear levels, and dynamic scripted events, now I know that is best to look for an engine suiting your game idea, instead of trying to build an idea in an engine which does not properly support your intended gameplay, I also learnt more of the effort that goes into learning an engine, and in the future I will be able to make better estimates, as well as understanding more about why in the industry technical designers sometimes create prototypes in Unity or Unreal for games which will be then realised in more performant proprietary engines
Conclusion
Overall I think this was a good experience, I am slightly regretting my choice of learning a new engine, because I really like this concept and I think the final prototype does not show its full potential due to the development issues I had, however I can still go back to it in the future and realise a better prototype for it in an engine I am more comfortable in, so for now I am just happy I was able to pull of the challenge of developing was is both my first CryEngine, and my first HTC Vive game, in just two weeks, some moments were quite frustrating, but in the end I was able to show my determination, and feel quite happy about myself.