next »

[Canotico]

damn, this has changed a crazy amount since i last said anything. eye concept looks badass.

YES! The concept artist that made it is super super good :D

the changes to your boss sound really good. It makes a lot of sense that you are going to use a concept that the player should be able to understand through visual cues without a lot of trial and error.

the fists hovering over the player looks quite weird, maybe it should not stay exactly over him, but trails slightly? it should look more natural then.

the roaming eye is an interesting feature 

I think that a good game design tells players what they should do without them knowing they are being told that, if that makes sense. Its the difference between being able to figure something out because all the pieces were there and you just put them together, as opposed to figuring out because there was a text box that told you about it.

If you mean the way the fist follows the player right before attacking them, then yes, they currently snap to the player's horizontal position. At some point I have to apply some easing to the overall movement of the fists so they don't look so snappy and, as you said, unnatural. Thanks for the feedback! 

It actually made me laugh quite a lot, like I wasn't expecting that to happen at all, I was just fixing some movement issues the eye itself had haha. Would be fun tho, perhaps I'll add a little secret that lets you pop the eye out like that and kill the boss immediately

[Canotico]

Fists explode when destroyed now, because you know, more explosions equal more fun. Right? Right.

[Canotico]

Now that I've implemented the new second phase of the fight where the players have to break the chains in order to drop The Eye to the floor, it was time to also get rid of the placeholder sprites for the chains.

I made new sprites (which I think turned out really well) and also added clearer sprites for the weak link players are supossed to attack in order to break each chain.

[Canotico]

Ok, funny story, I needed to upgrade the visuals of the beam The Eye fires. And I was planning on doing that using particles because then I wouldn't have to like shape the sprite of the beam according  to the plane it was hitting. And well it wasn't a bad idea, but what was supossed to be a one evening task turned into a 3 day endeavour, let me explain why.

As I already mentioned, the reason behind using particles was because I could easily deal with the odd shapes that the beam would need to have depending on where it collided (yes I know, this is basic stuff that can be done with a little bit of code, but I felt lazy about it, and I actually think particles would give it a more "inconsistent" look that would go better with what you would expect from a lava spewing eye).

So, anyway, particles. Unity's particle systems had no support for particles colliding against 2D colliders. This was added in Unity 5.3. So I decided I would try upgrading the project, no big deal right? WRONG. Everything was great, I upgraded the assets, everything was running smoothly, but the character controller just broke. The character controller is the very foundation of ALL characters in the game, it is in charge of movement and collisions, if it's not working, nothing is. And so, I decided I would try to find a fix for the controller (I'm using this character controller in case you are wondering, it's pretty freaking good), and I couldn't. Well, let's not say that I failed, let's just say that I would've been able to fix it, but at the expense of spending precious development time on it, which was out of the question.

So, after almost 2 days of trying to fix the controller, I decided to go back to Unity 5.2. The controller was working again, and then I figured a way of emulating the behavior of particles colliding against 2D objects to achieve what I wanted. I made a small script that basically parses a given area for any 2D colliders and then creates their 3D counterparts so that any existing particle system can collide with them properly. I like the solution actually, works pretty well and it also takes into account moving objects, in case you want the script I'll be more than happy to post it here, just let me know

And so, I was finally able to make my dream particle beam:



Neat right? It works as intended, and looks cool. But... not as cool as it could.

So I did a quick research on how these kinds of beams where usually made and I changed the way the particles are blended (using soft additive blending) and BAM:



I think its cool, and hot, haha....ha 

[Canotico]

Working on changing the activation sequence of The Eye, and made it kinda blink once or something like that... The point is that the camera shakes and there are particles therefore its cool.

[Canotico]

Ok so everything is coming together now. I'm almost done with the whole fight and am about to plug in the new SFX the guys from FatBard made along with the boss theme :D.

The third and last stage of the fight is finally done, and by done I mean that there's an end to the whole thing, and it looks like this:



I've been having a lot of fun adding particle explosions and such, which I will probably have to optimize at some point because I can't just rely on so many particles without taking performance into consideration... but thats a whole other subject. Right now what's important is that the fight is almost done.

Also, I've improved the explosion of the fists to make them more consistent with the other explosion particles:



Although they still need a bit more of work, I will have to leave that improvement aside because there are more pressing matters right now: Adding the new SFX and Music, Remaking all of the UI and HUD because they are hideous, and also remake the main menu of the game. Why am I making all of this? Because I will be sending a demo of the game to Indiecade, and the deadline (at least the early one) is April 1st, so I kinda have to hurry with that

