Skip to main content

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

Mysteryem

2
Posts
A member registered May 22, 2020

Recent community posts

A potential bug and some feature ideas:

Potential bug:

.zip model import doesn't seem to be working as expected. I added all my .fbx models to a .zip, but when I import the .zip with the model importer, it only imports the first .fbx in the .zip and imports it with the name "1" instead of the file's name.

Feature ideas:

Model probability weights.
Weights would allow the probabilities of certain models to be increased or decreased relative to other models. E.g. a model with a weight of 2 is twice as likely to be picked to be thrown as a model with a weight of 1. I would advise being careful with naming such a property though, since a 'weight' property could also be interpreted as how heavy a model is.
An alternative would be to add a general option to use the already existing 'scale' property to adjust probabilities, since in my opinion, large objects are typically those that might want to be rarer, since they are often heavier objects that would hurt more and also take up more screen space.

Model break chance and custom break sfx.
This one's a bit more far-fetched, but with the custom hit sfx in development, it made me think about how some objects when thrown would quite often break on impact, creating a different sound to if they didn't break, e.g. a glass bottle or a wooden crate. For simplicity, if a model breaks on impact it could get deleted or if you want to go all the way, there's the options of spawning giblet models, spawning particles with the same colours as the model or even doing something with a geometry shader to make the mesh explode and disintegrate.

I made some 3D models for other people to use with TITS. A few not-so-important things I thought of as a modeller:

It would be nice to have a numeric value for scale instead of just a slider, particularly for use with different coloured identical models, so they can be easily set to the same size.

It would be nice to be able to include a default scale along with any custom models so there's less work for someone importing the models. Either some companion file alongside each model or I know that with FBX at least, you can include custom properties from Blender into the FBX that can be read by Unity during model import, though I have no idea about other model formats. Maybe such a system could be expanded to also include a default sfx name or any other future settings.

Some way to easily have shiny objects would be nice. It might be that this is technically possible already since some material data can be included in some model files that Unity can then read to create materials from (e.g. colour and texture like you're already using), but I don't know whether this can also include stuff like metallic/smoothness or if you're even using a shader that can make stuff look shiny and reflective. Currently I can make things look sort of shiny by using custom normals, but it's painful to set up.

---

I also noticed you're saving Objects.tits as Base64 encoded binary data, which is kind of redundant since you can usually write binary data directly to a file (you may need to open the file in a binary mode or use some 'writer' specifically for writing binary data rather than text, I haven't used Unity to write any files so far, but those are common for other languages). Base64 is typically used when you want to transfer binary data through a plain-text format or protocol, such as directly embedding image data in a webpage or email (no separate image file), or including binary data in an HTTP request or giving users their savefile of a webgame as a string that they can copy and paste. It's not really an issue considering the low file size (my Objects.tits about 1400KB and is only about 200KB smaller when decoded and saved as a binary file), but I thought I'd point it out.

There is, however, one thing that I do strongly suggest you do and that's to include the version number of the program somewhere in the UI, whether that's in the window name, somewhere in the settings or somewhere else that's easily accessible. Trying to support people that could be running old versions with unfixed bugs, when it's not clear what version they're using, doesn't sound like it would be a lot of fun.

Thanks for making this fun program!