Blogs - coderchild

(Once again another somewhat technical post)

Back to FuetEngine.
After some weeks studying the posibility of developing the new game in Unity, I decided to come back to my own engine for the development of Maria Akane. Although Unity brings me the possibility of targeting several more platforms where to release the game, it lacks some things I already have with my framework, engine and tools. I’ve released 7 games using it, not counting prototypes and unreleased projects, and there are many things already done there, that I will have to implement from scratch if I wanna use Unity for a new game. In my case, using my own solution will bring me the possibility of focusing on the game itself. What a paradox!

On the other hand, releasing the game on the 3DS and also on the PC will be enough for me, as it can cover the expeses of the development of the project and maybe let me start a new one once I finish it. Okay, I’m assuming something important here: the earnings of this project will be at least the same as those of Cubit, and I think they will, since Maria Akane will be at least as good as Cubit (if not way more)… that’s the idea.

Yes, I know, the more platforms I cover the better, but anyway, I’m currently the only developer so, 2 platforms is too much work for me, and as I said, most probably more than enough.

Resolutions.
I’ve prepared the framework for the game development, and one of the things I had to deal is the resolution the game will be designed. This is, the dimensions in pixels the game will use during the development.

The most important thing here are not the dimensions themselves but the screen ratio. Nowadays, on the PC world, and also in non portable consoles, the most common aspect ratio is 16:9, and a resolution of 1920×1080 has become the standard (this is what they call: Full HD).

The fact that I’m targeting the 3DS as one of the consoles the game will run, means I have to keep in mind this device while developing the game. Imagine I start designing rooms for the game, and then I have to cut the sides of the room to make them fit into the 3DS screen. This would probably break the entire level design of the game!

Ok, so I face once again the problem of making a videogame that should fit perfectly in both, the 3DS and the PC.

In previous projects I usually worked with a screen resolution of 1600×960. This is high enough to let me publish a game in Hi Res for the PCs, in case I need, and the good thing is that just reducing everything to exactly the 25% makes the game look good on a 3DS. Ok, pixel art is something to take care, but everything else works.
This is a 5:3 aspect ratio. This means I have to introduce some bands at the sides of a 16:9 screen to make it look correctly, i.e. on the PCs. More over, as the complete height of a 1920×1080 screen is not totally filled with my 1600×960 designs, some bands should also be introduced in the top and the bottom of the image. This ends loosing many pixels: 1920-1600=320 horizontal and 1080-960 = 120 vertical, so I’m loosing about 16% of the screen horizontally and about 14% vertically.

This time, I’ve taken another approach. I will work with a screen resolution of 1800×1080 pixels. This is a 5:3 aspect ratio, and it looses only a bit of screen. Specifically, 120 pixels of the horizontal resolution (6,25%), which in my oppinion is almost unnoticeable by the Full HD users. In order to make the graphics fit into the Nintendo 3DS, I’ll have to reduce everything 4,5 times.

Room management.
This week I started working in the management of the rooms for the game.
I imagine rooms being an independent entity and, as the player can be in one and only one at a time, only one should be managed at any given moment. We don’t need the resources of other rooms in memory. This way, we split the whole world in little chunks, every chunk being one room. This has some interesting benefits:
– We can have virtually any number of rooms there. The whole world resource occupation could be bigger than the device’s memory, as we split it in little pieces with a very low memory budget.
– Load time is really fast. Rooms are loaded and unloaded on demand.

But what happens with objects that move across several rooms in the game? For instance an elevator / lifter? What happens with elements locked or unlocked when we exit from a room and enter it again, later in time? There should be a higher entity that manages this kind of information. The game World will keep these global objects, events an state.

On the other hand, I realized a system like this is very similar to the menu system I already use. The Menu Manager handles the flow from one menu page to another menu page, while the behaviour of a single page is managed by the logic behind it. There are pages really generic, which only handle transitions to other set of pages (like the options page, which brings the player to the stats, credits and setup pages) and there are pages with some specific and unique logic (like the enter player name page, which checks if the player name already exists or not and shows a message in that case). These specific menu pages are derived classes from the base class. There is also a specific object responsible of deciding which menu page needs to be created, a generic or an specific one, this is the MenuPageFactory class.

Ok, now if we change the word MenuPage by the word Room we realize, the exact same system can be used to manage the room system I had in mind for the game. More over, Ican use the event handlers in the menu system to my advantage. I can use the OnEnterPage event to setup things in a specific room before the room is presented to the player (a trigger was activated before so the player expects that a wall should be hidden once we enter the room). I can use Update to handle something that needs to be checked in the room every frame. I can use OnIdlePage to trigger something when the player stands idle in the room for a given amount of time, for intance a fairy spawning which will give full energy to the player (like the one in Maze Of Galious)…

