next »

[returnONE]

Greenlight campaign live now!
Link to open the page on browser or directly on steam here:
http://manasparkgame.com/

MANA SPARK is a Dungeon Crawler/Action RPG that rely on the player's skills and strategy, since you are always under disadvantage. The enemies are always a threat because the AI not only make them smart, but make them work together.

Unique artificial intelligence that causes the monsters in the dungeon to work together. The roguelike package: procedurally generated, random items and permadeath <3 Confirm that you really love challenging games or die. Die. Die trying.

With different levels, enemies, and equipment, the player will face different problems with different tools to solve it. Another effort is developing an AI advanced enough so it feels great when you overcome each enemy. Things like a trustful path finding, group behavior to trigger group actions, and a finite state machine to design and control the decision making of each enemy.

Devlog Updates

- Feedbacks and interfaces
- Procedural levels
- Enemies collaborations and interactions
- Shooting animation and colors
- New area and visuals update
- Greenlight & Demo opening   <- New


We're two people working full time on the project, one with art and design, the other with programming and we hope this will be our debut as a team!!  

You can also follow us on twitter:
@returnONE
@doliveira87

If you find it somehow interesting, feel free to ask anything and we'll be glad to answer.

Thanks!

[lululuprimal]

Love archery, so naturally, really like this concept!!

[returnONE]

Love archery, so naturally, really like this concept!!

Great. We plan to show more about it soon.

[Bombini]

Looks great!

[bbtombo]

wow, this looks awesome!

[doliveira87]

Hey guys! I'm one of the devs. Please, also feel free to share any impressions or suggestions about the game (pm or twitter, wherever you feel more comfortable  )

[returnONE]

FEEDBACKS AND INTERFACES

LET'S UPDATE THIS THING, RIGHT??
Worked this week basically on feedbacks and some interface details

First a glimpse on the equipment collection interface. Maybe I should get a pixel art font?


Particles on walking and rolling:


Tried to show the arrow trail and particles on hitting solid things but wolf was looking for lunch:


I've being thinking of ways to give more punch on the arrow collision with enemies but failed.
It already has a nice screenshake but it surely needs more attention.
Does anyone have any suggestion?

[Ottbot]

Some blood particles when the arrow hits the wolf might be worth exploring, and/or some sort of impact effect?

[doliveira87]

Some blood particles when the arrow hits the wolf might be worth exploring, and/or some sort of impact effect?

Hey Ottbot, thank you for the suggestion!
We were thinking of avoiding a bloody visual in Mana Spark, but I agree that some particles could help with our problem. Maybe an impact effect plus some particles (more to gray/white than to something reddish) as you suggested?

What do you think, returnOne?

[redsuinit]

I hate bugs too, haha. I made a mobile game that uses arrows and the creation of the suck arrow vs, the projectile itself was a pain to get right without the arrow being bugged and at some weird rotation.

[returnONE]

Some blood particles when the arrow hits the wolf might be worth exploring, and/or some sort of impact effect?

Yeah, I wouldn't go as far as adding blood, but I'm surely looking for the right impact effect.

I hate bugs too, haha. I made a mobile game that uses arrows and the creation of the suck arrow vs, the projectile itself was a pain to get right without the arrow being bugged and at some weird rotation.

That goddamn bug is hunting us since the beginning. @doliveira87 made it be way less frequent, but it is still there.
It also happen at the walls sometimes.

[redsuinit]

Some blood particles when the arrow hits the wolf might be worth exploring, and/or some sort of impact effect?

Yeah, I wouldn't go as far as adding blood, but I'm surely looking for the right impact effect.

I hate bugs too, haha. I made a mobile game that uses arrows and the creation of the suck arrow vs, the projectile itself was a pain to get right without the arrow being bugged and at some weird rotation.

That goddamn bug is hunting us since the beginning. @doliveira87 made it be way less frequent, but it is still there.
It also happen at the walls sometimes.

What development software are you using? Unity?

[doliveira87]

Some blood particles when the arrow hits the wolf might be worth exploring, and/or some sort of impact effect?

Yeah, I wouldn't go as far as adding blood, but I'm surely looking for the right impact effect.

