Now that I’ve finally recovered a bit from a crazy sleepless weekend…
So proud to announce that our team Next_Level won the Innovation & Creativity Award at Jamchester 2017 – UK’s biggest professional game jam for our game Congruence(Yes, most people couldn’t remember/pronounce it either)!
The Next_Level team
Super honoured & humbled – cannot believe how far we got in just 48hrs! Huge, huge thanks to my amazing teammates Jeffrey Robbins, Greg Wray and Adam Westbrook for making the magic happen both visuals & code wise! It was an absolute pleasure working with you guys! Designing the world & puzzles for such a unique game was one of the most fun experiences I’ve had as a designer yet and we’re excited to keep working on it – so keep an eye out, might get a much-improved version in the coming weeks 😛
Here’s a link to our WIP quick run through the game – including showing off our unique game – phone interaction that got us the award 🙂
Wohooooo. Not long after UE4 blew my mind with its massive patch notes, Unity has been upgraded to 5.6! While I still somewhat lament the inclusion of a more elegant way to update Unity, I am very much pleased with the potential of the update. It focuses on numerous things like better lighting, improved Vulcan support, mobile performance and the video player getting a significant boost (it can now play 4k!).
However, my main area of excitement is with the 2D pipeline. There seem to have been numerous improvements to 2D games, including a more advanced collision system and the ability for particle systems to interact with 2D objects. There have also been improvements to tessellation, sprite outlines and newly introduced sorting groups for sprite clipping!
No Sorting Layer
With Sorting Layer
This is great news and both will be something I will make sure to utilize in my university project and beyond! In particular, particle systems will be a ton of fun to play around with!
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.
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.
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.
This weeks tutorial was intense. It made me remeber 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.
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 ahve 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:
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.
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
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.
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.
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.
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.