SyntaxBomb - Indie Coders

Kids in bed during noon so I had some hours to play.
Earlier this morning I already created some simple wall elements and painted some ground textures - pretty straight forward with texture painting in Blender and a digitizer pen. Most of the textures are most probably not visible in the scenes.


I tried out "godot" and most of the time I needed to look how to achieve certain effects (eg having a background image - used a "GUI control" for this, ahh yes). Also CPU utilization is rather heavy. 20% without lights, 50% of a core with just the lights visible in the video below.
The fire pillars are _very_ low poly and the fire particles itself are simple quads which get colorized gradiently. Zoom out and it looks a bit light fire. To create the "fire light"-effect I added a simple lamp to each fire pillar, set the fire particles to "not casting shadows" (else you would see rectangular-shadows floating around all over the surrounding tiles). Then I animated/keyframed the lights color over a period of 2 seconds (intensity + color). Each fire got a script attached which randomized position in the animation during start - so they all flicker a bit "differently".


So for now I need to say: godot has some similarities to Blender (which eases the whole animation-stuff) but some pretty hefty annoyancies (movement/scale/rotation shortcuts) also gdscript ... it's like Python ... is to get used to (as it is like Python - intentation dependend ;-)). Also filesize is pretty big (25mb for the runtime).
Let's see how that develops - or not.




Godot shot:
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FjQP7jWT.png&hash=3c0b24d15af22c115fc3120bc95dd31ba688f89a)

Blender shot (including a rather messy UV layout ;-) - I started all of them as simple place holders to get used to the digitizer pen)
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F2H7lHcI.png&hash=5efc5af1dfda857204706637899036a21dd71c47)



Next steps (in some days) will be to try out how animations work: want to add some "traps" or spots at which mobs can spawn.
Most scripting is pretty "procedural" instead of the whole OOP I am used to. Also "auto completition" of the godot editor is ... non-existant if you instantiate objects ("var bla = tileWall.instance()") so if you do not know the commands you always need to google the documentations.


bye
Ron

That looks really good, Derron. Are you going to create a worklog thread or just waiting until you come up with a game name first?

Yep some good progress Derron - keep going!

Quote
so I _just need to make it addictive *shrug*

I find that a very weird statement *all* games should be addictive.  You disagree?  Why are you shrugging?  A simple or complex game - it doesn't matter!  All games should be addictive, or they're not good games!

A complex game that is no fun is far worse than a simple game that keeps you coming back for 'just one more play'.

Of course games should be addictive - but sometimes I think certain game mechanics "aren't". Especially if you play things during development you might loose some "addiction" as you eg. know how to handle enemies the right way. So you do not need to figure out how stuff works to reach perfect highscores. To avoid this you need "AI" which surprises you here and there. But a tough AI is more than just "rather complex". It is a pretty big task.


@ Qube
Feel free to moderate and put the posts about my "wip" into a new thread (maybe, call it "Competition entry: Maze Raider" and I could adjust the title later on). That would keep the thread a bit cleaner.


bye
Ron

Done :)

Thanks ;-)


Added some spike-traps this morning to try out how to handle animations. I thought of animating them in Blender but at the end placed and animated stuff in Godot then. So each spike of a trap got its own animation time line in a single "animation" (Spikes.Activate, Spikes.Deactivate).
Godot is really "string"-centered. So stuff is referenced by strings (get_node("bla/bla.tscn"), animationPlayer.queue("Spikes.Deactivate")). While this adds a lot of convenience it does not feel clever performance-wise. Think whole stuff is "scripted language-"-esque for now (no clue what happens to c# code or so as I am just trying out the gd script side for now).

Stopped my quick "place trap instead of ground tile" try as somehow the object has switched y and z axis (while it is not rotated!) and when placing the items on the 3d environment they here and there had some "y axis offset" (which should be an z-axis) so in other words it looked as if the objects were "sunken or raised" a slight bit - and this depenend on the x/y positions. Really odd and annoying moments: you always have to google for reasons and solutions and this without knowing what the right termina for the problem is.

What I like is the integrated animation stuff ... so you see how it "looks like". What I dislike there is, that when doing your "scenes" (each object is a scene and scenes can contain scenes ... so like "Prefabs" at the end) your light/environment is wrong. So all my tiles look blueish, dull instead of getting presented in a neutral color. For my fire pillar I needed to judge by the gradient I used for the fire - not by what was rendered in the scene preview (there I could only verify the animation/particle movement). When appending this scene to the level scene (which contained an world environment / lights) it looked like it was supposed to look.
I surely just need to setup some default stuff somewhere else.


I've read about collision stuff in Godot and many examples use this for free movement of your entities. I think it is better for the cpu utilization to have a grid based collision check (tile occupied? then you cannot go there) and only use a "rigid body" check when it comes to "mob vs player" meetings ;-)



The game is currently planned to be a simple "collect some stuff, activate some switches, avoid monsters/traps" game. Collect the needed stuff and solve the simple riddles (whatever I will come up) and the door/hidden-ladder/... to the next level will open/enable passing through.

Monster models I create are surely useable for my "Trick or Sweets" game (environmental props). Code hmm, for now not really reusable in my other projects.


Might post some screens when on my dev computer / at home again and the kids in bed.

bye
Ron

I like the early look of the first video. It's not far off the angle I have planned for my game ( should I get the actual bloomin chance to code anything ).

The subtle light effects are cool and I look forward to seeing development shots ;D

Looking good, Derron!

Quote from: Derron on September 03, 2018, 11:39:44
Godot is really "string"-centered. So stuff is referenced by strings (get_node("bla/bla.tscn"), animationPlayer.queue("Spikes.Deactivate")).

I've been learning Godot too, slowly getting the hang of it. I'm learning GScript and found out the other day you can use $item instead of get_node("item"):

So:
get_node("Label").text = "HELLO!"
can be:
$Label.text = "Hello!"

Once most of the C# stuff is done/fixed I'll be moving over to that instead of GScript.

Good to know that there is somebody out here who might be able to help if I run into problems ;-)


bye
Ron

Haha! I'm just learning and doing 2D :)

Godot 3.1 looks good with optional typing which should help the code completion issues in the IDE.

Looking good Derron. I will utilize the same toolchain.

I compiled godot "3.1-dev" meanwhile - resulted in a 130mb file, compiled with some modules disabled (not used formats...) and it failed after some hours of "linking" + "compiling". the Theora-decoder seems to need "opus" support and failed in some deep-for-loops then. Have read about runtimes truncated to 7mb uncompressed and 2mb in the final apk file. Of course they miss the 3d part then, but for 2D (therevills?) this might be an interesting thing to try out. Same for the windows/linux/... binaries.

The "autocompletition" was still not corrected - and as I have read about the issue, their excuse is that it is a dynamically typed language and they never can assure what kind of type is really passed.
I understand this for things like

func myfunc(someparam):
someparam.???


but I do not get how they do not understand:

func myfunc():
var tileGround = load("res://Tiles/Tile_Ground.tscn")
tileGround.???

I mean, the "tileGround" thing can change (from what it extends) but in the moment of typing it _could_ get resolved.


Only working solution is to have something like

func myfunc():
var tileGround = load("res://Tiles/Tile_Ground.tscn")
if tileGround is (or extends in godot 2.x) Node2D:
tileGround. #works

This is absolutely awful for someone who tries to learn the language + the multiple types and their functionality.

---

Game progress:
I had about 45 minutes yesterday (so 50% more than Qube ;-)) and wrote some script stuff to handle AStar for pathffinding. In Godot the 2D tilemap and the 3D gridmap (far too limited for an "3.x" - even if they implemented 3D later on) have some support for pathfinding. You could also do some navpath3d thing or so but this needs support in your 3d models (similar to collision meshes). AStar is useful for simple grid maps (grid occupied or not). Should be way better performing.
So I wrote some grid hashmap (similar like the "TMap" in BlitzMax)  containing all valid grid cells needed by the AStar class. All cells are then passed to the AStar class and node connections are established (grid cell x has leftside nothing, rightside another walkable grid cell, ...). Means afterwards the algorithm can calculate paths.
If something on the grid changes (wall breaks down, door opens, ...) the grid hashmap is refreshed and the AStar class gets a new list of datapoints added.

That way the pathfinding is no longer strictly limited to the actual tilemap - which might contain the ground tiles or wall definitions but has (for now) now clue about potential obstacles.
But I already thought of replacing it with some kind of 2D array and then add different layers for "obstacles" or "collectibles". This is the right spot at which I lack a lot of knowledge. Tilebased stuff was new to me in the last competition (the "creature corp" entry). Of course I now try to do things better (or at least different) which does not mean I do it properly. Arghh ;-)

I already know that I will spend hours of time developing stuff which at the end is doing pretty odd stuff to make it work in a fully-bugged way needing more and more hacks to keep it doing what it is suspected to do.


How would you guys manage the tilemap + collision stuff (think of many tiles being objects able to get "asked" if they are walkable/collectible or not - like doors, traps, coins, ..) ?


bye
Ron

Managing the tilemap query you had:

The way I do it is like this (javascript - so different language but same approach)

object 'battlemap' which is an array of objects
each element of battlemap (index = x + y * maxgridx) has the following properties:
.tile = 0 or 1, 1 = floor tile, 0 = wall tile
.creature = index to creature array - indicates if a creature is in the cell or not
.terminal (for my game I have computer terminals...I have a 'terminal' property which is true false if there is a terminal in the cell)

pathfinding:
I don't bother worry about creatures but only tile positions.....if I were pedantic I'd include the .creature index (-1 for empty) in the pathfinding as just another obstacle (1 creature per cell).

That's my method...the method i've always used for almost 15 years.....

So in other words:
- you store gridcell-objects
- assign mobs/collectible-items to these cells (think to save some lookups)

Dunno how much it affects performance if you need to lookup cols*rows arrays compared of a "occupied grids"-list. Think for small levels it should be neglectable and a good way to keep code a bit easier.

So I would have this:
- array/list of grid-objects
- grid-object contains: (static) walkable, cell position (col, row), position (x,y,z) for rendering, list of "contained" items (creatures, collectables,...)
- array/list of creatures/collectables (again but to save traversal over all grids just to update/handle these units)
- when updating creatures/collectables and moving over/in/out-of grid cells, the gridcells get informed and update "contained items list" + update their walkable-state (so you could have moveable blocking-stones...)

Of course above requires multiple lists/arrays to be kept in sync but it allows a faster access when it comes to collision/interaction-checks. grid objects only need to scan a handful of items in their "containing list". If creatures want to know about the tiles they walk on - how do you tackle this (except having all definitions in one file - means A knows about B and B about A). Looks a bit "dirty" to me.

Or am I missing something?


Thanks for exposing your tilemap-approach.


bye
Ron

Hi Derron...the easiest way to explain is with an example. ..on my phone so can't share links easily but if you look in my code (js link in my thread) and look at the references to 'battlemap' and its elements it should explain better than my words.

