Game Prototyping Article 6

It has been a while since my last post but I am proud to announce that I have finally finished the roguelike2D tutorial! Unfortunately, after a lot of consideration, I decided not to make a game in that style and instead make a bullet-hell shooter style game. There are still some tips I learned from this tutorial that will be invaluable to me when making my submission and beyond.

cropped-vlambeer-monochrome-1

Vlambeer’s logo – A flaming bear JW drew on a whim in MSPaint

My aim with this project is to emulate the kind of raw satisfaction hat come from playing Vlambeer games. Vlambeer is an odd studio for me. I find them arrogant and self-conceited and I honestly don’t like a lot of their games. Then you might be thinking – why would you even pick them as an inspiration if that is the case? The answer is simple, much like companies such as Nintendo, I don’t need to like them in order to respect them and acknowledge their strengths.

Vlambeer-Team

The duo behind Vlambeer. On the Left Rami Ismail, handling marketing, production and management. On the Righ – JW, the creative force behind the studio’s wacky games.

In the case of Vlambeer, it is what JW (Designer) calls “game feel”. He even has an amazing talk, where he showcases a prototype where he goes through steps of adding small touches to a game that make it “feel” that much more satisfying and visceral. While I believe he goes entirely too far, there is still a lot to be learnt here. Small touches like bullet spread, randomness, knock back and screen shake can entirely transform a game. That is why I have done a lot of research into the studio and have even gone as far as to requesting the library to get a copy of their book, which is already a fascinating insight into their design process, which I will reference and draw upon for my submission.

In my next post, I will show the progress I have made on my prototype and how far it has gotten. I won’t dwell too much on the design intricacies of it, as that is not only a WIP but also will be part of my submission.

Game Prototyping Article 5

This weeks tutorial was intense. It made me remember a lot of the more intermediate programming practices I knew back in high school as well as teach me a lot of new concepts.

The goal was simple  – to create a moving object script, that would serve as a foundation for all moving units in the game. Taking advantage of inheritance, the core pathfinding would be the same and each different kind of character would have their own implementation of movement. This makes the code much more scalable and cleaner.

What was interesting was some optimizations in pace, for example have an inverse of the movetime so that we multiply instead of divide, which is more efficient in terms of computing power. I also had to refresh my knowledge on inheritance, singletons, layer masks and such. It also introduced a bunch of brand new concepts, such as protected virtual functions, which can be overridden by the inheriting classes. Another useful thing was passing in generic parameters, that can be defined and flexible. This was something that I had always wondered about but never quite knew how to implement.

No images this week, because I am kicking it into high gear and focusing on getting this tutorial done so I can begin work on my own game.

Timely Thoughts – Concept

As any gamer over the years i have amassed a troubling amount of games in my backlog. As of this article the unplayed/unfinished games in my Steam library alone sit at a delightfully unnerving ~459. To solve this I have decided to combine two productive activities and I will seek to give my thoughts on and post about each game, in this way both generating regular content for the website and burning through my backlog. What could possibly go wrong.

Important to note is how I have avoided the dreaded word “review”. This is because I have yet to see a format for game scoring/reviewing that I like. Until I come up with something I will just give my overall thoughts on a product, trying not to follow the typical pattern of “classic game reviews” that is often too narrow-minded, categorized and dull to be of any use to a wildly varied interactive medium. It also fuels my false superiority complex. Woohoo. And don’t fret, the Arbitrary Game Score™ will still make an appearance.

Here are some numbers to illustrate just how bad the situation is. See that pretty banner on top of the article? Those are 56 games from my Steam library. Looks like a lot, doesn’t it? Well, with my current library size (which seems to grow every week), there are 8 more pages. Yeah… That’s not counting the 15 NDS roms, 8 Wii, 28 PS3 ,19 PS4, 13 PSP, 11 PSVita and god knows how many Android/iOS games in queue. It’s bad. it’s real bad.

Keeping the number-based reality check going, here are some images from two delightful websites.The first one being Steam Left – a service that gives you an approximate number of hours to beat all games in your library. In my case it was this:

Number_Playtime

Lovely. That’s for the bare bones main campaign completion btw.

The second website offers a more in-depth insight into how stupendously impulsive of a buyer your are. It’s called How Long To Beat Steam – and is linked to the How Long To Beat website, which offers pretty accurate community sourced playtimes – including completionist runs. The added details and accuracy make this one even scarier.

Graph_Playtime

Right, then. Seems like this’ll be a fun ride. On a positive note, at least I won’t run out of content anytime soon. Without further ado – my first ever “review” Just Cause 3

Game Prototyping Article 4

Today I finished the second part of the Level Generation in the Unity 2D Roguelike tutorial. The system works now and doesn’t look half bad! Using the algorithm from the previous post, it generates levels of increasing difficulty with progressively more and more enemies. It’ll definitely be a consideration for my own project, as a system like this could give a lot of replay value, without the need for actually designing the individual levels.

I also got a refresher on what Singletons are – and used it for the GameManager, as it is a persistent element that will be in each and every scene. I also saw how to elegantly assign all of the different sprite variations to an array – integral for rapidly working on a level generation system.