[Canotico]

I've been holding onto this for a while. The concept artist that helped me with the design for The Eye also made this totally badass illustration:

[Shackhal]

That illustration is really awesome! Also, how far are you with the other characters?

[SuperHatchGames]

That boss is superb! Love the colour palette you're using, very strong. Everything looks to be giving good feedback to the player too. I'd like to play this! Looking great

[Peace Soft]

This is really cool! Could you talk about the way the different characters' moves synergize with each other? It seems like there's a lot of room for interesting interactions.

[quantumpotato]

This is really cool! Could you talk about the way the different characters' moves synergize with each other? It seems like there's a lot of room for interesting interactions.

Yes -- and, when can I play? 

[Canotico]

That illustration is really awesome! Also, how far are you with the other characters?

Thanks! I think its absolutely amazing! As for the other characters, sadly I haven't been able to start working on them, the past few months have consisted of solely iterating the boss until it reached this "pretty decent" stage. But the other characters are surely coming soon since The Eye is almost done :D

That boss is superb! Love the colour palette you're using, very strong. Everything looks to be giving good feedback to the player too. I'd like to play this! Looking great

Thanks I'm glad you like it! I had a hard time at first with the color palette but seems like things are coming along well if you like it, so yaay!
I'm working really hard on making good design decisions to make things as clear as possible, I don't want players to be lost and not know what to do. I do think there are some important things missing but it's getting there
I want you to play it too! Just not yet... need to finish a couple of things and maybe who knows... maybe I'll publish a super alpha early build soon 

This is really cool! Could you talk about the way the different characters' moves synergize with each other? It seems like there's a lot of room for interesting interactions.

Thanks! And yeah, so the original idea of the game was to make true cooperative gameplay, where players would absolutely need eachother in order to beat their enemies. Because of this I want all characters to have many ways of interacting with other player characters and their surroundings.

I've made some kind of design rule for all the abilities the characters have, and it is that they all must have at least 2 levels of breadth. What I mean is (and I'm probably not even using the proper terms but whatever) that all skills have more than one use scenario, for instance, a damaging ability not only does damage, but also stuns enemies it hits. This makes it so that the abilities have many different interactions, which will hopefully make the gameplay rich enough for players to be creative about the way they fight, which is like the ultimate goal I have for player characters.

I don't know if you've played League of Legends, or DotA, or any kind of MOBA, but I'm gonna assume you have. The idea is that the game evokes on players that "teamwork feeling" where they execute such an amazing play with their teammates that they just wanna high-five eachother because of how awesome that was. I want casmage to cause that.

The current state of the player characters is far from my goal, as I haven't been able to pour as much hours as needed to improve their design properly. But it will happen soon since The Eye is almost done, so stay tuned!

Hope my needlessly long answer was good enough :>

Yes -- and, when can I play? 

Well... I'm making a build for Indiecade... Which is due to April 1st so.... maaaaybe I'll make that build public? Idk I'll think about it 

[quantumpotato]

Thanks for the info. Looking forward to it!

[Canotico]

Oh boy, its been a while. I've been crazy busy but I'll do a quick update on how things are going.

I "finished" The Eye and actually submitted a demo for Indiecade, so let's see how that goes. Besides that, I've been working really hard on remaking entirely the character controller script, you know, the thing that takes care of movement and collisions for characters. The one I was using was good but wasn't exactly made for Casmage, and I was running into some bugs (going through the fucking walls.... fuck) because I added things like Crushing, which weren't suppported by the script I was using so it was to be expected that it wouldn't behave properly.

Anyway, I've been working on making one from scratch that supports all the interactions that will be present in Casmage, ever. And the good thing about it is that I'm making it intirely raycast-based, meaning that the change Unity made in 5.3 related to BoxCast won't hurt the controller so I can just migrate the project to that version and use the 2D particles collisions and be happy. The End.

But in all seriousness, this will allow me to more say more confidently "It can't break" because I can actually know now what is the controller capable of based on how I made it. I'll be posting about the aproach I used for collision detection because I made it so that the same loop for collision detection also pushes characters around in case there is something pushing them.

After I'm done with this (I'm at like 95% with it) I will be reworking some other part of the game which is the Networking Engine to be able to use the new Networking stuff Unity introduced. I know I know, "why fix what isn't broken?" But hey, I've been fighting my programmer self for a long time on this, and I just neeeeeeeeed to do this because that new Networking stuff looks sooooooo sexy and seems like it will save me a lot of trouble. We'll see if I regret it in 2 weeks