I hate bugs too, haha. I made a mobile game that uses arrows and the creation of the suck arrow vs, the projectile itself was a pain to get right without the arrow being bugged and at some weird rotation.

That goddamn bug is hunting us since the beginning. @doliveira87 made it be way less frequent, but it is still there.
It also happen at the walls sometimes.

What development software are you using? Unity?

We are using Unity and its embedded physics 2D (Box2D). What did you use for your game? Were you able to fix this issue?

[redsuinit]

Some blood particles when the arrow hits the wolf might be worth exploring, and/or some sort of impact effect?

Yeah, I wouldn't go as far as adding blood, but I'm surely looking for the right impact effect.

I hate bugs too, haha. I made a mobile game that uses arrows and the creation of the suck arrow vs, the projectile itself was a pain to get right without the arrow being bugged and at some weird rotation.

That goddamn bug is hunting us since the beginning. @doliveira87 made it be way less frequent, but it is still there.
It also happen at the walls sometimes.

What development software are you using? Unity?

We are using Unity and its embedded physics 2D (Box2D). What did you use for your game? Were you able to fix this issue?

I was. The issue is the fact that position is calculated by Unity in the Update() function while all OnTriggerEnter() and OnCollisionEnter() functions run off the FixedUpdate() function. So what is happeneing is that under the Update function, the projectile is still moving, while waiting for the FixedUpdate() call for the OnTrigger/OnCollision function to run. Thus when the OnTrigger/OnCollision functions run, the projectile has moved one addition frame!

What I did:

Ran all of my arrow collisions/triggers off of the raycast function and adjusted the raycast length, until I got the desired result. In your case your arrow is always moving in a straight line, so my recommendation would be to create a ray-cast that extends directly in front of your arrow, and once the ray-cast confirms a hit, instantiate the object then. RayCast also runs off the physics engine, so you will most likely need to play with the length of the raycast in order to get the arrow  instantiate at the right time. Then, delete your collider and let the raycast do ALL of the work for the arrow. Unless there is some other reason to have the collide that I can't see from your gifs and gameplay.

[doliveira87]

I was. The issue is the fact that position is calculated by Unity in the Update() function while all OnTriggerEnter() and OnCollisionEnter() functions run off the FixedUpdate() function. So what is happeneing is that under the Update function, the projectile is still moving, while waiting for the FixedUpdate() call for the OnTrigger/OnCollision function to run. Thus when the OnTrigger/OnCollision functions run, the projectile has moved one addition frame!

What I did:

Ran all of my arrow collisions/triggers off of the raycast function and adjusted the raycast length, until I got the desired result. In your case your arrow is always moving in a straight line, so my recommendation would be to create a ray-cast that extends directly in front of your arrow, and once the ray-cast confirms a hit, instantiate the object then. RayCast also runs off the physics engine, so you will most likely need to play with the length of the raycast in order to get the arrow  instantiate at the right time. Then, delete your collider and let the raycast do ALL of the work for the arrow. Unless there is some other reason to have the collide that I can't see from your gifs and gameplay.

Hmmm, I tried to use raycasts instead of colliders some weeks ago, but I didn't get anything different from it. But probably I didn't play enough with the values (it was more like "It's done. Let's try. Didn't work. Rollback" hahaha). I appreciate your suggestion and I will give it a try.

Thanks! 

[redsuinit]

I was. The issue is the fact that position is calculated by Unity in the Update() function while all OnTriggerEnter() and OnCollisionEnter() functions run off the FixedUpdate() function. So what is happeneing is that under the Update function, the projectile is still moving, while waiting for the FixedUpdate() call for the OnTrigger/OnCollision function to run. Thus when the OnTrigger/OnCollision functions run, the projectile has moved one addition frame!

What I did:

Ran all of my arrow collisions/triggers off of the raycast function and adjusted the raycast length, until I got the desired result. In your case your arrow is always moving in a straight line, so my recommendation would be to create a ray-cast that extends directly in front of your arrow, and once the ray-cast confirms a hit, instantiate the object then. RayCast also runs off the physics engine, so you will most likely need to play with the length of the raycast in order to get the arrow  instantiate at the right time. Then, delete your collider and let the raycast do ALL of the work for the arrow. Unless there is some other reason to have the collide that I can't see from your gifs and gameplay.