GameManager

The GameManager script that utilizes the BoardManager and is persistent throughout every level of the game. It’s initialized by the Loader script, which is part of the Main Camera.

Above: some of the generated levels with a marked difficulty 3.

Overall, a very productive tutorial and I am happy with the quick pace of it. Eager to learn more!

PS: I also upgraded to Visual Studio 2017, which for now has no discernible benefit apart from slightly better UI and build times.

Game Prototyping Article 3

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.

Scripts

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

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.

Prefabs

A bunch of prefabs, with various settings.

Layer Settings

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

Sprites

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

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.

Move_Code

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

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).

Wk1_Cube

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.

VS_2015

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

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

 

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

DOOM : Oh, how delightfully wrong I was.

It is easy to get swept up in the hype surrounding game’s announcement. In fact, seeing as how E3 is right around the corner, it seems quite apt to talk a bit about it. Often times people are left stunned by pre-rendered trailers and proof of concept demo’s running on NASA hardware and scripted to the millimeter. Then, inevitably, the actual release comes around and the end product is severely underwhelming. Whether it is a minor visual downgrade (something almost entirely unavoidable when you’re presenting your game in front of the whole world at E3 and the release is a whole year away) or, even worse, cut content or entirely different gameplay. We’ve seen it time and time again with recent broken releases. From Watch Dogs, through Unity and even games like Far Cry: Primal, a lot of things were missing, not as advertised or simply did not work. Let’s not even mention the larger fiasco’s like Colonial Marines or the latest Batman game…

That, however, isn’t the topic of today’s post. Instead, it is the complete opposite. Once in a blue moon, when the stars align and god smiles upon the just we do get a miracle. A game that had looked so bad, so utterly devoid of what made the previous titles in the series tick, so generic and bland – turns out to be amazing. That’s right, we’re talking about the new DOOM.

As anyone who knows me can tell you, I was very skeptical towards DOOM ever since the initial trailer. As the first trailer finished, I could see how hyped everyone was, meanwhile all that was in my head were a myriad of different concerns – why are there so many QTE’s, why is the character so slow, why is it all so clunky, why is it so colourless. Then more and more gameplay videos popped up and that further cemented ym stance – this was not a true DOOM game. It was neither fast nor fun enough and seemed to be completely missing the point of the series. I was disappointed beyond belief. After the different but serviceable DOOM 3, id had killed the series. With the sour taste of RAGE still in my mouth, I just decided to accept the worst and carry on with my life. Then came the open beta and I hated it. At this point there was little to no doubt in my mind that DOOM would be terrible. Silly taunts? Ugly skins? QTE’s? What is this game? What have you done to one of the grandfather’s of the genre?! Once again, I held my opinion that Shadow Warrior 2 would be more of a DOOM game than the new DOOM. After all, it was fast, silly, violent and undeniably fun – everything that old shooters stood for.

Oh, how wrong I was.

Then, the release date came. And the reviews. At the time of this rambling rant DOOM has a very respectable Metacritic of 85 on PC with a user score of 8.2 (!). Naturally, I was highly skeptical. However, as time passed more and more respected reviewers and critics that I followed were heaping praise after praise upon the game. Everyone who played it, loved it. Sure, the multiplayer was lackluster and not everyone’s cup of tea but apparently the campaign was stellar. I couldn’t believe it. So I played the game. Oh my god. What. Have. They. Done.

Everything was so perfect. The game skipped boring tutorials and exposition and thrust you straight into the action. The lore and story were there if you cared for it, but doomguy certainly didn’t and neither did most people. The game was brutal, fast and visceral. The gunplay was sublime. The movement speed had been nearly doubled since initial demonstrations. The QTE’s were faster and (almost) entirely bearable. The health system actually made sense. Weapons didn’t have to reload. The levels were sprawling, multi-level mazes that brought back memories of a time when a level wasn’t just a straight line with several side paths for collectables.

I don’t know if it was the negative press, the bad consumer reactions or what but id turned around the game. Everything that was criticized int he original showing had been removed, revamped or improved. The game was a joy to play. I hadn’t felt such unbridled joy at the realization that a game is actually good since the last Wolfenstein (which is actually frighteningly similar in terms of expected quality vs end result). In fact, I might go as far as to say that this game is better than the last Wolfenstein. The gameplay surely is. And this is coming from someone who hated the game down to its core. I think every developer should take note, since this game is one of the best examples in recent times of altering a product in accordance to palter feedback and delivering an amazing end result. Well done, id software, you proved me wrong.

As it stands, 2016’s DOOM went from one of my least anticipated and almost hated titles to one of my favourite shooters of the last 5 years. To anyone who has doubts about this game, don’t. Id have done it and I can’t wait to see where the series goes next. DOOM is back, baby.

PS: Now with Wolfenstein, Shadow Warrior and DOOM back in full force, what’s next. Hexen? A proper Duke Nukem game? Please, please, please may this bring back a revival of old-school shooters.