[quantumpotato]

YO! I heard you were doing networking. You should DEFINITELY look up GGPO and read this Wiki page by Valve!

https://github.com/poliva/ggpo

Disclaimer - I have tried and failed to implement this in N player networking, but it is possible.

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation

What GGPO does is:

* the game knows all of the moves and they are very discrete -- when you start a punch, you usually can't cancel it into something else. (So this wouldn't work as hot for bullet hell shmupers, but works great for swinging swords)
* we are playing together and have our clocks synchronized (somehow)
* I jump on my machine (frame 0)
* Lag prevents my JUMP packet from reaching you until frame 20
* Your client is SMART and sees that my JUMP packet said "I happened on frame 0". So your client speeds up my jumping animation by 20 ticks.
* Now my character is in the same position on your screen and my screen
* So when you throw a healing item I rush to pull you away from a boss etc, we are synchronized
* Play Third Strike online PS3/360 to get a feel for it (or get the emulators running and try with a variety of games)

Ok so that's great when it's 1 on 1.

Valve's article discusses lots of players.
* Server keeps about a 1 second history of game events
* Everytime a player sends a new input, server REWINDS and REPLAYS the game events with this new information (Kind of like the Time Travel RTS http://www.achrongame.com/site/. I'm thinking you can play with how often to rewind here, maybe batch things in quarter second chunks to trade accuracy for performance
* Server (or game host) needs to be fast enough to compute all of this seamlessly.
* When it works: It means that when I throw a healing item and it hit you on my screen, the server rewinds the healing item toss.. sees that from my game state at the Frame 0 when it was thrown, it *would* have hit you.. so even though on your screen you were already out of the way, you get rolled back and healed.
* This doesn't allow client-side cheating -- the server is still authorative. Maybe it's simpler to do client side.
* It's worked quite well for Valve!

[Canotico]

YO! I heard you were doing networking. You should DEFINITELY look up GGPO and read this Wiki page by Valve!

https://github.com/poliva/ggpo

Disclaimer - I have tried and failed to implement this in N player networking, but it is possible.

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation

What GGPO does is:

* the game knows all of the moves and they are very discrete -- when you start a punch, you usually can't cancel it into something else. (So this wouldn't work as hot for bullet hell shmupers, but works great for swinging swords)
* we are playing together and have our clocks synchronized (somehow)
* I jump on my machine (frame 0)
* Lag prevents my JUMP packet from reaching you until frame 20
* Your client is SMART and sees that my JUMP packet said "I happened on frame 0". So your client speeds up my jumping animation by 20 ticks.
* Now my character is in the same position on your screen and my screen
* So when you throw a healing item I rush to pull you away from a boss etc, we are synchronized
* Play Third Strike online PS3/360 to get a feel for it (or get the emulators running and try with a variety of games)

Ok so that's great when it's 1 on 1.