It worked … flawlessly.

How to manage the world position?
Inside a room, we use local coordinates, but what happens when the player moves from the coordinate 1799 to the 1800? He has to enter into the room to the right, ok but with the 1800 coordinate? Nope! We have to decrease the width of a room to the X coordinate of its position.

This is easier to say than to implement. Physics can be here a problem. We’re telling the system that one object has moved from coordinate 1799 to 0 in just a frame, 1/60th of a second!

In the other hand, what happend with those objects that move across rooms we’ve talked before, like an elevator or a lifter?

(I’m thinking right now about of it, and I’m realizing that the player is one of these objects! This means, applying the same treatment to these objects will be enough! Ok, I imagine I will have to decompose the object position in 2 tuples an (i,j) room identifier, and a (x,y) vector for the position of the object inside the room)

Why don’t we use whole world coords for every room? If edition is a problem, we can just translate everything to its right place just after loading the room…

The problem here is floating point precission. I use pixels as coordinates. My character’s height is not 1.70 cm, she’s 192 units (pixels). Each room is 1800 units (1792.0 to be honest) . In world coordinates the 10th room to the right of the current one is at 18000 units. Floating point precission can be a problem here, may be not for static objects, but sure for dynamic ones like enemies, or the player itself. We’ll soon see jittering if we use those high numbers on moving object. Ok, let’s keep these position values as low as possible then…

Finally some numbers:

(where is the HUD?!?!?!)

This week I've started investigating on the controls for the game. As I'm on the preproduction stage and this could be a project developed in Unity I decided to go for one of those "ready to use" 2D platformer solutions, already found on the Unity asset store.

The one I came up featured many interesting things I surely will need for my game. For instance, variable height jumping, ladder climbing, crouching and many other interesting things if someday I need them. There were still some things I'll need to do, but surely this will save me a lot of hours of work. That was the idea, not reinventing the wheel, and just invest time where nobody else could.

On the other hand, one of the coolest things I loved from that solution was its integration with Mecanim, something I will surely use.

During this study I had to introduce some missing features to check if the overall result is something I like or not.

Things I've introduced:

- Inertialess movement in the air. Player moves as long as he holds the direction key, and once he releases it, no horizontal velocity moves the player. Only when the player starts a jump with no movement.

- Walkable floor over ladders: Player can walk over the top of a ladder, this is because in a 2D representation of a 3D scene these things happen, and player needs to walk over the top of a ladder and also be capable of moving through the ladder to the top of it.

- Ladder-only pass-throught platforms. Allow pass through only when on the ladder, but not when the player jumps and touches the ceiling of the platform.

Things don't like:

- Trying to get a perfect control is nearly impossible. Jumping and controlling the height in the air depending on the time the control is hold is really difficult, or it seems it's like in the moon, or player has only 2 options to press and one is pressing in less than 1 milisecond. The same applies to horizontal movement. Having to deal with material frictions, player mass and forces, to control how player speed behaves is a pain in the ass.

- When player falls into the corner of a platform, bounces like a rock.

- Player gets stuck many times in the corners of the platforms. Probably because of my player collider configuration, but it's the best I achieved. One large box with zero friction and 2 small spheres, one is just a trigger to know when the player is grounded, and another with normal friction. Ok, when the small sphere touches one of the platform corners then it gets stuck. Applying a big force will probably unstick the player from that place but also make unwanted movement.

- Unexpected things. Behaviour not expected, for instance when player fail to jump to the next platform, falls, and just slides down agaisnt a wall, but the next time player also fails the jump but touches a corner, and then bounces like a rock. May be this can be cool for a ball or the Indiana Jones Big Rock Sphere but not for the player.

Control is a key part in any platformer game or in any game where movement is important. Level design is built around it, and the space of things achievable depend on them. In order to keep the player focused on the game experience, they should respond to the player intentions. And last but not least, even if I find my perfect controls, many players will complain about them, so imagine if before they play the game I already know they were far from perfect.

I haven't still took a decision on what way should I go but most probably I will try to use one controllers I used on my previous games and adapt it to my new needs.

Note: This writting will be very summarized. It's just a dev log.

One of the things I'm studying the development of my next game using Unity, is because I expect I can use some cool features not implemented in my engine. One of the things I'm looking for is a cool way of managing lighting even for a 2D game.

I want to check normal mapping, dynamic lighting and lightmapping and see if this can create a colorful and rich player experience.

On the other hand, I'm studying this possible workflow just to know how level edition can be performed, and also start guessing room dimensions and those things for the new game.

