Pixel Art Witchcrafter - RPG Puzzle Story

#21

Thank you all for your feedback! And please vote if you didn’t :smiley: @Mathias_Westerdahl, I’ll put a smartwatch version in the corner of hope of the backlog :smiley: I want to play it too, though it is not so simple, but I’ll do my best to prepare a demo, so maybe I’ll gather even more feedback from you :wink: This is a great motivation! You’re awesome! :smiley:

2 Likes

#22

thank you so much! :grinning: :+1:

1 Like

#23

Hi! :smiley:
I know some of you would kill me or themselves, when I will announce I still can’t drop any demo :smiley: But I have to admit it :confused:
tl;dr: I had many troubles with creating a correct mob’s AI, but hey, there is a juicy battle right around the corner’. :wink:

I tried many times and there where many iterations and refactors. What I would like to share with you is to remember about the scope of variables! Imagine that I wasted an enormous amount of time on finding out what’s wrong, while I was overwriting the id I made local in the script of one GO and I had multiple instances of this GO in the level. Why? I didn’t realise that, when I write

local id = nil
function init(self)
   id = go.get_id()
...
end

I actually overwrite the id that is local for all instances of this script in any new instance’s init! I know it looks stupid now and I should use self.id, but just for my convenience I used id because it was way easier to just use it in any function of the script not caring about passing self.id anywhere. Debugging it took a lot of time and I couldn’t find the cause of my problems because I was suspecting anything, but not this. I just, I had to complain. It might be useful information for someone someday :wink:

So, forgive me once again, guys :worried: Raising newborn twins, working full time in ICT, dog walking and caring about a new home with my wife is so time and brain consuming, that I’m only able to code in very short periods, often during communication :sweat_smile: That’s why I make small iterations and trying to keep code as clear as possible, while actually still learning Lua and Defold :smiley:

But to sweeten the expectancy I must share this new AI behavior with you :relaxed: Let’s checkout how a basic paw-armed mob tries to kill our protagonist! :scream:

Notice the new GUI, there is a health bar (red), xp bar (yellow) and inside the orb there is a choosen element - the size of the particle fx and icon depends on amount of Elemental Energy. There are control buttons also and the button below a fireball stands also for the Focus board, when the EE is 0. When you’ll charge it again with some element it changes for a proper spell - like fireball here. I hope you’d like it and I’m hoping for feedbacks :wink:

So another useful informations for Defold users would be to describe FSM I used to control mob and collision objects of mob used to detect, if hero enters mob’s FOV or range of attack. I used self.state and self.new_state to change only the second variable and check for an inequality between them in update function, so for every state change I can perform different tasks only at the moment of change, because I save new_state to the state there immediately.
In every state I enable or disable proper collision objects and listen to Trigger messages that are sent on collision with hero once, either at enter or exit. Or to Animation Done messages for example. Again, I perform there different tasks and state changes, so still everything is pure and readable. It is very crucial in that kind of huge project I’m working on alone, so I give special attention to refactoring and design rules.

The damage is sent to each other at the end of animation, but it will be changed when there will be animation cursor exposed, because it will, as @britzl said:

so I’m keeping your word :smile: Then I can check for a proper moment of animation to trigger attack collision :wink:

I don’t want to show anything that could discourage you and you won’t give it another chance, as we all know that the first impression is crucial :wink: As soon as I will complete at least this basic battle behavior with interactive mobs including using some magic and (most voted) buttons for spells aaand it will be tested and playable, I will post a demo :smiley: As polish studios usually says, it will be released, when it’s done :sunglasses:

Cheers!
Paweł

7 Likes

#24

your game looks so good! No pressure, but the UDGJ jam is a good opportunity to ship a first demo :stuck_out_tongue:

3 Likes

#25

Actually, I was really thinking about it :smiley: I even wanted to ask if it is acceptable, because it’s not the work of the last week, but I would like to definitely design a boss battle, that I’m lacking right now :smiley:

4 Likes

#26

Reply from the UDGJ thread.

Then I allowed users to pull up a Focus board infinite times, because I wanted you to see all the spells. Normally it would be restricted to pull out only when you burn all the energy accumulated.

Is that much of a restriction? It seems to me the player can simply waste the energy by casting spells without a target.

I was thinking about even create another restrictions that would balance the amount of the elements on the Focus board depending on the environment - for example in the freezing mountains it would be almost impossible to “focus on fire elements around you” because there will be simply a lack of fire blocks on the board. So, one solution would be to take fire (torch) with you. Or take water bottle to the desert to use water spells. What would you think about it?

This sounds amazing! I’m a fan of a water mage being almost useless on a desert, but of course you have to make sure a player doesn’t easily get himself into a nigh unwinnable situation because of the way his character is built. I’m not sure about the torch/water bottle thing. Seems like any source you’d be able to take with you should be snuffed out by any weak spell. I guess it depends on whether your magic system follows the law of conservation of energy. An amulet or something might be better for that purpose. I guess it all depends on how the balance shakes down.

2 Likes

#27