I looked at your code and ... it is not how I would like my code to be (I prefer to split things apart into multiple files for easier reusage in other projects, to avoid dependencies, ... and so on).
You seem to use many "procedural" approaches (defining things in the code rather than some .ini files - keep data separate from code). For prototyping I think this is good to go but hmm dunno about team-based development or if you want to overhaul the code later on (replace x with y).


Aside of that, I restructured my code the last 3 hours - to split functionality into separate classes and still avoid cludging everything in a "global"-script (available via "GLOBAL."). Still it seems you might rapidly end in a chain of children:
GLOBAL.currentLevel.gridMap.GetAStarPath(GLOBAL.currentLevel.gridMap, startVector, endVector, ...)
except you add helper functions
GLOBAL.currentLevel.GetPath(startVector, endVector)

Ok, so I got it working again and somewhen in the next days (next spare time) I will try to restructure the grid-manager part (grid cells + units). Collectibles should be easy to do too. Also I think animating stuff (like coins swirling into the air during collecting or so) should be easy to do: create the animation and play it once the player enters the grid of the coin/item/what-so-ever. Just need to research if I can reuse certain animations for multiple items (so relative changes like rotation, alpha, ...).


Progress for now: Some enemies (cloned from each other - so one script to rule them all) pursue my player character on a "per tile/grid cell" mode. Means they look for a new route once they reach their adjacient grid cell (the one bringing it a step closer to the protagonist/hero). When they enter a cell, they emit an signal, and when they leave, too.
Signals are used similar to "events": to decouple stuff (A does not need to know about B, B just registers to listen to A's signals/events).
Also creatures/units are now having a base class to extend from.


When I thought of "Godot" or "Unity" I hoped to have all these basic-stuff already done and just to have to add some meshes/models and to define the AI. Seems there is still a lot to do.


bye
Ron

QuoteAside of that, I restructured my code the last 3 hours - to split functionality into separate classes and still avoid cludging everything in a "global"-script (available via "GLOBAL.").

Don't you find this approach to be the more snobby side of coders?. Those that go out of their way to avoid global variables just seems to be doing it because they can. Personally I find global variables invaluable, especially when just used as a flag across multiple functions.

Unless your aim is just to reduce masses of global variables?

QuoteI prefer to split things apart into multiple files for easier reusage in other projects, to avoid dependencies, ... and so on

How deep do you go with that?. For games I tend to just leave it at general framework, GUI, pathfinding, AI and common routines. I find it easier to adjust a common module as per needs rather than go super crazy and split things up into 20+ files. Sure I could split them up further but for simplicity it seems a waste of time.

How are you finding Godot?. It seems pretty well supported for an open sourced project.

@ Globals
I think it is kind of dirty if you have a "global" class containing the links/references/instances to all classes (level, grid, units) and to import these global into all other classes (so units can access "level", "grid").
I am used to think in parent-child-relationships. Parent knows that it has child, but parent does not necessarily have access to "parent.money" ;-)

So, maybe call it "separation of concerns" or whatever the right English terminus is.


@ splitting things
Not that deep. Tiles split from creatures, level base logic from level implementation ("the game scene" vs "level.GetUnitsAt(x,y)"). This is to allow individual levels to get added without duplicating the code.
In TVTower I split it way more apart as BlitzMax did not have "interfaces" but I needed a non-cludged access to information. I do not like to have "include" for everything but "import" (to speed up compilation times - and for easier maintainability). This "thinking" is burnt into my brain and so I try to use a similar approach in a dynamically typed language like "gdscript". Surely this costs a bunch of time and this is maybe wasted, dunno.

As said for rapid prototyping this is way too sophisticated and some might come way faster to an result then (on the first run - on the second project I can just add my previously created stuff and it hopefully auto-figures out what to do instead of having to adjust the code "here" and "there" and "ohh there too").
I mean: I once wrote an extendable GUI thingy utilizing some XML stuff. Why not just use this functionality, throw in an overhauled gfx and done?

Of course you are right when it comes to reusing game-specific stuff. So a pacman-creature-behaviour is surely not of use in a RTS game. These are not things I name "base.xxxx.bmx" ;-)
What I see as base is "tilemaps", "isometric grids", "highscore" ... and so on.

Now I started to try out godot, without knowing much how limited or unlimited it is, what is possible, what only with tricks, ... ?
I started and tried to keep things separate to maybe use it later on in other projects. Also I am not knowing if I do things wrong, so I better only do it wrong in one place (class, file, ...) than in a multitude of different scripts I "copy pasted" together from other scripts in the game.


@ Godot
It is interesting and of course I would more likely use it than "Unity" or "UE4". Think it is kind of an underdog. What I really miss is: written tutorials - or at least current 3.x tutorials. you find some interesting stuff for 2D (eg. GDQuest's youtube tutorial series) but for 3D you only find oddly-microphone-recorded videos in badly understandable English - or Turkish/Spanish (which is surely good for people understanding these languages!). Tutorials are often "long" or not strictly-to-the-point.
Just think of the latest Blender tutorials (jayanam makes nice little tutorials - especially good for beginners to Blender, and his German-originated basic English helps me to pretty easily understand him ;-)). These tutorials are exposing single stuff of Blender. Easy to spot them via the youtube search then.

But for Godot? If you lookup for stuff you most often land in the Godot docs - which are often just containing the function definitions (and description). It needs more examples.
If you want to check what Godot already supports in its frameworks (think of "gridmap" for 3D tilemaps) you only find some "minecraft"-like stuff.

Also Godot lacks some "showcase" games which are different to "2d/3D platformers". For now Godot seems more suited to replace old "GameMaker"-like games. Cannot imagine to do "TVTower" in Godot - except when using just scripts/code and skipping the whole editor-thing.

It is surely an impressive piece of software, but I think it needs a multitude of months to "mature" and to create a community being motivated to create tutorials. Maybe it needs some kind of "store" so people are encouraged to promote themself - and so indirectly their store assets / commercial tutorials / games. Blender achieved that during the hmm last 2 years, so this might be the timeframe for Godot to grow up too.


bye
Ron

Spend this lunch time to research about signals.

Seems signals are ... kind of limited. So you need a "sender" and a "target". There is no "broadcast" (I thought it behaves that way - but only the sender received the signal, which is pretty dumb).
Seems the other way to broadcast is available via adding objects to groups and then call a function in each member via "call_group".

They say signals decouple logic in godot. Nope, it does not decouple as I understand "decoupling". if A wants to listen to B's signal, it must directly link to it, so it must know about the existence of B. And if C does send the very same signal too, then A needs also to know about C. This is not "decoupled".

So this means for example: player A is the city-boy visiting a ranch and does not know much about animals, and then there is cow B and C which are eating grass. Now they want to inform the world about the fact they eat grass.
- A could now iterate over "cow herd" and check if they eat
- A could register for the signal of cow B that it begins to eat - but he does also need to register for the signal of cow B, C ... Z1000
- in a better world (eg in my Dig-Framework@BlitzMax) he would register for an event "animal.eats.food" and gets informed about all animals sending out the event, he does not need to know if it is a cow or a hen (but he could check via the "sender")
- Godot allows (as said) to send to groups but you need to take care of having items in the right group

Any ideas how to do "#3" - or is "#4" very similar?


To explain what I want to achieve (for now):
- each collectible, unit, ... "level object" sends out an event/signal/... when another object enters/leaves the very same grid cell
- each of these objects listens to these signals and handles if another object with the same col,row emitted an "enter/leave" (they then emit an "collide" event)
- objects are free to handle these collide-events/signal/... then (eg if it is a "player vs coin" the coin would get collected and score is given)

While one could handle it differently (Players/Creatures know about items/coins/...) it can create issues (Players need to know Creatures during collision and Creatures need to know about Players ...).
Will try this evening if "groups" could inform each other ("unit enters grid cell", col, row) and so on. It feels like using a crutch instead of a clean solution. But hmm, maybe I am the one doing it wrong. Maybe I just should use simple "if sender is Player"-checks and skip all these sophicisticated "separate concerns" thing. Hard to convince myself. hmm.



bye
Ron

Did not have time to do something today so I was only able to record a video from yesterday's after-lunch-session:



What you see there ware the newest additions:
- restructured "map objects"-managing
- - adding them to (multiple) godot-groups (for potential message-broadcasting)
- - added them to manager-groups (so I can easily pre-count how many items, collectibles, ... are on one tile/grid-cell)
- added some test animations (to try how "chaining" functions) for collecting, idling ... of items/collectibles
- tests for AStar-following creatures (same temporary-character, sorry ;D)
- no longer using signals for now as they are just not useable for my intends, am checking for collisions "by hand" now in the level class (creature vs creature, creature vs items/collectibles)

Most CPU utilization comes still from the lighting (20% without lights, >50% with lights). The whole handling of the grid logic is not adding much CPU wise - so I assume there is no need to optimized that yet.


Next I want to try out on how to adjust alpha of objects, do not plan to do that via shaders...
Once this is working I need to add some kind of "switches" so manipulation of the level is possible (opening paths, ... ,doors, ...).

Also thought of making the level even darker and give the main character a torch then - think that could look cool (and might be of use to fight mobs?! - in that case spots in the level might be existing to "re-fuel" your torch). But for now: trying to keep things simple and "finishable" but I bet, you all understand that "tinkering" and disuccing "ideas" is one of the cool aspects of game dev - the things that make "fun".


bye
Ron

Used yesterday's evening to replace a lot of map/grid code. Instead of using various objects to have "collision maps" (grid blocked or not) and "object maps" (storing a dictionary/table for each cell containing objects) I use a similar approach to Mattys now: each grid has a list of layers (used in that grid) and each layer can contain objects.
I used the prior approach to "split" the code but as everything knows all other things there is no need to make it that complicated.

But still the whole bang took a lot of time - why? Dynamically typed languages...
If you refactor your code, eg you replace an "integer array" with an array now containing objects it wont fail during "compilation" (which it surely not really does - it only syntax checks). It will error out when it uses that line of code the first time. So until eg. no collectible is collected, the game will run - but once you collect one, it errors out as you still use an array as "integer value" instead of the object now.

So everytime you change something, you might end up with an error somewhen in your game as you missed something. This is pretty annoying.


Also: assume you delete an object in your code (via "queue_free()" - to only finish it when it is idling/not processed at that moment). Now you had a reference to this object somewhere in your code (so not in the "godot maintained" stuff like the "node tree"). Now you iterate over your custom list containing the reference to the object. You even check for "if object == null" ... but it still fails then with some "accessing function of previously freed object". I mean, couldn't it just say "object == null" at the first glance?

Also: objects extending from the class "object" (so "node", "spatial", ... and whatever else) have methods like "has(value)" to check if an object has a "var myvariable" (or "global") defined. It also has "has_method(value)" to check if a function was defined in that class. This works nicely - but not always. Sometimes I pass a "spatial" (a loaded scene with a "spatial" as parent) to a function - and it then errors out (of course just during runtime) that the passed "object" does not have a function "has" (or "has_method"). The Debugger then says "object1234" and no further properties (no "variables").

Ok, maybe I really passed something not containing that functions? No clue, still newbie for Godot. But hey, wait. You can do if ("value" in object) to check if it has a property - and guess what, it now found my property without erroring out.
So what did I do wrong?

