February | 2017 | Stirring Storm

Game Prototyping Article 3

Posted on February 22, 2017 by Stoyan Stoyanov

This week I kept going with the Unity tutorial from the lectures. As per lecture 4, I finished the mario clone – which included learning about rudimentary AI (Enemy that follows player around) as well as working further on the different kinds of player control. It also included an enemy spawner.

Some of the expanded scripts. Note that I have kept everything in the same project, expanding on it as I went through the lectures. uIntellisense has been great with having the Unity Scripting Reference always be a click away.

Mario clone level, with AI that walks towards the pipe and walks back + player that can jump and kill it.

My biggest takeaway from this lecture was to seek beyond for more information on tutorials. As I am still uncertain of what game to make, I have decided to take a gameplay oriented approach (contrary to my typical idea-crafting approach of creating and refining on paper and not touching a game engine until I have a 25 page GDD).

To do this, I decided to work on one of Unity’s own tutorials – the 2D Roguelike game, in the hopes that while making it, I will not only learn more about Unity but also get some ideas.

A bunch of prefabs, with various settings.

An example player configuration – note the layers and tags, as well as the animations & kinematic Rigidbody2d.

Some of the sprites in action in a default project canvas (idle animations working)

Completing the first three sections taught me about how to work with the Sprite Renderer in Unity. I assigned the character animations and changed their speed. I set up everything for the different states of the player and enemies. I was taught more about layers and tags and why they are crucial for a 2D game. I also created a lot of prefabs for the floor and item tiles that will be used to create the game.

All in all, it was a highly productive tutorial and though I don’t appreciate having to pause constantly on the videos, the quickened pace means that I should be done with this game tutorial in only 3-4 sessions, allowing me to begin building something of my own.

The tutorial itself can be found here.

Game Prototyping Article 2

Posted on February 13, 2017 by Stoyan Stoyanov

This week I did the second tutorial. It went over how to add character controls to an object. The implementation in the tutorial meant that a force was applied to the cube(player) and this is how we moved it. This mean that there was some delay in controlling it, due to the necessity for force to build up. It did, however, mean that there was inertia and it did behave more like an object being pushed around than a character.

Thankfully the uIntellisense plugin means that I can open up the Scripting Reference within VS2015 at any time. Here my adaptation of the practices from the Move example can be seen. It was mostly cleaning up the structure and use of the Vector3. This way I have a cleaner code layout and the effect I am looking for (rigid body movement)

We did have a look at Unity’s Character Controller implementation and while that is excellent for a game that requires precise controls (most games), when I tested it out it felt like the cube being knocked about was way more fun, so instead I merged the knowledge gained from the two tutorials. This way I had a cube that could move in all directions and “jump” but still had that fun and bouncy collision and inertia. Also did a bunch of testing with regards to what sort of balance of force made it the most fun.

This made me think of making a game that takes advantage of Unity’s in-built physics simulation, as even knocking a single cube into other objects was pretty fun. I’ll have to think about it more.

Game Prototyping Article 1

Posted on February 6, 2017 by Stoyan Stoyanov

This is the first post for my Game Prototyping module (DES304). I have admittedly slacked off and now only have two months until the project deadline. The aim is to have documentation and a working prototype for a game in Unity. To achieve this I will be aiming to do tutorials and an associated blog article every Friday until 2 weeks before submission. Thankfully, I have had experience with programming and have done some small prototypes in Unity as well as some scripting, so hopefully coming to grips with Unity 5.x and creating stuff in it won’t be too difficult. However, it must be mentioned that my last prototype was done almost 2 years ago and I have also had no programming practice since then. This, combined with the limited time frame, along with other courseworks, a job and personal projects/jams/competitions means that I will have to work double time.

