FMP 23 - Evaluating the Project

In this final post I will just semi-quickly go through my thoughts about the project I handed in.


I stated in my design folder that I wanted to have a completed first chapter of the game, and while the definition of chapter is definitely vague, I initially thought I would have a longer demo - as per the previous post, there is a very good reason for that. All the corner-stones have been lain now, which means that actually adding to the project will be a breeze - I definitely think it is possible to double the length of the demo in less than a day for example; the only thing that will take time now is asset-creation.


I am really pleased with the different scripts, and seeing them work together is always a joy (not so much a joy when you get an obscure error you cannot fix).

Regarding the characters, I had initially planned to create them in the same style (with sprites) as my previous game, but that could not work with a non-orthographic camera. Creating them in my own way, with a series of two-faced quads, was a lot of trouble, but it definitely taught me a lot about the best way to go about it - I am now almost 100% sure that the characters in Paper Mario are indeed frame-to-frame animated, and are drawn completely per frame, instead of stitched together. I think I will try my hand at this, at least with complex characters, which will also teach me more about traditional animation.


I am quite pleased I managed to add a little puzzle to the game - the assets themselves were quick, but again, it is just a model that can be exchanged, when the code works it works. Some of my favourite parts of Paper Mario and Monkey Island were just discovering random things because you went to look. I think I will add more little things like this, and more puzzles in general.


The enemies were a lot of fun - the coconut especially. I had initially planned for a larger presence of monkeys, and even sketched out a mean, obese Monkey King, but they did not make it in. The fact that they are sketched out and planned for makes it quicker to add though.


Lastly, regarding the world itself, I am really happy with how the different 'world-tiles' work together - it feels akin to Paper Mario to me, like exploring a jungle, and that is what I wanted.


To sum up - I like what I produced, and even though it was not as much as I had hoped for initially, it was the right choice to delay adding more stuff for increased functionality. I have no doubts that the game will expand rapidly from this point on, and with the things I learned from making this project it will be all the better.


Thanks for reading! I'll be back in some shape or form!


-Mads

Cardboard objects

One thing I'd like to show here, with 10 minutes to go, was just some of the objects I made that I don't believe I have shown yet - inspired by the textures from Paper Mario, I made some of the 3D objects with a cardboard-like texture on them. I don't think anyone but the most eagle-eyed will actually be able to see it in game, but that is partially what the blog is for!

It's a little touch, but I quite like the effect it has when you look at it.

That's all for this post!

FMP 22 - 7th September : Evaluation - Process

Now we are here, at the end of all things, I felt I should combine the last weeks process post and do a little evaluative review of the entire process I had, regarding the time-schedule and how I managed difficulties and so on. After this I will write a post about my thoughts about the project I handed in.

First of all, the entire process was a bit skewed because of my late start - which was my fault, but it is still a fact of the matter.
Besides that, I realized once I had started and were researching how to overcome certain obstacles, and especially programming-wise, that I did not want to cut corners on the project from a longevity-standpoint - as in, I created everything in order to support continued work.
For example, the dialogue and combat system, which could have been created on a case-by-case basis, are instead examples of multi-threaded programming that can be expanded as much as needed with very little work compared.

Another example - several of the characters have joints and parts which were drawn separately in order to be better for animation, even if I did not have enough time in the end to use them - but that comes later.

I managed to pick myself up and reschedule my remaining time, and even though the programming took longer than expected - in essence, because I wanted to continue working on it, it became a much more programming-oriented project than I had envisioned - I still managed to complete my list of tasks.
In the future, I believe I will allocate more time to programming, and continuously evaluate whether or not some pursuit is worth it - I spent a long time trying to make the models appear flat like paper for example, which in the end taught me a lot, but it also took away time from other things.

I did think the blog was a bit of a nuisance at times, but I do think I will continue blogging in some shape or form - maybe only if I have something I am really pleased with though.

In the end, I am decently pleased with the process - it was tough going at times.

FMP 21 - 29th August

Regarding the playable character, I have yet to produce something I am completely happy with, and if I am honest, I doubt I will in this time-frame - he's starting to look decent enough, but in the final stretch here, imagination and creativity fails me.

As it looks now, I'm eally glad I had a buffer period here at the end!