Means during refactoring the code I fighted the language for a lot of minutes - minutes I would better have spent for the game.



During refactoring I also added some helper methods to replace "floor + layout" tiles (the "floor" is a separate scene/object) with others. Means I can now add traps (having it's own "floor" - so I can eg destroy it partially for a "falls into trap" effect) to a grid cell dynamically.
Needed to do such stuff so "moving tiles" are easier to achieve.
Also created some "blocker" items (walls coming out of the ground once a switch was activated). Code preparation done to make dynamically "IsTileBlocked()" checks possible (all objects attached to certain layers of a tile are asked if they are blocking).


For now I really enjoy things like "dictionaries" and the likes - they ease a lot of pain during coding (but they of course feel somehow "dirty" and "expensive"). But I really dislike the somehow inconsistent behaviour of the scripting language. Also the dynamical typed language aspect is really... something I have to get used to - especially as it is surely expensive to always check a passed parameter first (not just "if bla == null" but if it is having a specific method).


bye
Ron

Nice to know my approach came in handy.

Let's see some more screenshots.

Pheew... two evenings to get some kind of "pac man"-level-like generator up.
Not really satisfied as it (for now) looks too "clean" for the game theme. So a "dungeon"-like-thing might suit a bit better.
I have the whole map generator in an extra-script so it should be fairly easy to replace it with another one (or offer both).

(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FWSFji9H.png&hash=c6ee8bb0a25a4a3b195f709924232e4ddc5078a5)
(yeah, I miss some blocks for the "4 walls = 1 block"-parts, will replace with some Egyptian statues or obelisks or so)

Performance of the generator is far worse than when writing such stuff in BlitzMax. Of course this might be grounded on the way I do (try) things in Godot. Nonetheless we talk about milliseconds in these small levels (I tested with a bit "more" cols*rows ;-)).

Another thing I tried to tackle for about an hour was: how to draw 2D stuff on 3D things. At first I added a "Spatial" and there I added some TextureRect-nodes. These TextureRect nodes can emit a signal when they "_draw". My main script hooks into it and calls some custom draw stuff. So it drew the "minimap/map-layout". Nice. But ... oh, ahh wait, why was the 3D part drawn after the minimap? Hmm, I moved/adjusted-add-location of all 3D objects into a new node ("playground"). I moved the "Spatial" (containing the TextureRect) after this playground-node but hmm, did not work. No clue how to set a z-index for these things.
Googling for "Godot HUD" or "Godot draw 2D stuff" and so on ... leaded to 2D Godot tutorials, not "3d + 2d" things. Somewhen I found a Godot documentation telling something about "CanvasLayer" - which allow some "Layer setting". Voila, added such a thing as parent of the TextureRect and was able to set the layer to "1". Now my hud/minimap was rendered after the 3D stuff.


Pheew .... I really thought that things are way easier in Godot (or Unity?). It is not enjoyable if you need to lookup soooo much stuff instead of just creating your assets, writing some logic and voila. Man, I hope I will once reach the part in the project where I can add some animations (Hooray "game won", "Ohh noeees I die", ...). Think they are more fun then.


bye
Ron

QuotePheew .... I really thought that things are way easier in Godot (or Unity?). It is not enjoyable if you need to lookup soooo much stuff instead of just creating your assets, writing some logic and voila. Man, I hope I will once reach the part in the project where I can add some animations (Hooray "game won", "Ohh noeees I die", ...). Think they are more fun then.

I guess you are plodding on as slowly as I am? :P - Certainly a steep learning curve diving into a whole new way of working. Every step of the way for me too has been google / youtube.

I think people think that Godot / Unity make things so easy and truth be told, they don't. Sure, it's nice to visually build your scene / level but in the end you're still coding your game logic in C# ( not sure what Godot uses ). For me it's been a real hard slog at every step but I'm funnily enough enjoying the challenge ;D - At least for my next game I'll have a much better knowledge on how to approach things.

How are you finding Godot overall?

Back on topic... Your game is looking pretty swishy and intriguing. I hope you get to finish in time :)

You could use mono/c# for coding - or their "gd script" which is very similar to Python - which means you always get issues when you paste some code with "space intends" instead of "tabs" (eg. you wrote something in another editor - or you paste some sample code). Happens not so often (as you most of the time write your code straight in the inbuilt editor) but as the editor lacks some replacement/refactoring-skills you here and there get the wrong-intent-error.

What bothers me most is the lack of "keywords" for proper google/youtube-search. I cannot watch every "Godot" video just to somewhen find what I currently am struggling with. They do not use the words/terms _I_ would use. It is some kind of "hen - egg" problem. If I knew the right functionality/keyword in advance I just could lookup the documentation or use it right away. As you do not have proper autocomplete for your objects (dynamically typed...) you would need to tangle along the whole hierarchy of object class ancestors until you reach eg. the functions doing vector normalization or assigning materials ...

As said: the projects (Unity, Godot, Unreal, ...) are surely way matured than many libs/frameworks but if you do not know how things are called there... you are pretty much lost.


I still cannot see myself writing "TVTower" in Godot/Unity. As someone else stated in this forum: Unity/Godot are surely suited for arcade games or maybe jumpnruns.
The editor is then used similar to "effect editors" or "tile map editors". Sure you speed up stuff there - but most often you only help a designer, not the coder.



@ game look
Nah, once it works I would of course replace my mockup assets (or improve them). Walls need rounded edges if they are not connected to another wall. Decoration elements are missing, items are missing.
This will be the fun part. Designing golden scarabs (or so), modelling and animating mummies. I feel way more "welcome" by Blender than by Godot - for now.


bye
Ron

Spend yesterdays evening (2 hrs after some wine and a movie with the wife - real life matters ;-)) to get used to particles in Godot.
I tried to find a way to randomly rotate a plane (quad) particle around its center - so that it is visible from every angle (here and there).

Seems Godot does not have that option (at least it seems I was not able to find it ;-)). Tried to use qubes but that looked ugly too ... with my current configuration.
Ok, tried to find stuff on google/youtube: nada. I only saw people presenting their _results_ (not the setup/configuration) of a simple fire animation.

After tinkering about a "always face to camera" thing I found billboards... weren't billboards always looking into the camera? Hmm, has Godot such a thing? Yeees it has - hidden in some option panel of the texture/material: "Parameters :: Billboard Mode :: Particle Billboard". I mean - if THAT wasn't obvious. I am glad that the Godot documentation of the year 2019 had this information right at hand.... *grrr*.

Ok, seems my particle planes now faced properly to the camera. Needed to get my textures working. Set them as transparent (as before) but it all looked dull when fading out alpha the older the particles got (top of the fire). Tried to use a multiply/add "emission" setup to brighten things up --- naahhh looked ugly. Tried out to use "transmission" (I thought the alpha values already configure a transmission ...) and voila, it looked _pretttttty_ cool!. Transmission seems more a kind of "screen"-mode in Photoshop (grey + grey becomes light grey). With the right "color" (which seems to be a kind of "Multiplier" between 0 and 1 - allowing images for varying multipliers) it was easy to adjust it properly.


For the creature (for now still the player mockup character) I added 3 particle systems - 2 on the arms and one at the back. Then I emit only 2*10 and 1*20 particles (=40) per second - think that is a low value.
To make it look "burning" I also added to small lamps in front and back of the character. The lamps are also animated like the torches in the corners of the level. This makes it "flicker" during walking. Maybe I attach the lamp to the movement of the arms too (will have to check how to do this - maybe some parenting thing (empties or so?)).

(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F5yefaik.png&hash=81c84ed6700f83d40c1535da0392f2d7818ba303)

Using multiple particle systems allows me to animate the engulfing-process. Means: you somehow attack the enemy (or he walks into a trap) and then you start particlesystem 1 ... after 0.5s system 2 and so on. This then looks like it starts to burn.

I think I could also add all the particle systems into a new scene - and append it as needed to multiple objects (means I only set the effect up once and use it multiple times) -> multiple creatures use the same effect setup (but with their own particle instances).


bye
Ron

Ok ... so how to adjust particle systems from within your code? How are the functions or properties named? The documentation talks about particles or particles2d - but the particle system (3D) itself?
A dynamically typed language does not autocomplete well... so "Particlesystem(dot)" does not open a list of suggestions. "Emitting" is it labeled in the editor, tried "particlesystem.Emitting = true", null-access-error. Tried "particlesystem.emitting = true" and it worked.