On to the prototype itself. In the first week we got taught the basics of the Unity editor as well as some simple scripting to move a cube around. What I liked about it that it showed an alternate clever way to implement recognizing inputs that lets Unity handle figuring out what kind of input device it is. If this really works as efficiently as it seems, it really is a clever way of coding your game to be (as close as it can be to) input device independent. For now, all the cube does is move left and right according to user input. I do like that it was immediately pointed out to use Delta Time in order to make actions framerate independent. This gives me a lot of faith in the tutor and the course, especially considering that some games made in 2017 still haven’t figured this out… (Hell, even the Dark Souls/Demon’s Souls games suffered from this).

Week 1 tutorial – moving a cube left and right using a Vector3 and Input device- independent controls. Not a bad start.

In terms of ideas for what my game will be… Hmm… I did always want to expand on an idea for a Vlambeer-inspired space invaders action game. However, that is 2D and while it is very focused on delivering a satisfying experience I am somewhat afraid that it will be slammed for being iterative, as the description notes that games should ideally do something “different”. I have a feeling that some weird hipster janky mess of a game would still score higher based on creativity alone. There is still a high likelihood of me sticking to my idea and simply thinking of how to expand it in creative ways… Especially since I love the concept of game feel and making something very satisfying and tactile to play.

Alternate game ideas that I’ve had include making a 2.5D combat platformer with waves of enemies coming in and a very simple rock-paper-scissors combat style mechanic using shields, swords etc.

My other idea is to simply make a mobile game where you are the god of wind and you need to maneuver a little woodland spirit by blowing gusts of wind with your fingers and going through different paths with obstacles.

Which one I stick with in the end will entirely depend on which one inspires me to work the most and also how much time I have. because some of these a re far more feasible than others, given my limited artistic proficiency and all my other side projects.

My VS2015 setup – sleek, dark and efficient

The good thing is that I have updated my setup so I have the latest Unity version, two monitors working (for optimal tutorial viewing) and have setup VS2015 (I don’t fancy MonoDevelop as much) with the uIntellisense plugin, which gives me the full scripting reference built-in.

Global Game Jam 2017 – SubEscape

Posted on February 1, 2017 by Stoyan Stoyanov

The Jam

The first dev entry of my revived 2017 website will be nothing less than our team submission for Global Game Jam 2017. It’s supposed to be the world’s biggest game jam event with over 36,000 jammers in 702 sites this year, so a pretty suitable choice for a first-ever game jam experience. The location I picked was Dundee Makerspace which overall provided a fairly convenient place with plenty of space for our VIVE setup, though the internet left something to be desired. Next year I’m probably going to stick with the Abertay University location. The jam itself lasted from Friday 18 till Sunday 18:00, with games revolving around a single word – in 2017’s case “Waves”. There are also some “optional modifiers” that people can aim for that are supposed to make it harder and more interesting for veteran jammers but we (thankfully) chose to avoid them.

The Team

Our chosen team name

The team itself

My team consisted of Michael Greenard, who handled pretty much all the code and had to work two sleepless nights. His heroic efforts will be remembered. Matthew Aitchison who was responsible for the vast majority of the 3D assets in our not-so-intelligently chosen realistic VR art style. Paul Drauz-Brown, who did all of the game’s audio and also had a sleepless streak fighting against UE4 and wwise integration. George Rankin who helped a lot with the design of the game and levels, along with me, Michael and the rest of us (no space for a dedicated designer in these small teams) and also spent the better part of a day obsessing over making a nice door. It did end up a pretty nice door, though. And, lastly, me helping out wherever I could, mainly with design and 3D assets, with some particle work.

The Concept