This week was for producing more graphical doodads like trees and textures to populate the areas with, and here are some screenshots of that:

 

 It's starting to look up I think (as well it should, there's a week till hand in)!

 Level design is never really done, you can always tweak and alter things to be a little better. I've been looking a lot at the earlier Paper Mario games to try to research how they made their scenes work, and how full of graphical objects they were.

I recently read an article on Gamasutra about level design and telling stories through the level, without dialogue or exposition, and while a demo like mine has next to no relevant story, I have added a single piece which I hope to enhance upon further in the future versions, and get a sense of mystery to this island.

Till next!

Source:

http://www.gamasutra.com/blogs/DanTaylor/20130929/196791/Ten_Principles_of_Good_Level_Design_Part_1.php

 

FMP 20 - 22nd August

Done with the 'Forefront'-posts for now, I have been able to focus a bit more on the game, though it did bite into it a bit anyway.

I spent some time finishing up the event-system (and by 'event', I mean a little cut-scene of sorts) - it's a little bit messy, but I cannot see how else to make it without having an obscene number of scripts or script-to-script interaction. It is definitely possible to add more events to it, but if that gets too messy then I can just make a new script for that scene and so on - the ground-functions are there, and it works, so.

I spent the last of the week researching- and drawing different versions of the players partner for the game - where did they meet, how (which is why I planned the event-system for here), and of course, what would the character look like.

I like the Paper-Mario approach of none of the partners being human, so, beyond the Parrot-partner you get in this demo, I also had plans for a type of sophisticated Monkey, maybe a stowaway Sea-rat, an ensorcelled Cannon maybe even - stuff like that.
For this version, only the Parrot will be included - simply because there needs to be a reason and a story behind why the characters are introduced, and that does not take place in this demo.

One thing I haven't really talked about yet, is the difference in dialogue between Paper Mario and Curse of Monkey Island, example. In Monkey Island, the main character, Guybrush, and his interactions and dialogue with different characters is one of the main parts of the game, and all of the dialogue is recorded by actors. In contrast, in Paper Mario, Mario doesn't say a thing (he sometimes shakes his head and stuff like that) - instead, all of the dialogue is handled by the partners. This makes sense in the Mario-games-universe, because Mario never actually has lines, and it is a cool approach, because it means the player can put themselves in Marios stead more easily.

For this demo I have planned for the partner to handle the speaking, but I have yet to decide if the main character will talk in future versions of the game.

Till next!

Forefront 10 - Animation and Unity

The topic I want to discuss today is simply animation itself, with a focus on classical, 2D animation.
The fact of the matter is that most indie-games are 2D - making games in 3D might require skills beyond what small teams can provide, and it is also extremely timeconsuming. Furthermore, as triple-A games frequently have dozens upon dozens of people working on them, every artist is very specialized, and a master of his or her craft. With 2D, anyone who can draw can pretty much draw both backgrounds, spell effects, characters, icons and so on.
Because most indie-games are 2D, they are also animated thereafter, and so I will have a look at some of the classical principles, and how they apply to other projects and my own, and top off with a few examples of different styles of animation.