I know I could trigger certain stuff via "AnimationPlayer"-Animations (so instead of changing values you call a function after X seconds or so") but for now I just did a "StartFire"-Animation which animates the "visibility" of the lights (emulating the fire-lighting). Also I animated the power of the lights (from 0 to the value used in the fire-light-animation which is played in a loop). Still experience some odd "shadows" (maybe the lights need to be repositioned aside of the particle system ... I already intended to move the lights too, to make it look more "fiery").

(https://abload.de/img/ezgif-4-6c61a78c450lez8.gif)

For fire it is also important to set the coordinate system for the particles from local to global (once they left the body, they wont move along with him) ... "let it go, let it gooo..."


bye
Ron

Added "spread fire" so it is up to you to create a nice chain of burning stuff.
Needed to fiddle around with "previously freed instances" - you need to take care on your own of getting rid of old variables - as there is no way to check for "valid instance" yet. Assume you have a coin object in multiple "node groups" and set the coin to "queue_free()" (remove as soon as idling) and then you access it via one of the "node_groups" the entry is not null, but leads to an "previously freed instance" error.
Means you need to manually remove all the stuff and so on. Can get tedious.

Whole code looks more and more "dirty" with long lines just checking if a given object is of a certain type/class/has functionality. Refactoring becomes a hassle!


I also changed the fire animation to be more "comical" one as I assume not all people like to watch stuff burn.

Nonetheless: short video



bye
Ron

Looking good!

QuoteNeeded to fiddle around with "previously freed instances" - you need to take care on your own of getting rid of old variables - as there is no way to check for "valid instance" yet.

Doesn't Godot have a method to spawn / deleting instances of objects? - Surely it must have a method to create and destroy multiples of an object? - That's kind of the basics of any game.

QuoteAssume you have a coin object in multiple "node groups" and set the coin to "queue_free()" (remove as soon as idling) and then you access it via one of the "node_groups" the entry is not null, but leads to an "previously freed instance" error.

That sounds like more of a bug to me. If you have a script attached to an object then it shouldn't run if that object doesn't exist. Unless you are accessing them via another script to which I would say it's script priority error. The code side of Godot/Unity are very OO based so keep in mind that one script may delete something but another may try to access it in the same update sync.

Also ( don't know if this applies to Godot ) keep in mind that there may be two updates going on, normal per frame update and physics update. If you want to access other objects then keep all that code in one or the other. Mixing between the two will lead to referencing issues.

QuoteI also changed the fire animation to be more "comical" one as I assume not all people like to watch stuff burn.

I think you could get away with them screaming in a high pitched comical voice. If you were going for photorealistic graphics and people burning then I think some would find that awkward but a comical cartoon style (thankfully) is a still a safe haven to have fun.

@ freed instances
https://www.reddit.com/r/godot/comments/8hp3ok/use_call_deferredfree_instead_of_queue_free/
https://github.com/godotengine/godot/issues/4306
...

In essence Godot encourages you to remove an object from the "tree" by using "obj.queue_free()". It waits until the "obj" is idle (not processing anything) and then it removes it from the tree/root...
You could call ".free()" to instantly free stuff - but in almost any case you will end up with a crash (as you remove it eg. inbetween of a physics-update or so).

Now assume "obj" is stored in
var arr1 = [obj]
var arr2 = [obj]
(and in the tree ... via an add_child(obj) from within a node/script)

Now you somewhere call "obj.queue_free()". It does not matter how long you wait now (/how many cycles). The "reference" in arr1[0] and arr2[0] won't evaluate to "null" ("if arr1[0] == null" will fail!). But in the same time you cannot access properties in arr1[0] and arr2[0]. The "Object" there is now a "previously freed instance".

How to circumvent? RIGHT ASIDE when "queue_free()"ing the object, you need to take care of removing the object's references manually (arr1[0] = null, arr2[0] = null). THIS is tedious.
I meanwhile added a "Delete()" method to some of my objects which removes the manually added stuff - but as you cannot ensure that all added nodes have this method, you need to check for it each time - or else just call "queue_free()". Also it does add dependencies (which is not a problem in this language as it throws everything into one bowl and mixes it up ... "include"-way instead of "import"). In the end you have code accessing stuff from multiple files which access the other files too - refactoring hell upcoming!


They have some kind of "weakref" class which you could use instead. Means instead of "arr1 = [obj]" you should add a "arr1 = [ weakref(obj)]" and when accessing the object you need to check it ("if arr1[0].get_ref(): arr1[0].get_ref().doSomeOperation()").


So why is this confusing?
There are some "free"-methods which only take care of the "default storage way" (adding it to a node and retrieve them from there - including performance costly for-loop-lookups). Tutorials always say you should use "[queue_]free()".
So ok, I may forget to remove a reference from within an array or list. I would assume that the object stays alive in that list (as it is still referenced) but no - you get this "previously freed instance" error. AND you do not have a way to check the object _in_advanced_ if it was safe to access it (aka "still valid instance"). With 3.1 (not released yet) they added an "is_valid_instance()" method to do that - after people begged for months!

THIS is what annoys me the most: to tinker around on how to remove/manage stuff. For now I need to "centralize" functions on where stuff is removed - and act accordingly to remove all references which might somewhere exist (especially for faster lookups ... just imagine you need to lookup for projectiles on a 1000*1000 tile grid...).


As much as I love the visual effect editing (including its annoyancies) the dynamically typed language thing and the "previously freed instance" stuff is driving me crazy and _really_ slows down development pace.


bye
Ron

Can you allocate space for everything in the beginning and simply reuse objects over and over simply changing their properties and only free ghings wgen the level is completely ended.

Like a pool that reuses elements so memory remains roughly constant because nothing is destroyed and instead has a property that says whether an object is in use or not and if not it can be reused for something else of the same type.

You would need to take care of resetting everything ... you obviously miss stuff here and there and then you run into bugs.

Also: if you collect a coin - then there is no need to keep it in the "pool" and to iterate over it again and again. Remember: if you put it into a new list ("availableList") without removing it from the other lists ("usedList") you end up either processing it everytime ("if dead then continue") - maybe even Godot processes it (physics) - maybe one could "pause it".

For such easy things like "coins" or 10 monsters - this is a big thing to code instead of having some simple "== null" thing.


bye
Ron

This game has a nice feel to it...But you always seem to get caught-up in technical problems...Maybe you over-think the procedures?

I might overcomplicate stuff yes.
But if you do not know what things "Godot" offers you are enforced to check the internet - and if nobody asked stuff with the terms you use (or nobody asked at all) then you are stuck until you found a solution, bypassed the problem or skip a certain functionality.

The "previously freed" thing is ... annoying at least. And it does not take hours to fix the particular issues - but to find the reason for it and how to avoid it in your game.

I think my experience is similar to Qube's Unity adventure (ok, with less progress than what he achieves ;-)). Once you understood a certain part in Godot/Unity you can reuse it later on (or more propably: avoid it next time and just use the pre-crafted and ready-to-use solution inbuilt in the software package).

And yes, I am aware that dynamically typed languages allow certain stuff without hassle - but with the costs of issues I experienced with Godot for now. Just am not sure if I can accept it.


bye
Ron

Quote
The "previously freed" thing is ... annoying at least. And it does not take hours to fix the particular issues - but to find the reason for it and how to avoid it in your game.

I think my experience is similar to Qube's Unity adventure (ok, with less progress than what he achieves ;-)).

lol, I think engine designers speed off...Then suddenly realise their initial approach was maybe not the best logical approach - so it causes headaches for the users.

QuoteYou could call ".free()" to instantly free stuff - but in almost any case you will end up with a crash (as you remove it eg. inbetween of a physics-update or so).

Wow! that sounds like they've not finished designing that side yet. You should be able to free an object at anytime without issue. In Unity you just Instantiate a prefab and Destroy() it when you need to. Some recommend doing a pooling system to create / destroy objects but I'm not going to overcomplicate things for my first outing.

Yes, when you use "free()" then it does that instantly - if you use "queue_free()" it waits until the object is no longer used (but this also means it is eg. available in other function calls of the same "logic loop").
So instead of deleting items, you need to set some variables (eg. "isDead = true") so stuff could handle it accordingly. In my case I eg. mark items as no longer "collideable" (instantly) so other entities do not collide with it too.

I really want to "like" Godot but hmmpf, I am too used to BlitzMax to adopt to the Godot-way-of-doing. Adding stuff here and there is fun. Fighting these odd things is what annoys and takes hours and kills the fun you just experienced the half of an hour at the begin of your coding session. So I had an "previously freed" error the last 10 tries in the game - somewhere in between, but for now I cannot replicate it (as it happened in an area which _should_ get cleaned when removing an entity).
Am happy that we are in a developer community, so we are used to odd segfaults, crashes and so on - so I _should_ move on and take care of it later (will be hard to ignore it for now ;-)).



bye
Ron

QuoteYes, when you use "free()" then it does that instantly - if you use "queue_free()" it waits until the object is no longer used (but this also means it is eg. available in other function calls of the same "logic loop").

Then why not limit queue_free() to objects that don't have any code interaction?, like most particle effects ( explosions, smoke, fire etc ). Other objects like bullets, enemies, missiles and the like would always need to be instantly freed on contact ( after collision logic ).

I don't think you need to track for a safe time to remove an object for example :

Fire bullet > bullet hits something > free() > do fancy particle explosion > queue_free() - As you're not attaching any logic to an explosion then you don't need to track when it's done it's stuff, but if you do need to go a step further and do stuff like explosion ratio burns then surely it's a piece of cake to know if an instance of an object is still active?

From the sounds of it ( quick doc read ) "queue_free()" is based on the idea that when an object become idle it is then deleted. To me that instantly results in a coding nightmare as queue_free() can never ever deal with every scenario, especially when you have logic attached to that object. No wonder it craps out.

Personally I'd only use queue_free() in the example above, i.e. when I don't need to know when something has ended or has attached game logic.

Quick question though... Why don't you know when you need to delete an object?

Yes I think so too about free() and queue_free().
It only get's tricky if I add objects to arrays/lists/containers and so holding additional references. If I forget to remove from such a container and then "free/queue_free" the object I will run into the "previously freed" issue once I iterate over this particular array/list/...
In BlitzMax I could "autorepair" such things by eg. have an "If bla.isDead then toRemove :+ [bla]" thing.

In Godot I cannot repair it - as I cannot see if an object is still valid, means I get a "handle" but do not know whether I should remove it or not ... and I cannot access it as it leads to the "previously freed instance" issue...

I am pretty sure that the free/qeue_free() stuff somehow works - I just sometimes use it as I am not intented to use it (eg. forgetting to remove a reference when freeing).



----------

Yesterdays evening ended with refactoring some code so that tiles have the possibility to be non-static. So a static ground tile becomes ex. a "trap" which has a script attached (based on a base unit script also creatures and collectibles share - so it has certain functionality inbuilt now) - this is needed as some elements do not need a ground (the blocker wall needs to go lower than the ground - including a "hole"). This also means I need to do "all [interactive] vs all [interactive]" checks to inform ex. about players entering an interactive ground tile ("activate trap"). Performancewise it could be better to have a list of "objects having changed grid position" and then in the objects' update-call check if there are entries in that "changed position list" - would save some function calls but is of course more cumbersome. As said the current system works and for now the performance culprit is surely the light+shadow system and not the simple game logic.

Ok, so current todo-plan is:
- add collectible "torch" ("dry") - or have one automatically (old bone + clothes are everywhere to find ;-))
- "refill" and activate torch at tiles with fire pillars
- burning torches allow to burn (certain?) enemies
- burning enemies can kill you
- wall blockers + switches (walk on the switch and the blocker wall moves up and blocks a path until you reactivate the switch/other switch/riddles?)
- spike traps: move over them in the wrong moment and... you're dead
- level end gate which opens once you collected "required" items (some special ultra-rare artefacts each adventurer wants...)
- burning enemies should move away from the player - but what happens if there is no space left to go - should it move towards the player then (and so kill the player? - increasing difficulty)


bye
Ron

Ok, so ...  wanted to check out bitmap fonts. Seems there is some "hmm hmm" code in - Godot users should use "Dynamic Fonts" instead - but since Godot 3.x there are less options available (prior you could add gradients, outlines ...).
Means I created some bitmap font with "littera" - and somehow the glyphs jumped (baseline incorrect). Opened up my old XP VM and run "ShoeBox" in there (drop a PSD file containing your glyphs and it creates the font out of it... so individual styling is possible).
No jumping there, yes sir ... but ahem... somehow my drop shadows made the background brighter. Digged around what could be the reason. I converted my file to use premultiplied alpha:


$ convert fontHudSmall.png -background black -alpha Remove fontHudSmall.png -compose Copy_Opacity -composite fontHudSmall.png


and the image now looks way better.

(https://user-images.githubusercontent.com/2625226/46147181-0a97b500-c265-11e8-86c1-61ae4bf7f6a2.png)

Is this stated somewhere in the docs/issues? Hmm the only thing I found, was an 2016 (v2.x) report that the option for premultiplied alpha bitmap font images should be added (so the normal one is default) ... arghh.
Meanwhile I raised an issue and hopefully they resolve it - or show me the right way of doing a "HUD" over an 3D environment - seems this is not done so easily (I want to avoid to "render to texture" and set a quad somewhere over my game - I think a game design editor thingy should provide this already).

issue:
https://github.com/godotengine/godot/issues/22477

If this was a bug, then ... don't we talk about a version 3.x not 0.x? Shouldn't others use "HUDs" too - do they only achieve that via complex r2t? Why isn't there a proper tutorial about this (2d hud over 3d environment) - maybe I just lack the right terms to feed to youtube/google.


Edit:
Maybe I should also create another issue: if I render a colored rectangle (color is param of the draw command, no previous world.setcolor() thing!) then the upcoming world rendering is using the color of the rectangle. Need to render an empty but white text string to return to "white".

bye
Ron

My bad ... seems ShoeBox (http://renderhjs.net/shoebox/) has issues importing PSD files correctly. Exporting them to .png first and then dropping the resulting .png files into ShoeBox results in an bitmap font not having this issue.
So this time Steve was absolutely right... the computer bug sits in front of the computer ;-)

Next problem to tackle: how to scale a bitmap font properly (when resizing the window)? A DynamicFont handles it nicely but of course it does not have the option for drop shadows, gradients, outline strokes, ... it had such things in 2.x and for now it was delayed for v3.2 (stable is 3.0.6 for now).
Argh. Think I need to set the scale of the "HUD"-canvas layer according to "original/designed resolution" and "current resolution". Might look a bit ugly/blurred then. Hmpf.


bye
Ron

Our today's annoyance comes from ... "_physics_update(delta)".

To ensure that something is updated at a fixed rate (read: amount of times in a fixed period of time), one should use "_physics_update". So ... what are your assumptions on what it does? I assumed that all objects (doing physics or setting to do so) are run at the very same "tick". Means a all get their "_physics_update()"-call right after each other.
NOPE ... they don't.


player physics Player
player physics Player
player physics Player
player physics Player
player physics Player
player physics Player
player physics Player
player physics Player
level physics
level physics ... done
player physics Player
player physics Player
player physics Player
player physics Player
player physics Player
player physics Player
player physics Player
player physics Player
level physics
level physics ... done
player physics Player
level physics
level physics ... done
player physics Player
player physics Player
level physics
level physics ... done
...


So some stuff is more often updated than others. Argh. This is not nice Godot! You tricked me again!
I used the physics update to do the usual
oldPos = pos
pos = new calculated position
thingy ...

This allowed me to check if an object changed its grid cell. But during dev I wondered why other objects "sometimes" recognized a change of other checked objects - and sometimes not. If you now know that some objects get updated more often than others it is clear that my approach no longer works (old position is already 7 times set to a newer position which might be within a new tile grid cell).
Back to the drawing table...

... first try will be a "signal relay" (units emit a signal about "having changed grid cell now", level registers for this signal [needs to be done for _EACH_ unit individually!], level relays this signal to other known units/tiles which are interested in it - i.e. the ones on the affected old/new tile grid cell).
The odd thing for me is the fact that a "one to unknown"-signal is not possible (kind of a broadcast). I would prefer a "emit_signal(no target, signalname, params)" which is only received by ones listening to "signalname". But this option is not available yet - and I would need to code it on my own.
... using the dirty Godot-everybody-knows-everything approach each unit could straight inform the level about changes (which then informs all other ones) - signals are just there for "decoupling" but I do not know if signal listeners get disconnected when deleting objects - do not want to create memory leaks.

Seems things become a bit more messy if you cannot "click/drag together" stuff in the visual editor.

bye
Ron

Ok, so made it "dirty" and units/tiles just inform the level/grid if they changed tile position meanwhile (entering, leaving, ...).
So finally "switches" and "wall blockers" work as intented:



As you see it misses an effect if the wall goes up while a unit walks over it ... think the unit should get thrown out of the map ;-)

I really enjoy how the map lights up when the enemies engulf a bit. Think it is enough for now - job coding has to get done and upcoming weekend time is family time (except they are all asleep).


bye
Ron

Got "knockback" and "stun" of enemies working. To achieve this I needed to introduce a "last tile" (used, not "tile during last update"). This allows calculation of a movement vector - or simply checking if enemy comes from "left/right/..." to knockback the enemy in the right direction.
Knockback is used to allow burning enemies while also being able to get hit/killed by burning enemies.

Together with that I added a "Jump To Grid Tile" function (including some "up-in-the-air, move, fall-down" animation). Using functionality I used (in a different way) before feels nice - as you come to results fast and without googling around ;-)