Valve's article discusses lots of players.
* Server keeps about a 1 second history of game events
* Everytime a player sends a new input, server REWINDS and REPLAYS the game events with this new information (Kind of like the Time Travel RTS http://www.achrongame.com/site/. I'm thinking you can play with how often to rewind here, maybe batch things in quarter second chunks to trade accuracy for performance
* Server (or game host) needs to be fast enough to compute all of this seamlessly.
* When it works: It means that when I throw a healing item and it hit you on my screen, the server rewinds the healing item toss.. sees that from my game state at the Frame 0 when it was thrown, it *would* have hit you.. so even though on your screen you were already out of the way, you get rolled back and healed.
* This doesn't allow client-side cheating -- the server is still authorative. Maybe it's simpler to do client side.
* It's worked quite well for Valve!

Hey! Thanks a lot for the recommendation! I've actually already gone through that valve lag compensation document and I think it's awesome so thanks for reminding me it exists :D

About GGPO, I'm not entirely sure I understand the idea behind it or how would I use it when I don't have a standalone server for Casmage. I'm pretty sure there is a way to integrate it to the project but I don't think I will need to because:

I'm actually migrating all the networking code to the new Unity's networking api (UNET) and it's just absolutely beautiful.

I'm impressed by how they managed to create such a high level layer of networking that makes replication across clients so easy. Of course I'm no expert on it (yet) but I've liked it so far and I'd recommend everyone to check it out because I think it solves many issues that arise from implementing multiplayer right off the bat.

I've been rushing to do this migration as fast as possible because during this time the game itself is not moving forward, so I want it to have the lowest down time possible. I spent last weekend implementing the lobby features UNET provides and now I'm ready to get to the important part: make the fight with The Eye work for clients. Once that's done I can move on to the next boss which is gonna be pretty.... pretty cool if I say so myself.

[quantumpotato]

Oh cool, I've heard great things about UNET. It's open source:

https://bitbucket.org/Unity-Technologies/networking
https://bitbucket.org/Unity-Technologies/networking/src/c26a8146968cbd61c2017b3e49327f3d2c3996fa/Runtime/NetworkManager.cs?fileviewer=file-view-default

Re: GGPO -- it's actually designed specifically for not having a server. It was built for 1 on 1 fights on Arcade Machine emulators.

Whereas Valve's approach rolls back the action to see if your attack was valid, GGPO speeds up your position on the opponent's screen. The reasoning is that you realistically can't react to the first N frames of a jump, a punch, etc.. so it doesn't feel like you were caught off guard when a fighter's animation state is sped up from walking to Punching Frame 7.





Very first match, the blue Ken player jumps forward and kicks very close to the start. Let's call it frame 0. So a packet is sent saying "JUMP FORWARD @ Frame 0".

When the packet arrives, the Urien player is on frame 7. And the blue Ken is still on the ground. Urien's client reads the packet, sees that it happened 7 frames ago.. so it speeds up its representation of the blue Ken to be 7 frames into a JUMP FORWARD animation. Now both players are synchronized (no server required).

Does that help explain it? It sounds like your UNET is working well but I'd be happy to chat further about this if you want to discuss. EDIT: Try watching a few minutes of that video and remember, it's all online! Super smooth

[Canotico]

Oh cool, I've heard great things about UNET. It's open source:

https://bitbucket.org/Unity-Technologies/networking
https://bitbucket.org/Unity-Technologies/networking/src/c26a8146968cbd61c2017b3e49327f3d2c3996fa/Runtime/NetworkManager.cs?fileviewer=file-view-default

Re: GGPO -- it's actually designed specifically for not having a server. It was built for 1 on 1 fights on Arcade Machine emulators.

Whereas Valve's approach rolls back the action to see if your attack was valid, GGPO speeds up your position on the opponent's screen. The reasoning is that you realistically can't react to the first N frames of a jump, a punch, etc.. so it doesn't feel like you were caught off guard when a fighter's animation state is sped up from walking to Punching Frame 7.





Very first match, the blue Ken player jumps forward and kicks very close to the start. Let's call it frame 0. So a packet is sent saying "JUMP FORWARD @ Frame 0".

When the packet arrives, the Urien player is on frame 7. And the blue Ken is still on the ground. Urien's client reads the packet, sees that it happened 7 frames ago.. so it speeds up its representation of the blue Ken to be 7 frames into a JUMP FORWARD animation. Now both players are synchronized (no server required).

Does that help explain it? It sounds like your UNET is working well but I'd be happy to chat further about this if you want to discuss. EDIT: Try watching a few minutes of that video and remember, it's all online! Super smooth

Oh! Thats awesome I didn't know it was open source! that's a +10!

Anyway, GGPO seems like a very interesting solution for high fidelity replication, which is much needed in an online fighting game. Your explanation helped me get the general idea of it so thanks for taking the time to do that I really appreciate it.

However, I don't think Casmage will need such a precise solution, but I think it's pretty interesting nonetheless!

[Canotico]

O.K.

Let's see, I've finally finished migrating the networking engine for the game so that means I can finally (FINALLY) get back to work on.. you know... actual progress....

So, what will this actual progress be? Well in fact it will be the next boss. HOORAAAAY!

My intention is to make this new boss as different from The Eye as humanly possible so that the player can get a sense of how different can the fights be in the game.

So, starting from the obvious, if The Eye is in this Fire faculty place... then the next one should be.... in the.... place thats opposite to fire... that is.... water-related-location place. The water faculty.

This boss will of course be related to water then, and I'm not going to give away my idea for it just yet (I'm actually holding it up until I get the concept art :D) but let's say that it has a watery body (no surprise there, I know).

I've spent the day working on a shader that could help me achieve a nice water effect, and I've actually managed to get part of the effect I want to achieve entirely using the fragment shader, so, it's nothing amazing and in fact it looks more like a.... Jelly Shader but with time I hope it becomes a really cool looking 2D water shader.

TL;DR: I made a Jelly shader

[Shackhal]

Great to know your progress

But I have to admit that I'm waiting for new characters xD Although creating the enemies seems a good way to define the character design.