A good thing about Unity is we can make prefabs of tiles. This way, we can create a tile like a quad, build the room, and later change the tile properties which will propagate among all the prefab instances. In this case, I changed a quad to a cube just to check how will look the game with some perspective.

Still having to decide how many vertical levels will have every room. It strictly depends on the size of the character we want and the fact that I don't want to do a scrolling through the room. All the room should be visible at the same time because this improves the player orientation in the whole level: this room is below that, and to the right of this one... I don't discard performing scroll in rooms, but it will have to be selected in player preferences or something similar.

Regarding to shadows, I have to still decide the method to use. I tried Unity Projectors one in each light and following the player, but I don't like the results because it introduces really ugly artifacts.

NOTE:
- Expect a post somewhat technical. Please, if you're not interested on game development you could just skip/miss it
- As this post doesn't pretend to be a neither tutorial nor a paper, it's is very summarized. If I had to write a novel every time I write a post, then I'll had no time to develop the game :\ apologies!

This week I started studying the workflow for my new project Maria Akane, if I had to develop de game using Unity.

In my previous projects I've been using my own Engine "FuetEngine" and all their tools. So the task is guessing the tools which will substitute the FuetEngine ones, starting by the ones which I'll use to do animations.

This will test the viability of setting up and animating the 2D characters using Blender. Note I'm not a Blender expert. Hopefully some of the problems I found can be solved by someone else.

For skeletal cut-out animation, the setup is really tedious. For every part of the body, we have to create its quad, and give the exact size in pixels (or something proportional) manually.

We create a group (Empty object where it will be parented) which will allow us to put several sprites linked to a bone.
For every sprite, we have to create a new empty object to setup the pivot or rotation / scale point for this sprite.

For every sprite, we have to create a new material, and for every material a texture. We have to setup properly the material and texture parameters to handle correctly alpha, diffuse and removing specular.

We have also to perform an unwrap, and set the proper texture for every element.

You can try to place the sprites in its exact position, to check everything is being done properly, but this we'll later lose this setup.

Once we have all the parts setup, it's time to setup the armature. We setup it by hand, placing the bone tips, tails or heads in its proper place.

For every parent object (parent empty object of all the object of a body part, for instance the head), we have to add a constraint modifier of type ChildOf. Its target will be the armature and we'll have to setup the proper linked bone (for instance the head bone).

Most probably, we'll lose the position and orientation setup in previous steps. We reset the position to 0, and we setup the orientation manually. If it looks good, then it's ok. We'll have to rely on this.

This will be the the approximate result, although in this case, all the bones have the armature as parent, and this is not the most appropriate result, if we want to associate this to a humanoid avatar in Unity.

We need to take special care with the names of the materials. When we import the mesh in Unity, the materials will be created automatically if there exists a folder called Textures in the same folder of the .blend file, and all the textures our model uses need to be there in order to make the import process work properly.

In the other hand, we'll have to edit all the materials one by one, because:

- By default they are diffuse and we need them to be transparent->Diffuse
- Because their intensity it's not 100% and then they look grayish, even if you setup the intensity to 100% in Blender.
- At this moment we can animate our character from Blender using bones. Please note, there is no need of bones to make an animation of this kind, as we can directly make a hierarchy using all the parts already defined, for instance: arm is parent of the fore arm, which is parent of the hand, etc...

The use of bones is more necessary if we want to use rigging and skinning which can be done with this setup.

With the animations ready, we can go to Unity and take profit of the tools and features for conventional animations. Specifically, we can use Mecanim, use the Unity event system in combination with our animations, use blend trees, animation blending between Mecanim states, and everyhing else.

After many attempts to achieve a humanoid avatar bone structure in Unity, I desist and opt for the "generic animation" system, as Mecanim and its main features work.

It would be great if after creating a humanoid avatar it's possible to take profit of other animation sources, but I'm not 100% sure if this is possible. So we'll have to create our own animations from scratch.

Hi!
After Zombie Incident, I’m starting a new project. This time it seems it will be a more ambitious and longer project. Let’s see what happens : )

The project is called “Maria Akane”, which is the name of the old Nippon Underworld protagonist.

Maria Akane is a combination of action gameplays where everything spins around a maze. There Maria Akane will have to investigate room by room to find the entrances of the levels where some action gameplay will take place. Once the level is finished an exit to a new place in the maze will be opened.

Some of the levels will be those found on Nippon Underworld Forums.tigsource.com. This means Nippon Underworld won’t be developed anymore(amen), and closes a cycle I’ve been carrying for 2 years.

I will try to keep a brief weekly devlog about the things I’ve been doing along the week. That’s the theory, let’s see this in practice :D

And that’s it, now the first devlog entry is going to be written.
See ya!