Current issue of this lunch-breaks-coding-session: "TextureButtons" (parent: Control node) do not emit signals while they should. I am pretty sure (but surely failed somewhere) that I did similar to a tutorial about this thing. Button press-signals seem not to get emitted. Grr.
Nonetheless a simple screen transition code base was established (for now: fade to black, replace screen, fade from black to transparen/screen). Will add some nice "swish"-decoration elements (running/flying scarab ?!).

Think for now I will have to skip many game elements I "planned" and just create a basic game with all required elements.


bye
Ron

Still fiddling with the button not emitting signals ... but layed that aside and tried to come up with some "GUI" and "HUD" stuff.

Trying for half an hour now to use a sprite atlas as source for a ninepatch rectangle. I mean... for me it is obvious to have HUD/GUI sprites designed on a single image. So best thing is to just set up the coordinates/dimensions for such a sprite in the editor and then use this sprite for whatever I want it. Right? But seems Godot is (again) not capable of doing a specific thing. You can save the sprite you configured "on" your sprite atlas. But once you want to use this sprite as source for a ninepatch rect - it uses the whole image again. Seems as if "coordinates" are absolute and not "sprite relative" (which would allow usage out of a spritesheet/atlas). As the ninepatch thing configures as "left col width, right col width, top row height, bottom row height" you even cannot trick around (eg. one could define top left x,y,w,h, top x,y,w,h, top right x,y,w,h ... and voila, no trouble).

Means at the end I need to cut my spritesheed by hand/tool just to make it work "somehow" in Godot. Editing a bit within the GUI? Cut it again afterwards ... WOW, such a timesaver, not!

I see limitations all around the corners and it feels more and more as if I used a Flash-game designer-toolkit.
Nonetheless I am aware that there are surely some other options to achieve what I want in Godot - but hell, it is hard to find solutions within minutes - I do not want to search the internet everytime I want to use a feature I just _expect_ from a toolkit like Godot. Regarding 9patch: in my DIG-Framework it is not a big portion of code enabling what I described above and source of my ninepatches can be single images or spritesheets - did not try animations yet but it is the same: another sprite on the sheet which gets cut into 9 pieces.



Edit: Aeeehm... whatever. Did not change anything but now - it works as expected. At least a "NinePatchRect" can now use a portion of a SpriteAtlas. TextureButton still does not handle the 9 patch button (means: no scaling). Maybe it has some caching issues, I just checked and unchecked a box and resized the button - and the ninepatch "snapped" in - instead of using the whole texture it now properly uses the small sprite. I do not know what to say - such "bugs" are annoying as you now never know: is this a bug in the editor, or is this feature in the engine bugged? grrr.
And as it is surely not reproduceable I even cannot file an issue.
So for now I would need to code my own "Button" behaviour on top of a ninepatch sprite.
I think it is not worth the hassle, as this also means for "nine-patch stuff" I need to code my own "progress bar", "input" ... and the likes.


Fighting a "bug": 30 minutes
Crying about it in the syntaxbomb forums: 10 minutes
Lost time of my lunch break: 40 minutes in total

Mphhhf!

bye
Ron

So...would you use this godot thing by choice for a project that was your own free choice normally? Or is this just a learning experience?

I want to use it (or Unity) to try out more things than just BlitzMax for "game/tools", Java for "applications at work" (some android stuff) or php/mysql/jscript when it comes to websites.

There must be a reason so many use Unity for games - and especially for "3D" there seems to be no convenient solution for BlitzMax - if you are, like me, an absolute beginner when it comes to 3D games programming (while I have ~20 years of "amateur experience" in 3D software).
Godot is open source - which I favor - so I thought I will try it first (instead of Unity). Thought that it will surely provide what my "simple games" will need.

So - yes - for this competition I wanted to try out something new, Godot. I always aim to learn something new with these competitions (eg. in Blender: better texture painting, workflows for 3D assets from 3d tool to 3d engine). I am pretty sure that other "similar" games (tile/gridmap based things) will be easier to code in Godot for me from now on and so it is a potential software for other little games. As said I am surely most often fighting myself instead of (the software) Godot.



bye
Ron

OK, fixed that "buttons do not react to clicks": my screen transition element(which is on a layer on top of the game) contained a "TextureRect" which overlayed everything. This "TextureRect" is not a simple "texture rectangle" but here in Godot it is extending "control". Controls are there for GUI/HUD stuff - which means it seems to listen to mouse/input interaction. I needed to set mouse interaction to "ignore" and voila... it goes "through".


Editor screenshots:
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FU7Dy6Su.png&hash=d246be5a3c63fc9e628ea3c06f6228687d78e765)

(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FpeTCQA7.png&hash=d9738a75259f8bc93dee81f62c31943a7503bcec)
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F0EOVPYy.png&hash=6d63358799ffbd778ce309b65ff3d8ce4cdb97da)
(as you see - with ninepatch I need to handle my own "normal/hovered/pressed"-visual representation stuff)


Lol: seems syntaxbomb and Godot use the same gray tone... :-)


Ok, family will arrive soon, so coding for today seems to be done. At least a "issue" solved.


bye
Ron

QuoteLol: seems syntaxbomb and Godot use the same gray tone... :-)

Huh! that's pretty weird :P

What person in their right mind designs a coding theme with a bright white background and black text?!  #eyestrain.  Dark Theme all the way for me!

Odd behaviour of today?
I added some "spawn creature triggers" (will get replaced with sarkophags or so). They spawn creatures at the given grid.

To do this you have to:
- create an instance of the creature object (in Godot: "scene")
- move it to the desired position (set/adjust translation of the instance)
- add it to the node tree (so it gets rendered)


This is exactly what I do - so translation is done right before it gets added to the node, aka it is moved before it can get rendered. But still added ones are first rendered at "0,0,0"  and are then moved/"snapped" to their target position.
I also "debug printed" some stuff - and it claimed to have set translation as I wanted it to do.



func AddUnit(unitID, col=-1, row=-1):
var unit = preload("res://Scenes/Creature.tscn").instance()
print("AddUnit: ", unit.get_name(),"  translation=", unit.translation)
if col == -1 or row == -1:
var tile = GetRandomWalkableMapTile()
if tile:
col = tile.col
row = tile.row
else:
print("no tile found")
if col == -1 or row == -1:
print("no free slot found")
if col == -1: col = 1 + randi() % (mapCols-2)
if row == -1: row = 1 + randi() % (mapRows-2)

unit.set_translation(Vector3(col * TILEMAP.TILE_SIZE, 0, row * TILEMAP.TILE_SIZE))
unit.RefreshGridPosition()

AddMapTileObject(col, row, GLOBAL.GROUP_HOSTILE_CREATURES, unit)
print("         -> grid=", unit.gridCol,",",unit.gridRow, "  translation=", unit.translation)
emit_signal("unit_add", unit, col ,row)
return unit


output was:

AddUnit: Creature  translation=(0, 0, 0)
         -> grid=6,2  translation=(12, 0, 4)


So as you see it correctly changed object's translation ... I even removed potentially interferences and really cut it down to:
- create instance, set translation, add to node tree
and it still ... has this annoying visual "jump". I must have missed something. grr.


bye
Ron

What if you set it to invisible for one frame first?

