Introduction

UPDATE: at first I wanted to develop this game in Lumberyard, when I realised it could no be done I changed engine and the title, I am stating this to avoid creating confusion in the reader when reading the first entries

-------------------------------------------------------

Hello everyone, I am James, and as the title says I am using this Jam as an opportunity to learn a brand new engine to add to the list of engines I am very proficient now, currently featuring both Unity 3D and Unreal Engine.

Now, when learning a new engine it is good to start by trying to create something simple and small, just taking small steps while you get acquainted with how to do something you already know how to, but in a brand new engine, therefore I am building something simple and small... except I am building it in VR

Design

The game is essentially a simple survival horror:

• As the player, you are standing in a small area in complete darkness
• Enemies will spawn and move towards you from your surroundings
• You can use the Vive controller(s) to aim torchlight(s)
• The torchlight(s) will emit a light, allowing you to look at your surroundings, and spot approaching enemies
• The torchlight(s) will dim over time until turning off completely, the player can restore the light to full brightness by shooting
• Shooting will also produce a ball of light, which will act as a bullet, and destroy enemies on hit
• Shooting will be a limited resource, which can be replenished by killing enemies
• You will lose health whenever an enemy reaches you
• Losing too much health will result in a game over
• The goal of the game is to survive for as long as possible

Inspiration

My game concept is heavily inspired by Past Your Deadtime, a fellow gamejam game I've found here on Itch.io

Planning

This how I plan to approach developing a prototype for this project over two weeks time:

• On saturday I setup the project by flashing out a design, breaking it into features I can build individually, creating this planning, and getting started on technical research.
• Up until Monday I plan to be researching how to work in Amazon Lumberyard, and make small prototypes to ensure that all the features I planned can actually be built in this engine
• On tuesday I plan to create a complete First Playable Prototype, a working prototype containing all the core mechanics which are part of the experience I intend to create
• Up until the following friday I will be playtesting, tweaking, and iterating on my prototype, aiming to get it to deliver a good and engaging player experience
• Next weekend I will get started on researching and practicing with MagicaVoxel, a tool I never used before, which will allow me to create Voxel based art (think Minecraft), which I intend to use to create models for my enemies, I might also decide to research and practice how to use Asset Forge, since I could use it to create a good environment, however consider much of the game is set in darkness, environments are not a big priority, and therefore I might decide not to learn that tool as well, if I am running out of time
• The following monday I will get started on polishing, which means completing and start implementing my MagicaVoxel creations into the game (and possibly Asset Forge creations), I will also take care of visual (particles), sound, and haptic (rumbling) effects.
• By the end of Tuesday I plan to have every character model (and environment if any was made) implemented in the current build
• I plan to have polishing completed by thursday
• Finally, I reserve the last day to take care of any last minute problem, as well as to ensure the project is properly submitted

Day 3 (End) - I am migrating to CryEngine

So it is the end of day 3, and with it the end of my research period regarding the engine Amazon Lumberyard, my intention was to spend this time learning how to use the engine, and then tomorrow get down to build a first playable prototype of my game.

Research - Results

After 3 days of research and practice, all I was able to do was take one of the levels of the existing VR sample project, and add some code to spawn a ball by pressing a trigger on the controller, which will then be pushed in a certain direction.

Out of the 4 core features I planned to have in my prototype, I was only able to build 29% of the first one

And to make things even worse, after looking into it for a while, and making a few failed attempts, I came to the conclusion that, even if I were able to come to understand how to create the rest of the game, it is very possible I might not be able to create a distributable build for it to actually submit

Research - Reflection

I believe the main reason why I had such poor result, is that Lumberyard is an engine currently still in developed and released as a simple beta, there is very small amount of learning material for it, and since the engine is constantly receiving major changes, material realised even only two months ago is already outdated and was useless to me.

Research - Reaction

My intention was to use this opportunity to learn Lumberyard, as it was advertised to me as a more user friendly incarnation of the CryEngine, in order to later have an easier time learning Cryengine itself later on.

Even tho with 10 days left I might still manage to complete the game in Lumberyard, the scarce amount of learning material, together with my inability to create a distributable build of the game, creates too big of a risk for the project, I therefore plan to abandon this engine, and to migrate my project to Cryengine, which I also never used before, but that unlike Lumberyard is an officially release engine (instead of a beta), and therefore should have enough documentation and learning material to allow me to actually create a prototype in the time given, my planning as been updated to account for this.

FUN FACT: at some in the last three days I actually ended up looking up the documentation for Cryengine 3, the version of Cryengine on which Lumberyard is based, as some of that documentation is compatible with Lumberyard, I was told to referee to it since no equivalent for Lumberyard exists as of yet, I guess it ironic I ended up migrating to Cryengine completely

Day 10  - Status Update

So, it is Day 10, according to the updated road map for this jam I should be done with Art Research, unfortunately things did not proceed as smoothly as expected, let's have a status update.

In the last 7 days I researched and practiced in Cryengine, I only ventured in the two visual scripting tools provided, Flow Graph and Schematycs, purposely avoiding text based scripting in either C++ or C#, my reasoning for this is that theoretically Visual Scripting tools are made to allow designers to make quick prototypes, for a game jam they should be perfectly sufficient.

I must say I am dissatisfied, Flow Graph I understand predates Unreal Blueprinting, so it is logical that is way more limited, Schematycs on the other hand aims to complement Flow Graph, and it seems to be heavily inspired by Blueprinting, althogh it has differences which might make it even better if properly used, however it is still a beta tool, and to me it also felt limited, and sometimes very buggy, the fact that spawning a Schematyc in runtime breaks many function forced me to alterate the design of my game slightly, as a design solution turned out to be the only solution to a technical problem.

I do understand that Flow Graph is old and Schematycs still a beta, but unlike Unreal Bluprints, the systems provided in Cryengine just are not as complete, not even for a simple prototype.

Current state

Shooting: I am able to spawn bullet like object, propel them forward either using or not physics,  I am able to detect a collision (although only by having box triggers around the colliding objects), and trigger a response (I practiced turning off a blue light), however while these thing work individually, there are some bugs when I try to make them work together, to prevent issues I now plan to have bullets be always present in the scene, and switching between an active and passive state, they would stay passive in the player's hand, once triggered they would be shot forward, and once hit their target (or after a maximum movement period), they would deactivate and teleport back in the player's hand

Enemy AI: I still have to look into AI, however I am already able to move entities and detect when they are hit by a bullet, the only uncertainty is them being spawned and destroyed, since spawning Schematycs break systems, and I was not able to figure out how to destroy entites, the common solution might be just teleport them away, similarly to what happens with bullets

Shooting - Resource System: I have not looked into it, but as far as I have noticed, I should be able to be able to build it easily

Lighting System: again I have not tried this yet, but I am familiar with all components necessary to create it

Art

Pipeline: I am having some issues dealing with placeholders, so far I only dragged some assets from some of the sample projects provided by Crytek on the marketplace, however they all had issues in loading their materials and textures, which I did not look into since they were just placeholders anyways, but I now I will have to, as the engine is giving me literally thousand of warnings about that

Enemies: I would still like to build this in MagicaVoxel, however I am postponing this task for the 3rd of August

Bullets: I will probably reuse a particle effect from one of the CryEngine sample projects as the bullet

Hand(s): I will probably be using the official Vive Controller model to represent them in-game

Environment: I am not sure yet what I will be doing for the environment, considering I am running out of time with the core mechanics

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

1. 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 
2. 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
3. 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
4. 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

1. 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
2. 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)
3. 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
4. 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

1. 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 
2. 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
3. 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
4. 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.