(Note: my go-to book is The Animator's Survival Kit, and I am not allowed to post pictures from it, so this might have fewer pictures than I would like)

Many 2D games, and pretty much all of 'pixel-art' 2D games, use frame-to-frame animation. This means that every frame in every animation is drawn separately, then stitched together. This affords the animator the use of all of the traditional Disney principles, like squash and stretch and exaggeration (note that some of the principles are to do with staging - for obvious reasons those cannot be controlled by the animator when someone is actually playing the game) - for the frame needed, the animator simply elongates or exaggerates what is needed, and the effect is palpable, as thousands of traditionally animated works can attest.
In my game however, those two principles are not applicable (which is why I am discussing them). My project is based on Paper Mario, and more context-specific, on paper cut-out animation, that is, every joint is a separate piece, which is the rotated - think smooth stopmotion animaton.
While it is definitely possible to use the scale-parameter in Unity during an animation, this will often prove to be woefully inaccurate. An alternative approach
I chose this form of animation because I wanted the game emulate the Paper Mario style, and because it is much much faster. Additionally, and I like this point, the different joints can be update graphically, and this will, if done correctly, transfer into the Unity animations, and so the look of the model can be changed even after the animations are done - this is nigh impossible with frame-to-frame (I certainly have no idea on how to do it), and when you are a learning artist, this is a golden opportunity to iterate on characters.
One way to achieve the mentioned 2 principles is to include alternative joints, which you then 'swap out' with the original when needed, but this conflicts with the points made in the previous paragraph.

Looking at a series like Paper Mario, it can appear to use both frame-to-frame, and joint-rotation animation (Forward Kinematics). The 'Idle' animation in Colour Splash for example, for both Mario and other characters, appears to be a simple loop between 2 different frames - not really animated at all, really, but this fits with the paper-craft style of that particular game.
In my own game, which has edged away from this style, I have created several joint keyframes (for as many as 120 frames per animation) and then allowed Unity to interpolate between them with its Animation editor.
One problem with this approach that I cannot envision a solution for is how grounded the animation feels - with frame to frame, each leg is simply draw on the ground, but with frame rotation, as the upper leg, lower leg and foot joints all rotate together, getting the foot to feel like it actually impacts with the ground is exceptionally tricky.
For this reason I may opt to change to normal frame-to-frame later if I improve sufficiently as an artist, and if and when I am completely happy with the design of all my characters... most likely not.

To include it in this context, Curse of Monkey Island uses a large number of traditional frame-to-frame animations.

One really interesting new project on the 2D animation game scene is the game Cuphead, by studio MDHR.

Trailer from E3 can be viewed here:
https://www.youtube.com/watch?v=4TjUPXAn2Rg

Cuphead uses a design and animation style similar to the old Fleischer Studios cartoons of the 30's - it's brilliant, bonkers, and quite a visual treat to behold.

Returning to Unity for the final stretch of this post (this turned out longer than I had thought), I will briefly talk about external animation programs for 2D animation, like Spriter, and Spline for example. These engines greatly increase the options and speed with which animations can be created, and they also support such things as distorting meshes, bones, and Inverse Kinematics - meaning, amongst others, that the model can finally feel grounded! I am fairly sure the animations can be transported into Unity as well, with the only downside being that they aren't free.
Animation packages can also be purchases on the Unity Asset store, such as Puppet 2D (https://www.assetstore.unity3d.com/en/#!/content/14024)

I think that's all I had to say on this subject!

Note that while the assignment brief says we need at least 10 blogposts, and while I hope to include more, this all depends on how the next couple of weeks are going to go - having less time than planned hasn't helped.


Sources:
Spriter from BrashMonkey. 2016. Spriter Features | Spriter from BrashMonkey. [ONLINE] Available at: https://brashmonkey.com/spriter-features/. [Accessed 03 September 2016].

Spine: 2D skeletal animation for games. 2016. Spine: 2D skeletal animation for games. [ONLINE] Available at: https://esotericsoftware.com/. [Accessed 03 September 2016].

Principles of Animation. 2016. Principles of Animation. [ONLINE] Available at: http://minyos.its.rmit.edu.au/aim/a_notes/anim_principles.html. [Accessed 03 September 2016].

 Cuphead - in Don't Deal with the Devil. 2016. Cuphead - in Don't Deal with the Devil. [ONLINE] Available at: http://cupheadgame.com/. [Accessed 03 September 2016].

FMP 19 - 15th August

So I figured out what was wrong; instead of writing String.Split(" ",[0]), I should have written String.Split(" "[0])

Hard going finding that out. I have started the event-system, but it is getting quite complex indeed.
One thing I will highlight however, is how I have, when I could, refused to take the easy way out. When I used to program, I would tackle each problem head on, complete it, then move onto the next part. The problem with this approach, however, was that when constructing subsequent scripts, previous scripts might not have been crafted with those other scripts in mind, and so rewriting or altering was often necessary, time consuming, and confusing.

With this project however, I have created everything to be expanded upon - the dialogue system works with every character, and the scripts can be seamlessly changed, prolonged, or shortened, all without messing with any scripts at all. At the same time, the combat system reads and spawns enemies based on which layer they are on and what their names are - things I have not used before either.
It is a rare joy to craft something that feels like an actual working cog in a machine, and know that it will keep turning whatever you throw at it.

In related news, I am not satisfied with my pirate character, though I must have drawn half a hundred sketches by now. I will let him sit for a bit while I move on to the next issues.

Till next,