Yes, invisibility or having some kind of "getting added"-animation (scale up, fade in , ... whatever fits) was on my "circumvention list" already.

But I want to understand why it happens at all. It is not a threaded build - so I assume "adding + placement" is done straight each after another. I am pretty sure that I have done something somewhere (checkboxes, or similar) which I shouldn't.
I cannot see this happening for some other items (the collectible "yellow boxes" for now).

Will try to fix it at lunch.


bye
Ron

While on initialization of such a spawned item an:
visible = false
yield("0.05 second"-timer, "timeout")
visible = oldVisible

"covers" the initial bug I tried a lot of stuff. It's not an attached script issue (replaced the script of the creatures with that of the collectibles). Thought maybe physics are the culprit (I have a particly system attached to the creatures but not the collectibles). Seems not to be the issue too.
Argh...
Ok, so leaving on the "invisible"-fix for now.


Meanwhile I got another issue: when the player dies it actually does a "StartDying()" and a "FinishDying()" (so I could play animations properly - or just extend whatever happens in that moments in extending types/classes).
When tween for "dying" (swirl, scale to "up to zero") ends, a signal is emitted automatically (inbuilt signal) - "tween_completed". For exactly one time a single listener to listen to this signal is registered (I print out a "connected to signal" right below the connection-establishing - and this line is only printed once). I also gave the "to call" method/callback a unique name so that other scripts might not interfer. When I start the tweening process I also print out a debug message - which is also only printed once.
Ok ... so guess what happens? This signal listener is called twice in a row. How can this be ... ? For now I could fix that by only reacting if a certain flag is set.

I feel a bit lost by fighting all these little annoyancies.


bye
Ron

Grr.. ok, that signal issue is ... I would call it not a bug but a missing feature.. in a "Tween" node you can chain up multiple individual tweens (eg. one for location, another for scale and a third for rotation).

Tween (as of now) emits a "tween_completed" signal for _each_ of these individual tweens - but none for "finished with everything".

This is the reason why I received the signal multiple times. Means I need to take care for myself how many "individual tweens" are stored within one big "Tween node" (and subtract then for each finished - only reacting then if the last one finishs). Annoyance!


Edit: seems in v3.1 this _will_ be fixed in a way that "tween.is_active()" returns false once all tweens finished. A pity that I am at the latest release: v3.0.6.

bye
Ron

Sounds like Godot is as much a WIP as your game :o - Keep plodding on though and finish :)

Yes I will try. So this weekend was/will be short (next family party - big families need multiple parties to get all under one roof ;-)) but at least I got some basic:
- start menu (needs some more love put into design ...)
- player can die (burn baby burn!)
- game over notification
- score notification
- basic HUD elements/icons

plenty to tryout/do:
- open final door/reveal final treasure to fetch/ ... once you collected all requested elements
- add music
- add sfx
- create player / enemies / collectibles + animations for walking/raise from the grave/ ...
- create difficulties (more enemies, more traps ...)
- decorations for the level (make it look "nicer")

pheww. At least some of this stuff is done in Blender so should create _less_ trouble ;-)


bye
Ron

OMG! looks like you've an arse load still to do :o - Better ring the family and tell them to stop visiting so you can finish it off ;D

Lunch time used to create some simple tiles:
- door with border and stairs
- some ground tiles to potentially cover objects going below "ground" (eg. stairs or moving-down-doors at the bottom of the level)
- sarkophag (including simple "open" animation)
- painted backsides of the walls :-)

(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FMMXcHbo.png&hash=312d91ecff46c706122ab811e9ad39d63c2b32d9)


Let's see if this evening offers me some spare time or not. Wifey time can be everyday so ... surprise surprise.

bye
Ron

Coming on nicely - very Aztec.

Nice building work ;D

Think you all know how enjoyable bug fighting is ...

You surely remember how I spit on dynamic typed languages in this thread a bunch of times.
I tried to "match arr[0]" (like a "switch" statement...).

match arr[0]:
  1: bla
  2: blubb

But it did not execute one of them, why? So I did a print(arr[0]) and its output? 1 (or 2, 3, ...). Hmmpf, so why is it borked up?
Solution here was: arr[0] was not an "int" but a float/double/whatever (I initialized it with "Vector3(0,1,2)"). So casting it to an integer resolved the issue and the match worked:
match int(arr[0]):
  1: bla
...

This is a bit of... frustrating/annoying/... grr.



Gamewise I had to fight the pathfinding/a-star this evening. I do not have only static content but also dynamic blocking things. This means I need to update the astar nodes after every change (actually I wait up to 1 second - so AI does not react to changes within a blink). As soon as I did this I had a little jitter/stutter on every astar update.
Replaced a "loop over dictionary to find neighbour element" approach with direct index calculation and the hickup was gone. Seems you should never try to do as some tutorials suggest (slow!).

To have an happy end for today (had some business coding too)) I also added the "final door" of a level ...do not go into the white light :-)


bye
Ron

Todays evening was full of ... coding stuff I coded for my BlitzMax framework "Dig2 already: a SoundManager.
Similar to Qube's idea of a soundmanager class my autoloaded singleton contains some simple "PlaySfx(streamOrStreamUrl, volume)" and "PlayMusic()"/"PlayPlaylist()" functions.

As you might know ... Godot does things differently. So for each track I wanted to play I needed to create a new "AudioStreamPlayer" (which again needs to get added to the node tree). So far so good. Then I've read that .ogg files are imported as looping while .wav are by default loaded as non-looping. Ahh yes. I prefer to adjust things in the source code (an .ogg sfx file should be non-looped). But that is this visual-editor-paradigm.
Ok, so I got some music playing. Time to code the cross fader stuff. Godot does not inform myself when it reaches the end of an .ogg file so I have to take care of it myself. Why should I do so? Ok, to keep things small I do not want to add long music tracks (also they might cost money if you cannot compose them on your own). So I use some smaller loops and repeat them some times and after eg. 3 loops were played, it now cross fades to the next "looped loop".

But what was this? Crossfading did not work until I checked "volume_db" has this appendix "_db" not for nothing but for decibel. So I checked values for decibels and what Godot expects. -60db for silence, 0 for "maximum loudness without clipping". Added some ValueToDecibel() thing and 15 minutes later I found out that Godot already offers a "linear2db()" function doing exactly...the same.

Nonetheless - and 3 hours of coding fun + searching/creating some simple effects I now have working background music (fading nicely into each other) and I can play sound effects to my needs.
I already decreased volume of the death sounds as ... it takes out some fun if you let many of them burn. So better some silent "woahhh" sounds than feeling like in a horror movie.




PS: of course the colorful rectangles are only there for debugging purposes - so pink will get replaced by a sargophag nearby etc.



bye
Ron

Looks fun ;D - Not sure if you're going to change this but I wouldn't have the in-game background music louder than the sound effects. Also I'm getting used to those placeholder squares so it's going to be a bit of a shock when they are gone. Goodbye faithful squares, you served your purpose well  :-*

Music volume was reduced (to 75%) while recording.


Bye
Ron

Added "short walls" which are used to add custom decoration stuff (todo ... pillars or so) and sarkophags (which spawn a mummy...). Code replaces "end walls" (with no further connection) with "short walls" so there is some area freed to add a half-tile-element.

Added "sarkophag"-animation-connection and controlled unit spawning + "forced routes" (so AI follows a given route first before doing their own movement decisions). Means now the sarkophag opens, creature leaves and once it reaches its target grid it begins chasing/idling.
Also added stuff so player resets when loosing a live and creatures get removed too.

Nothing more this evening (came home late - and had some glasses of booze next to the default BBQ-beer ;-)). It's never good to have 28°C in October.


So tomorrow will be only lunch time and maybe some hours in the evening - still need to create at least a half-decent player model (+ animation-export which I did not tackle in Godot yet), a mummy model and the collectibles need to get designed too.

Not to talk about stuff I modelled but did not yet animate nicely (traps). Normally I would like to add some blood particles here and there ... arghh too much to do for a sleepy and boozed brain (~6hrs and the kids will be awake ready to "papa I want you to play kitchen chef with me" or to "gurggl gurrgl" aka "I want milk mama").


Seems at least some others already finished in time.


bye
Ron

Lunch time:
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FLfle9XZ.png&hash=65d9495f59e4472f32905939eb233755f9e5ca8d)

(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FS50CI4v.png&hash=110d427f1dccbc79ac2a670945cac7bb0c9015b4)


But the "dull" colors (they are "worn") it is no longer so vibrant and "distinguishable" on the similar-colored level. hmm. Nonetheless: family time now.


bye
Ron

Love the Mummy ;D - Is it animated? if so do you do the animations yourself?

Quote
Love the Mummy ;D

I agree - good job!  Come on Derron, work while family sleep to get this completed in time.

Kids brought to bed ... back on the computer.

I came up with some small ideas during playing in the park:

1)
Add a simple circle-shape below units. The circle could be colored according to "hostile", "collectible", "player"
That way you could easier spot the interesting stuff

2)
Darken the floor to make units/items pop out even more. BTW all the textures are hand painted.

(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FPXtBodw.png&hash=1d4109113ea4cf80f55ece7066bbeeb271de4753)



@ animation
Certain animations will be done by hand but I thought on trying to use "BHV" files (to learn that too). Nonetheless I first have to rig the models now. I had to reduce polycount a bit ("Peter" is now 4k polys including hat and mummy is 2.5k poly - especially face is more high res albeit not really needed in that camera views) and something borked up my old rig setup (included a scale I do not want to keep).

The mummy had a better paint job before but when I put it into the game it was so barely visible it could not stand. You need to "exaggerate" when it comes to such small units.



@ textures
It is a mess for now .. I tried to have only 1024*1024 textures but this leads to jaggy lines here and there. No time for a proper unwrapping/UV layout. Only done some seams here and there and rely on a simple unwrap then (+ repositioning the UVs so that multiple stuff can get placed on one texture).



Ok, back to Blender now.


bye
Ron

That does look really good.  Having a map on the left seems odd though - a map should always be on the right IMO, plus there is less user information there on the right - so less cluttered.

It is a debug-map ;-)
... as this "closeup" was not intented yet - albeit I thought about a camera mode for a more intense gameplay (...not knowing what comes next).


bye
Ron

A camera zoom when things get more intense perhaps?

It's starting to come together.  I hope you finish it or at least have a playable game for us.

Animated mummy: awakening (raising arms and so ...) and also added a walking animation.
Animated adventurer: walking, idle, fire holding
Getting the animations from Blender to Godot was a bit of a pain - the "godot exporter" somehow failed to export animations (with my files - and also the sample files provided by the exporter). Fiddling around with all this stuff took ... literally hours.

So for now I need to export ".dae" (collada) files as they at least contain the animations.


Also I had issue with some materials (if you want to use vertex colors rather than image textures for everything). Also Godot had issues with some objects - hat had off-normals while Blender stated all normals were as expected.

Animations have to get "morphed" too (idle - walk - walk fire - ...). TODO for tomorrow.


Am not really liking the new look (got used to the placeholders ;-)) of the "skinny" characters. Nonetheless... time for bed, kids are awake in <5hrs.


bye
Ron