Hmmm, I tried to use raycasts instead of colliders some weeks ago, but I didn't get anything different from it. But probably I didn't play enough with the values (it was more like "It's done. Let's try. Didn't work. Rollback" hahaha). I appreciate your suggestion and I will give it a try.

Thanks! 

You are going to have to play with the values quite a bit. The only way to 100% fix this problem is if we could calculate position and rotation based on the FixedUpdate() function. I attempted to store the position and rotation at the beginnig of each FixedUpdate() call, but that led to the opposite issue, the arrow would be farther back. It is honestly a pretty big flaw that only presents itself in THIS application. Attempting to instantiate an object when it hits something while moving with high velocity.

Oh, also, one thing I FORGOT to mention. Once the raycast confirms a hit force the objects velocity to 0 before calling instantiate! Then you just need to play with the value to get it right, and delete the collider! Hope that helps!

Also, one last question, does the arrow travel at a single velocity, or does it adjust? My game had a constantly changing arrow velocity, so it was even MORE difficult. I actually had to write a function in the Update() call that determined the raycast length before issuing the raycast! Talk about a pain!

[doliveira87]

You are going to have to play with the values quite a bit. The only way to 100% fix this problem is if we could calculate position and rotation based on the FixedUpdate() function. I attempted to store the position and rotation at the beginnig of each FixedUpdate() call, but that led to the opposite issue, the arrow would be farther back. It is honestly a pretty big flaw that only presents itself in THIS application. Attempting to instantiate an object when it hits something while moving with high velocity.

Oh, also, one thing I FORGOT to mention. Once the raycast confirms a hit force the objects velocity to 0 before calling instantiate! Then you just need to play with the value to get it right, and delete the collider! Hope that helps!

Also, one last question, does the arrow travel at a single velocity, or does it adjust? My game had a constantly changing arrow velocity, so it was even MORE difficult. I actually had to write a function in the Update() call that determined the raycast length before issuing the raycast! Talk about a pain!

Got it. Bullet physics is always something hard to deal (specially when there's no way to access lower level code). At least our arrows are always in a constant velocity.
I can only imagine the size of the problem you had to solve working with non-constant velocity projectiles! Brave guy haha

[redsuinit]

Got it. Bullet physics is always something hard to deal (specially when there's no way to access lower level code). At least our arrows are always in a constant velocity.
I can only imagine the size of the problem you had to solve working with non-constant velocity projectiles! Brave guy haha

I actually majored in Mechanical Engineering in college, so I am actually pretty well equipped to handle challenges such as that. It's part of the reason why I love to do this as a hobby. I get to use my education a lot more than you might expect.

[doliveira87]

PROCEDURAL LEVELS

My turn to show some new stuff =].

This week I've being working on procedural level generation algorithms.
At first, I played a little with BSP based ones, but we found out it was not satisfactory at all (the dungeons didn't look organic).
Then I found TinyKeep's dev description of his algorithm and decided to give it a try. I was not disappointed =D.

Here's an example for a little amount of rooms:


And a shot for a bigger level:


Finally, generating a small conceptual level and then actually creating the dungeon:

(Don't be harsh about the visuals of these gifs, I'm a mere programmer =P)

I don't know if it may be useful for anyone, there are still some flaws in my implementation of this algorithm, but I'm sharing the source code with a little sample here. Feel free to use it and I hope it may be helpful!

[redsuinit]

My turn to show some new stuff =].

This week I've being working on procedural level generation algorithms.
At first, I played a little with BSP based ones, but we found out it was not satisfactory at all (the dungeons didn't look organic).
Then I found TinyKeep's dev description of his algorithm and decided to give it a try. I was not disappointed =D.

Here's an example for a little amount of rooms:


And a shot for a bigger level:


Finally, generating a small conceptual level and then actually creating the dungeon:

(Don't be harsh about the visuals of these gifs, I'm a mere programmer =P)

I don't know if it may be useful for anyone, there are still some flaws in my implementation of this algorithm, but I'm sharing the source code with a little sample here. Feel free to use it and I hope it may be helpful!

That's awesome! Well done!