Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

TurboHz

9
Posts
1
Topics
21
Following
A member registered Oct 12, 2016

Recent community posts

Haven’t tried it, but there’s also Depot.

Yep, it’s a shame. I really liked this app, and had lots of potential.

AFAIK it’s developed using Godot, and I’m sure I could fix some of the bugs myself. But, alas, it’s not open source.

Perhaps we could rally together to ask for the source code to be released?

(5 edits)

Found yet another bug:

When exporting to Godot, I had to change the export path, because it’s different in the different machines we use.

The export will report success even when the path does not exists, and no files are generated.

Furthermore, if you update the export path without restarting, the export will work (as expected?), but will write absolute paths in the Resource files, not relatives.

Restarting will fix the issue, and Resources will be exported properly, with relative paths.

Maybe not related, but I’m getting a crash when I remove an item that is used as reference somewhere else.

Confirmed issue in the latest version, v1.37.

(If I remove all the references to the deleted item, export works)

Hope it helps.

Found another issue:

Arrays of Resources are exported as:

export (Array, Resource) var attack =["preload("res://gridlessDB_data/constants/objects/Player.tres")"]

Notice the quoted preload

(1 edit)

Hijacking my own thread, I noticed this issue:

Entries in the same DB, with the same NAME, but different CATEGORY, overwrite each other.

This is definitely a bug, because different categories (probably) have some different fields.

(9 edits)

Hi, I’ve recently started using the addon (with Godot export), and I noticed some things that might be improved.

I’m using Godot 3.x latest

ISSUES

The exported resources (.tres) seem to have an incorrect load_steps.

Example (corrected by Godot to be load_steps=3):

[gd_resource type="Resource" load_steps=2 format=2]

[ext_resource path="res://gridlessDB_data/spifu_state/classes/Roaming.gd" type="Script" id=1]
[ext_resource path="res://gridlessDB_data/constants/objects/Normal.tres" type="Resource" id=2]

[resource]
script = ExtResource( 1 )
animation = "jump"
speed = ExtResource( 2 )
disturbable = 1
incapacitated = 0
lurking = 1

IMPROVEMENTS

No deal breakers, but will be things neater, will make feel nicer:

  1. Allow to export without “class_name”

    It’s very inconvenient to have the class name space “polluted” unnecessarily (since Godot has no namespaces).

    I use this very often, for type safety (and autocomplete) without registering a class:

    const Weapon = preload("res://gridlessDB_data/weapons/classes/Weapon.gd")
    
  2. Allow adding comments/description to fields schema

    Sometimes you need an explanation in addition to a descriptive name (could have a “i” info icon or something to display the comments as a tooltip)

  3. VCS friendly database format

    As it is, with binary format, its very difficult to have different people to work on the same database. With a text format, we could merge changes. It could be a setting for the DB, or perhaps just allow export/import from/to json or other format (though less convenient). I realize that image fields would cause issues (perhaps they could be serialized to some text format, if they are actually in the data).

First of all, let me tell you that I'm so looking forward to play your game! I love the source material, and had been wondering for some time why nobody was doing a proper homage, getting rid of some of the limitations of the era. I also love the low poly aesthetic; I'm so looking forward for it to enjoy a new revival similar to that of the pixel art.

About your situation, and that the development of your game, perhaps knowing of other experiences will help you, so here's mine.

I've been working on a game for a couple of years, without much previous, direct, experience.

One important thing is, I'm not working on it alone. Though I'm the one doing the programming, and learning along the way how to make it possible.

Early on I realized that my vision was overly ambitious, so the scope of the game has been scaled down several times. We're on the third devolution, and it's a drastically different and way simpler game. But we choose to keep things in the design that will help when/if we tackle the more ambitious game.

I guess what I want to say is, both managing the "size" of the challenge, and having a team (in my case, a friend), can get a long way to keep you working and keep going on. 

Being realistic about what can be achieved, is a must. Otherwise what awaits is failure. 

And I don't, I wouldn't feel ashamed of copying or cloning already invented game mechanics. As they say, you can only break the rules you know. It's all part of a process, and we all start imitating before we're ready to innovate.

There's another issue which be will be fighting soon enough, when most of the mechanics are in place, which is content creation. I would say the two most critical and harder to nail are both story and level design.

But here's an idea: Maybe with original characters, and a free level design tool, people can make their own story, and play their own game. Sure, I'd prefer to make my own game, batteries included, but if I manage to get that done, and I can't manage to create all the content I'd like to, I would still consider it a success!

Keep that in mind, whenever you don't feel like working on the game. Personally, as a programmer, I think working on other, related stuff, such as game tools, helps a lot. I'm not strictly working on the game, but I'm working for the game, which is still progress :)

That looks seriously cool. Is it gonna be 60 FPS? 30FPS?