Ok, kids in bed - lunch/nap time wasn't successful today (only ~1hr "spare time").

so ... 4 hours to go now. Want to at least create a semi-acceptible startup screen, and 1-2 game elements need to get done. Maybe I even achieve to design the gameover/win screen rather having some monotone-colored rectangles with text :-)

No words about option screens, key configuration and the likes (would have that in if I could reuse code from my BMax framework ...).

And yeah - then hope that exporting for win32 works as intented.


Time for some nice music to listen to... German punk vs 70s. Ok, let's start with "The Sound of Silence" ;-)


bye
Ron

Wife nagged to do some houseworkstuff ... so meanwhile I (started to ) render out the startup screen:
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FcSRe8kj.png&hash=1227e46af0cf0006f42f6ecaee0962dcb943ab6b)

Hmpf, time is running out soon.


bye
Ron

I'm sure if you asked nicely you could mention deadlines  ::)

Render looks great.

Ok, so for "now" I am done with the "game".

I enjoyed adding stuff here and there - once I got used to the "Godot way" of doing things. AND once I prepared a lot of stuff to "reuse". Means once my tile interaction scripts were written it only took a couple of minutes to create a tilemap item which kills the player after it has thrown him into the air and plays a little blood particle fountain meanwhile.

Until you reach that state Godot throws many, many, .. many stones into your path. GDScript and "previously freed instances" were the most annoying things.
When exporting animations as "escn" they are missing - when exporting as ".dae" (collada) then you need to make sure that your meshes are not posed during export as some "local transformations" (eg you only rotate a specific bone instead of starting with "rotate from X"). Blender displayed them as I wanted but in Godot you somehow had the hands moved into the head and such oddities ;-)
If the deadline is already visible you do not want to have to learn how such things work. It "just should work" ...

So at the end of the compo time I at least tried to create a little icon - created a proper .ico file but seems Godot neither likes that one - nor the one I created with "imagemagick". Hmmmpf.

When updating assets (eg. saving them in the project folder with your painting programs) Godot displays an updating-asset-window. Nonetheless my controls/HUD did not reflect changes. You need to click into the ressource-gui-widget of the texture and hope that it gets refreshed then. Sometimes you need to double click on the corresponding .png file in the file browser of Godot - to make it refresh. Nonetheless the "scene preview" (where you move things around) does not reflect it then. It needs a "extend"-checkbox check-unchecking to refresh.
I think there are plenty of little bugs in the Godot editor which needs to get tacklet - and which are surely mentioned already multiple times.

If you want to change the material "tint" of an item you need to:
- open its scene
- click on the mesh you want to adjust
- right-click on material and "make unique" (else you adjust other instances)
- click on the material
- click on albedo (or what you want to adjust)

It is surely also possible to do "by code" but ahem ... steep learning curve or so?



All in all: export was pretty easy (add the target, set "64bit or not", set icon (which does not work for me) ... and export it). But hey - it does not compile stuff. It assembles all assets and packs its runtime (ready made for all targets already) next to it. So I already assumed that it works "easily" (which does not say that the release works for everybody).

I can assume that certain little games work pretty nice in Godot - eg. Holzchopfs little Train-Brainer caught my attention - 3D trains? ;-D). The more "complex" (read: many different thingies) the gameplay becomes the less I would suggest a usage of Godot. As therevills wrote: you feel "dirty" or "hacking" when doing your coding in Godot. Things get messy pretty much if you are used to a different way of organizing your assets/code. Of course things would absolutely differ if I would do another little game (maybe finish it this time? ;-)) with Godot but hmm I would again only use it for 3D games as for 2D I have my beloved BlitzMax (NG) - which only misses a proper HTML5 output/target.

Maybe in some months the economy system around Godot evolved a bit and it provides "premade stuff" like Unity does. Checkout Qube's little gem/game and how fantastic it looks: in Godot you need to create all the little effects "from scratch" which just takes too much time (even if it can be fun to create certain stuff there).


bye
Ron

Oo, I like this game and it has a really nice atmosphere about it. Glad to see you managed to get it in in time :). Great work on the title screen render.

I think you and I can happily say "We learned a lot during this comp and things would be oh so different next time in our approach" :P

..i like art style/textures for mummy..atmosphere looks really nice..

Derron, just a quick report that I'm playing the Mac version and on the game over screen hitting space to continue actually doesn't. I have to restart the game to play again. Not sure if it's just the Mac version that's doing this but maybe nobody apart from me has used it yet?

Quote from: Xerra on October 17, 2018, 22:34:08
Derron, just a quick report that I'm playing the Mac version and on the game over screen hitting space to continue actually doesn't. I have to restart the game to play again. Not sure if it's just the Mac version that's doing this but maybe nobody apart from me has used it yet?

Yeah, I found the same issue as you. I didn't report it as I assume the Windows version works fine and most people would be playing the Windows version.

So in the start screen "space" does not lead you to level 1 too?
And in the game "ESC" does not lead you back to the start-screen?


In the start-screen I use:
if Input.is_key_pressed(KEY_SPACE) or Input.is_key_pressed(KEY_ENTER):
...


In the game screen I use an own solution which stores the same function but caches it - so it reacts to "was pressed".  The difference is that the first one is repeately fired (hit it and it is true for each "loop"). For a screen transition this works well as the scene changed in the next tick then. But during the game key presses need to get only fired once for "down + up".


This is my simple code (maybe one spots the bug already?):

var keys_pressed = []
var keys_was_pressed = []
...

for key in [KEY_TAB, KEY_SPACE, KEY_R, KEY_F, KEY_T, KEY_J, KEY_P, KEY_ESCAPE]:
if not keys_pressed.has(key):
keys_pressed[key] = false
keys_was_pressed[key] = false

if !Input.is_key_pressed(key) and keys_pressed[key]:
keys_was_pressed[key] = true
else:
keys_was_pressed[key] = false

if Input.is_key_pressed(key):
keys_pressed[key] = true
elif !Input.is_key_pressed(key):
keys_pressed[key] = false

...
if keys_was_pressed[KEY_ESCAPE]:
SCENETRANSITION.FadeTo("res://Scenes/Scene_Mainmenu.tscn")



bye
Ron

QuoteSo in the start screen "space" does not lead you to level 1 too?
And in the game "ESC" does not lead you back to the start-screen?

Space works from the start screen and ESC works in game. It's when the game over window appears that space doesn't work. Also when you press 'P' in game, the game will pause but the timer still counts down.

Can replicate it.

...and fixed it.
Reason? My scene-transition is a "node". And when going "game over" I pause the game. Game pausing is done via "get_tree().paused". While I did not add my scene-transition node to the tree it somehow landed in the global tree (think everything lands there). Means when paused, the whole script was no longer processed. Which I did not "remembered" (just had a debug print when starting the fade - and it worked, so I assumed it was called correctly, ignoring the fact that it was no longer "updated" then).


So solution was to add

func _ready():
#fade in all cases
self.pause_mode = PAUSE_MODE_PROCESS


to my scene transition script.


I updated the download links to link to the new v0.8.1:
- visual indicator for pause mode is now visible too (to avoid bug reports about stuck figures)
- "space" during game over for start-screen works now

https://www.gamezworld.de/files/mazeraider/Maze_Raider.Linux64.7z
https://www.gamezworld.de/files/mazeraider/Maze_Raider.MacOSX.zip
https://www.gamezworld.de/files/mazeraider/Maze_Raider.Win32.7z
https://www.gamezworld.de/files/mazeraider/Maze_Raider.Win64.7z


bye
Ron

That works :)

But... I've found some more bugs :P

1.. On the title screen if you keep pressing space it repeats itself trying to fade out the screen to start the game.
2.. When playing the game if you repeatedly press "R" to restart, after a few presses the game crashes.

Gotta keep you busy ;D

Quote from: Qube on October 17, 2018, 23:52:38
That works :)

But... I've found some more bugs :P

1.. On the title screen if you keep pressing space it repeats itself trying to fade out the screen to start the game.
2.. When playing the game if you repeatedly press "R" to restart, after a few presses the game crashes.

Gotta keep you busy ;D

To add to this, repeated pressing esc in the game (I know you wouldn't do it normally but ....) will just keep kicking in the fade transition.

Music and sound have stopped working in the new version. Qube did you get this too?

QuoteMusic and sound have stopped working in the new version. Qube did you get this too?

Just shoved on my headphones and can confirm the sound and pretty great music has vanished :o - Derron!!! fixy fix fix!!

Yes, dev-silenced the audio ;-)

@ fade
Yes - I can disable that - actually will do that when I brought the older one to the kindergarten (in 5 minutes)


@ reset crash
Yes - I assume this is a "previously freed bla" error - something wasn't cleaned up in time (while of course I have a function doing exactly that when removing something from the "layer object maps").


bye
Ron

Upped v0.8.2

- "ToFade()" skips starting a new fade if current fade-to-scene and new-scene differ
- re-enabled music/sfx which I switched off during adding of fixes in v0.8.1 (wanted to listen to other music meanwhile ;-))

Same links as above. Thanks to you bug reporters.


@ Qube
Hmm, I reset the level now about 60 times in a row without a crash. Thanks to low loading times this is not that bad.


bye
Ron

So far when playing it I've not had any further problems. Good job, Derron.

In reply to Steve Elliots post:
https://www.syntaxbomb.com/index.php/topic,4971.msg20175.html#msg20175


Yes, music should be "in the background" - and initially I had it cut to a total of "40%" (now it is at 80%). For a "after compo" game I could add some more options to adjust it - but I am not sure if someone is really playing it any longer than the competition time. Life span for a such compo games here is ... pretty short. It is almost a "fire and forget" thing (which is often a pity).

On the other hand any improvement "GUI wise" (options dialogues etc) can help speeding up other projects done in Godot - which I for now doubt to do in the near future (but you never know ...).

BTW I prepared some more SFX (when punching the mummies with your torch etc.) but hey, I kept them where the other extra tiles (vanishing ground ... so hurry up to not fall down, shooting spikes from the walls ...) wait for a potential further game development.

----

I just found something little to fix:
- start menu font of the "version text" was incorrectly using a bitmap font instead of a normal text font and so it cut version string
- SFX nearly not recognizeable because of too loud music, decreased music volume by 25% (60% instead of 80%)

Downloadlinks kept the same.


bye
Ron

Quote
Yes, music should be "in the background" - and initially I had it cut to a total of "40%" (now it is at 80%).

80% is madness.  Watch any film, it's always subtle.  The sound effects are crisp and loud, the music simply enhances.

80% of the "non normalized audio" (I was not sure if I was allowed to edit the "playonloops.com"-audio). So it might be less than "80%".

As said - I cannot make it configurable for now but as one stated I had it less loud in a prior version I at least cut it down a bit again - seeing it as a fix (not a _show_-stopper but a _listen-to_-stopper ;-)).



bye
Ron

Perhaps deafening a user can be considered a bug?   ;)

Love the splash screen, wished the main game had a isometric closer view to really see the fine detail you created on your models!