We took the word waves and… well, to be perfectly honest, I feel like we lost our way a bit with regards to integrating it into our game. We had a lot of ideas about how it could fit in. The concept was simple – a VR Escape The Room style game in a submarine. We had ideas of going deeper into the submarine leading to madness, with waves of distortion. We had ideas of mysterious entities zip[ping by outside the sub. We had ideas of having a “pulse” mechanic – similar to scanning waves in sci-fi games. Sonar. Brain waves. Etc. etc.

The Execution

In the end, as it usually happens, we had to drastically scope down and ended up with having blinking alert lights, creating waves of red light that briefly illuminate your environment as you try and move from room to room before the water gets to you. The puzzles were mostly authored by George, me and Michael, though it was in general a collaborative effort in terms of design. We kept it fairly simply, eliminating a lot of our more extravagant ideas outright (like mine and George’s wacky torpedo-launching puzzle), mostly due to time constraints, programming complexity and the fact that we stupidly chose to go with a very realistic art style, meaning that asset creation was very slow.

Personally, the most I got out of the project was working within such small time constraints, which relally helped me learn how to optimize my workflow. Unfortunately, I wasn’t familiar enough with using UE4 in a VR environment to meaningfully help with coding and seeing as design was shared between multiple people, I chose to focus on 3D assets and particles. The 3D assets in particular were very interesting to me as our artist was using Quixel Suite 2. One quick glance at its smart material system and I was hooked. Even though I am very far from a 3D artists, I quickly dusted off Maya and went back into it after a 1yr+ hiatus. Though it took me a while to get back to speed and I essentially impulse bought and learned Quixel Suite 2 in several hours, by the end I got into a decent groove and made some pretty decent assets. I’m definitely very eager to use it more and would definitely recommend it to anyone interested, it is an incredible piece of software and simply works within Photoshop.

You can find it here

My biggest struggles were working with a brand new team, comprised of people I didn’t know/barely knew, working within such tight time constraints and with minimal sleep and also making sure I had something to contribute to the team. I definitely felt quite bad at the beginning as, after my design contributions, I was tasked with some assets. They took me an insanely long amount of time, most of which was spent remembering the proper pipeline for importing UE4 assets (curse the damn legacy FBX exporter and Maya 2017 defaulting to some completely incompatible version – as well as the in-built “send to xxx” functionality being broken.) and also how to properly combine, unwrap and generally triangulate. Worse still, my very first asset (which was horrendously broken in its first iterations) was a crucial component of the first puzzle – namely the valve that the player needs to find and attach to the first door, in order to proceed. Inefficient modelling, improper mesh combination, bad UV’s, wonky pivot, scaling and orientation – it had it all. Overcoming the shame of it, fixing it and then getting into it more did help me create some semi-decent stuff by the end.

In my desire to help further I also made the game logo and splash (featured at the top of the page), wrote the game submission and made the game trailer. Will definitely work on my After Effects/Vegas skills more in the future, as it is incredibly useful to have in this day and age. I also spent a decent chunk of time looking into Cascade – UE4’s particle system. It’s an archaic mess at first glance, but works very well within its own dated logic. It was admittedly a bit of a shock the first time I saw it – I felt like I was warped back into UDK. Decent documentation and some excellent tutorials helped me somewhat begin to understand it. In the end I made some pretty nice particle effects that sadly couldn’t make it into the final project as we ran out of time. That was mostly since Git completely failed on us as soon as the file sizes got bloated and for the latter half of the project we essentially had only one PC with an up-to-date game version.

Overall, it was an invaluable learning experience and one that I am eager to repeat, though for my next jam I will look more into my own skill set, so that I am better prepared as remembering and figuring out stuff all over again is simply time wasted. Time that the team doesn’t have.

The Result

It’s not the best game in the world and it won’t win any awards but for my first game jam I am quite proud. A VR game with a realistic art style and bloated scope is far from the easiest thing to pull off in such a short time with an amateur team but we gave it our best shot. In the words of one of our team members – it’s better than a lot of VR stuff actually out there on Steam right now. Though that might speak more about the state of the industry and valve’s standards that it does of our aptitude. A special shout out to Michael, our programmer and Matthew, our 3D artist for doing the majority of the work.

Relevant Files

SubEscape Video Demonstration

Game File Repository

Global Game Jam 2017 – Sub Escape Page