I’ve played around with the game a bit more with my niece (6 years old as of today exactly) and checked out most of the spells. Really nice effects! And destructible environment is always a plus in my book even if (or maybe especially when?) it doesn’t affect gameplay.

What I’m wondering is how is it roughly intended to play out - in this demo you basically have access to any type of spell at any time if you take the time to play with the focus board, which pauses the game. Is the plan to have the player specialize with a certain kind of spells or to be able to switch them at some predetermined places, or is switching/recharging just meant to be a lot harder eventually?

2 Likes

Unofficial Defold Game Jam #1
#28

Yes, the main reason for this is I didn’t balance the game at all. It is all just like it was feel to be ok. Then I allowed users to pull up a Focus board infinite times, because I wanted you to see all the spells. Normally it would be restricted to pull out only when you burn all the energy accumulated. Normally, as it is intended to be an RPG, Estel will learn spells one by one. I’ve already implemented something that could be perceived as an upgrade system with unlockable spells - I’m testing and developing it :wink:

I was thinking about even create another restrictions that would balance the amount of the elements on the Focus board depending on the environment - for example in the freezing mountains it would be almost impossible to “focus on fire elements around you” because there will be simply a lack of fire blocks on the board. So, one solution would be to take fire (torch) with you. Or take water bottle to the desert to use water spells. What would you think about it?
(If you want to dive in - the world is created out of elements, and witchcrafters are able to control them in the area around them, for example pushing air elements in any direction, drain water elements from wet or humid objects, etc. - a little bit crazy, but based on an old alchemy that was actually overthrown by Lavoisier so late, in 18. century!)

Destructible and interactive environment is what I want to implement so much! :smiley: I want every object to be burnable, maybe pushable or affected somehow by wind. I want to make objects wet and then freeze them. I want fire to be ceased during rain. Maybe even grow plants by watering them :smiley: But all of those are dreams, that I would eventually implement, but the release would be then in late 2080’s :stuck_out_tongue: But that’s indies privilege and that’s why indie games are awesome! :smiley:

3 Likes

Pixel Art Witchcrafter - RPG Puzzle Story
#29

Yeah, so to clarify this dev diary a litlle bit I need to update it!

There was a jam! And I posted a demo and description on itch.io as my submission! :smiley:
For more information you could follow the UDGJ#1 thread :wink:

So, you could be pretty up to date with changes I was making :slight_smile: Right after the jam, there were also introduced the great change to the engine - adding control over flipbook’s framerate and cursor allowing me to perform amazing effects I was thinking of from the beginning.

But now it’s time to refactor the quick and dirty code I wrote in a rush to create a demo to publish :stuck_out_tongue:
I analyzed LowRezAdventure by @britzl and it allowed me to create separated modules responsible for functionalities like movement, keyboard controls and animation. Now I’m working to tidy up the combat and also separate it to the module. I’m creating instances of those modules for each GO like the hero and enemies, so it’s now closer to Enitity Component System. And adding to this a Finite State Machine responsible for taking care if everything is as planned an there are no bugs where you can perform something that is forbidden at the moment, everything looks now professional and I’m glad, because I can easily now implement things, add features and find bugs. So I sincerely recommend to not reinvent the wheel and follow proven and verified patterns and solutions :wink:

To summarize a feedback from the jam, I would like to politely ask you to help me decide which solutions would be better:

Select multiple statements that you consider are true:

  • Focus board is a bad idea and slows down the pace
  • The board allows to focus on puzzles, and rest from the battle for a moment
  • The time while focusing should slow down instead of stop, to create a pressure on a player
  • Player shouldn’t be able to pull out Focus board anytime, but only when EE is 0
  • Player should be able to pull out Focus board at will, but there should be max EE restriction
  • The amount of elements gained is to high
  • The amount of elements gained is to low
  • The rules of gaining elements energy was clear enough
  • The rules were unclear and it was hard to figure it out
  • Enemies should be tougher
  • Enemies should jump to
  • The boss was too easy to overcome
  • The boss was hard to beat, I couldn’t figure out when to hit him
  • The sword was irreplaceable and I used it the most
  • I enjoyed combining spells with sword attacks
  • I would like to mainly cast magic spells

0 voters

And some more suggestions, regardless the demo, but more focused on the future of the project:

  • The best approach is to allow users choose the way to play - either sword or spell fights, and then upgrade those
  • The combination of spells are awesome (water can extinguish fire)
  • The interactive environment is great (e.g. burnable bushes), add more interaction for objects
  • The spells interactivity with each other and environment is needless
  • The hero should be more lively and climb like an assassin
  • The hero didn’t need to climb at all, let’s make a closer camera cut and make it more personal
  • The hero didn’t need to even jump at all, static gameplay could be more controlable
  • The dynamic combat is ok
  • The combat could be turn-based, so a player can focus on creating spells combinations
  • It is better to design for PC and browsers (keyboard+mouse)
  • It is more suitable for mobiles (touch control) - vertically, with two hands on screen
  • If on mobile try to allow to play both vertically and horizontally
  • It could be awesome with a pad in hand (consoles)

0 voters

If you think of any more suggestion on how to direct this game, feel free to write it down or PM me :wink:

0 Likes