Attach is a screenshot when zooming in and it looks like Godot has messed with your Indie model :(

What is your work flow for creating your graphics?

@ messed model
This is what I described in one of my posts - I exported it correctly but hmm, somehow it messes it up sometimes.

Another annoyance is: if you set up the "AnimationPlayer"-animations within Godot it does not "reset" afterwards. So if you played your animation "once" to check it out, it stays at the end position even if the animation is not set to be "played already".


I now checked if the default pose is correct on load - and it seems ok. I just notified that Godot seems to has issues with non-manifold models (no models not being "closed" everywhere). While Blender renders without issues Godot seems to run into some trouble (see the orange lines peek through?):
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2Fs9KAE7c.png&hash=24c7778f9e2fc755ce1235a2e15b6e55c67a78c9)


Now let it play the "stand" animation, which does nothing more than keyframing the above default position:
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FC7IplhJ.png&hash=7c1bcde841d9fbbf4693f8677938169ec48186bb)
Hey, does not look "defaultish" anymore.


I think Godot has issues either importing - or its Blender exporter has issues on exporting - IK animations. I just saw that for the fingers only the middle finger has a whole key-frame set while index-finger and the likes only have a "start and end" keyframe. Think that might be a bug worthy to report to Godot.

Please excuse this annoyancy - it's my fault to not have recognized that earlier.


@ workflow
I model, paint, ... them all in Blender. I then export single "selections" ("scenes" are not useful for a manual-tilemap-approach) via either "godot-exporter" (.escn files) or "better collada exporter" (.dae files). The "godot-exporter" had issues exporting my animations (in other words: the "animation player" contained no animations or export failed at all). The .dae files contained all my animations. For material see below.
Once the file was exported I either "doubleclicked" on them in Godot and created an inherited scene - which I then saved ("unit.item.collectible.tscn" or so) and added a script for its behaviour. Another option is to have a scene already (eg. with a "root node" and an "offset node" - so you can move stuff without the entity leaving its "grid position" - imagine a little bug walking around on a tile programmatically not via a ready-made-animation. I use it for the "get spiked = jump"-animation) - another option is to link to such an existing node. You click the "second icon" next to the "+" and then select the existing .escn-file and there the base+child-node you are interested in.
Sometimes Godot is capable to use the material you set up in Blender (while "mesh - material" stays at "null" then ... odd!) and sometimes it does not do that and you have to select the mesh and open the material - and drop a saved material file on it (I saved the "wall tile" material in a file so all walls can share the same texture intance, material setup etc - only UV setup is individual).
The textures were copied separately/manually to Godot by me - there should be some automatic but it did not work in all cases (think material name issues).


bye
Ron

I tried various "IK to FK"-addons which want to auto-handle this issue but hmm, seems they all have different issues - the first one lead to "no animations but one", the second did nothing - and the third (manual way - baking animations step by step) had similar issues: if you did not animate a bone (so it stays at "default") then things really rely on the start position Godot assumes.

Also I am not sure why having some animations in it leads to a ".dae"-file growing from 2.8MB ("only the idle animation") to 7.8MB (all animations). I mean, it is only a set of transformations...


Will try more after noon.

bye
Ron

Quote
Love the splash screen, wished the main game had a isometric closer view to really see the fine detail you created on your models!

Yes totally agree.  There's some really nice graphics here that kinda get lost because the camera is so far away from the action!  But you did allow camera movement keys so that makes up for it in some way.

A very nice little game.

Hmm ... tried for 90 minutes now:
It seems the exporter addons somehow try to bake "IK to FK" already - still they fail.

I removed all other animations (same rig as the mummy, so no "awake" is needed).
I created multiple a test animations in Blender:
var 1 - keyframed all "IK" bones at frame 0 and then only the adjusted ones -> still "ugly"
var 2 - keyframed all bones (IK and FK) at frame 0 and then only the adjusted ones  -> same result

When it initially loads, the pose in which it got exported is used - right. But as soon as I select _one_ of the animations, it borks up:
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F9frgWDP.png&hash=326e2fe825e31ca5e4e49ee3af3767f371f7090e)

I have no clue why this happening - and I seem to trash my spare time instead of using it for something "useful" :(


bye
Ron

@Derron>>the models look nice, but why make them so detailed when the camera is so far ?


About animations, how do you make them, do you make the poses with your body and then try to recreate them in the animation tool ? (i have my own method, but i am curious)

@Derron>>about your issues with joints and animation poses, i already have seen a similar issue :

a skeleton/rigg is made of joints ("bones")
in an animation software, you have 2 modes :
one to create the skeleton/rigg with joints (the Tpose)
one to create the animation with poses

the thing to keep in mind is that the orientation (pitch, yaw ,roll) of a joint in the TPose (on the skeleton/rigg) is not necessarily 0,0,0 (because you may have rotated it by mistake or because the rigger/animater/exporter did that)
it often happens when you try to merge existing animations exported from one software to another or from one character to another.

so if the initial orientations of the joints (in TPose) are not 0,0,0 , then when it is animated, it looks weird...
same thing with the initial scale / animation scale of the joints

Quote from: Derron on October 20, 2018, 07:04:16
Another annoyance is: if you set up the "AnimationPlayer"-animations within Godot it does not "reset" afterwards. So if you played your animation "once" to check it out, it stays at the end position even if the animation is not set to be "played already".

Yep, I got that many times in 2D too! I was fading out the dead and had left the animation at the end of the fade so you couldnt see the sprite, started the game and couldnt see any of my sprites!

Quote@ workflow
I model, paint, ... them all in Blender.

Wow, all in Blender - its been a while since I looked at Blender, could never get the hang of it.

@ RemiD
Think you described something similar to what I found out yesterday (before leaving the computer for board games and booze :-)).

When I animate stuff in Blender, I of course pose the bones - and the bones are left in that position then (even if I play an animation which changes that). I did assume that this is not problematic as the original "T-Pose" (initial pose) is still there. If I did not set a specific action track ("various aligned animations") it would show that initial pose too.

And way more important: as said I tried animations with "global" visual appearance of each bone (so a global XYZ, global rotation, ...) and "local" ones. Means each animation did define the position of all bones right at frame 0 of the animation. Somehow this did not work as expected. I think it has to do with the way the "better collada exporter" and "blender godot exporter" handle animations. With Godot 3.1 an IK Solver will be available - but for now this is not existing and so every animation is "baked" behind the scenes. This means a 40 frames animation is not storing the keyframes but the position/location/scale at each single frame. This explains the huge file size (7.8mb for a 2.5mb model + animations).

I assume during this export they do not use the global position but some other stuff - resulting in the odd behaviour if you do not reset your characters pose to "Initial Pose" (so no transformations are done to the bones).
In Blender this is fairly easy to do: go into pose mode, "a" (to select all bones), "alt + s" and "alt + r" and "alt + g" to reset scale, rotation and position of the bones. done.

When then exporting the animations in Godot look fine.



@ more details
I only left the manual camera movement on but I could enable a follow-the-player-thing too - if desired. It was a bit "bugged" and needs some more love before I would let it loose on the players.
I created the assets for: the game screen and for the startup-render-screen and also I wanted to learn a bit more about texture painting.


bye
Ron

About animations and weird poses, i saw a similar thing, when, by mistake, i had modified the orientations of some joints in "rigg mode" (when you create position / rotate the joints to make your TPose), and then the animations that i made previously were all weird (but in reality they were correct if the orientations of the joints in the TPose would have stayed at 0pitch,0yaw,0roll)

Similar thing when trying to merge an existing skeleton/rigg (from a motion capture app) to my own skeleton/rigg : the orientations of the joints in the TPose were not the same, so the animation poses ended up weird !

If there is interest I would upload a new version under an other Download link - so you can walk through the game in 3rd person (very buggy - which is why I disabled it) and a "follow player from bird perspective" mode.


bye
Ron

Here is an extra download:
- exposed camera modes via "c" (attention: 3rd person mode is pretty buggy controlwise)
- reduced volume of music even more (hope it is better now)
- fixed an issue with UV layouts of certain walls (they were not textured properly)
- fixed (hopefully) the animation issue (borked up vertices on the adventurers mesh)

(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FqVTP9je.png&hash=09f28cf7eef0f819ab4fd8de7f6d79135a93b9c7)

Downloads (extra, so competition-downloads stay on old version):
https://www.gamezworld.de/files/mazeraider/Maze_Raider_v0.8.4.Linux64.7z
https://www.gamezworld.de/files/mazeraider/Maze_Raider_v0.8.4.MacOSX.zip
https://www.gamezworld.de/files/mazeraider/Maze_Raider_v0.8.4.Win32.7z
https://www.gamezworld.de/files/mazeraider/Maze_Raider_v0.8.4.Win64.7z

Derron,

As suspected I did download the Win32 version. Upon looking where the executable was stored, for whatever reason,  double clicking the executable failed to result in any UI being presented, I tried it 3 times last night and even double clicked the .pck file, although suspecting that also wouldn't work.

Double clicking the executable this morning, after a restart, it worked. Good looking game, sound is also well done, congratulations on your entry.

Thanks.

Hope other games got your further attention too (as said, giving votes with judging certain games only by a screenshot might be a bit unfair for the authors of these games). Giving feedback (positive, negative, ...) or reporting bugs will help us all for further games (to make them more compatible, less bug-containing, ...)


bye
Ron

Yep, all the games got my attention, I fully appreciate the coding mountains that have to be climbed to achieve even my paltry entries in some of the previous competitions. Everyone that submitted an entry has achieved so much in their own right. The ones that got my votes yesterday raised a smile when playing for different reasons, when your entry ran this morning, I was very impressed with the UI and gameplay. It's just unfortunate (for whatever reason), it didn't run last night. The nuances of PC's, that's what makes completing something as an indie so rewarding, when they work. For your info, I'd to kill the three exes I'd tried to run via task manager last night. There was no Admin rights required to run the executable this morning, it just worked.

Hi Derron - just come across this (as I was away)
My thought were looks brilliant, sounds great. really like the style
Then the game starts and the only thing left is the music. it's becomes a simple top down maze.

My question would be this:
Why not start with the full view as presented, then zoom right down so you only see a ver small section of the maze and therefore see all the lovely 3d details? maybe a 3x3 or 4x4 square showing?

Thanks for the (initial) kind words.
You can use WASD to try this out (move and zoom camera).

I even had a 3rd person camera - but it looked a bit "wonky" and I did not have the time then to perfect the smooth/lerping of the angle-movement (when turning around).
As stated some posts earlier: try key "c" to switch camera modes.


Also a "minimap" (for development) is already in the code and could get displayed too ... in a zoomed camera view.
I had plenty of ideas for the game but ... it does not have the attention (read "downloads"/awareness) to justify more invested time. So all these competition entries here... are most of the time just for this community.


bye
Ron

The C for camera mode is more like it :)

I did notice the lighting flickering on and off at times and also the controls did not help.
up/down to move forward backwards, but left right only works half the time.

But I did like the general look and feel :)

Controls... Generally or when in another camera view mode?

Lights flicker on off... Should not happen except when refilling/setting on fire your torch there.


Might have to upgrade to Godot 3.1 and export then, maybe they have some fixes.


Bye
Ron