Blog - Development log - GDice

Page / - last modified by Victor Zhang on 00:25, 22/07/2020

Development log - GDice

last modified by Victor Zhang

on 00:25, 22/07/2020

Table of Contents

In order to:

Refamiliarize 3d polygonal modeling ( recently used solid too much, kinda "spoiled" by the brep software )

Learn an opensource game engine in detail( Godot ), which will probably be used for digital musical instruments' visualization part

Learn the process of publishing a simple free android app (not touching ios yet as usually they have more tight restrictions and policies)

Note that publishing a commercial app is a whole other story, as there are more liability and legal details involved

Try to finish a project

This seems to be my life long weakness, that I'm more like a tinkerer that likes to start things but once to production stage, because the tasks then become repetitive I tend not to finish any projects. But finishing up things is important in many instances.

Also could test if I could tend to a project by rolling out some bug fixes or feature adds.

Scope:

Because it's a very short hobby project

The scale needs to be small, managable by one person

Interesting enough

Address some of personal interest

Dice is a good starting point

Although there are many apps like this already

The scope of project is small

Modeling is minimal, so that I can re-learn blender's basic functions

Yet not spend too much time on building assets and focus on the mechanics

Use the physics engine and learn its limits

Existing dice app

Two different styles:

Non-physics simulation style, clearly could be easier, however, wouldn't enable me to test out various functions of game engine

Physics simulation style

Existing ones variation:

Usually uses accelerometer ( which sometime could be unreliable, and have weird behaviour )

Tap to apply impulse

Inspiration:

It's a back to skeuomorphic approach of a dice-roller

The interaction doesn't exist with exising app

There are blinds that can hide the dices which most apps do not have

Differences:

Most existing apps needs to open a settings menu to select what kind of dice and how many

In the design, because I chose skeuomorphic approach, it needs to mimic the real-life action of dropping in and taking out dices

Also the new higher resolution device enables the interaction as older device wouldn't have enough resolution to work with additional draggable components.

Project part:

Dices

The maths of Polyhedron is already very well defined

So in blender, knowing how to slice/combine surface, move points with keyed in coordinates would be enough

The unwrap math is also already well defined, so it's pretty easy to map the surfaces

Physics wise, other than knowing the vertex vector, normal vector also needed for determining the up face

In this instance, because I did not follow the available dices, the only rule is that opposite side number's sum is always same

Up face is hard coded as "const" in script

Then the normal vector is transformed by dicerotation and compared to Vector3.Y ( up in Godot ), then the angleTo which is the minimum wins the number output

Might be performance drag here as it's calculated each frame, or not? ( Very small operations each dice but my hunch is that the vector3 math api does a lot of calculation )

Physics

Godot uses bulletphysics engine

It caught me by surprise that the behaviour is very different first time I tried to deploy to android ( testing on desktop before that )

Need to test on device earlier for later projects

Problems faced

Physics

The simulation framerate is very low

All the friction/bounce settings needs to be changed radically to accomodate the difference

Fortunately the android settings still works on PC/emulator, more smooth

To get violent dice rolling effect, the friction and rotation speed of plate needs to be set very high, resulting in dice flying out of the arena

Adding very thick walls and plate didn't work

So code to return the dice into the pot when things go haywire is added in _physics_process to ensure they do not fly out of the arena (may also have impacted performance negatively), thoughts there seems to not be reversed collision box (restrain bodies inside) type of collider in physics engine, imagine would be good to have something like that. Or it may have been this kind of collider that I didn't know about, need to research on that and keep an eye

Drag and drop

Somehow handling _Input isn't enough, as it's easier for touch to move out of the object when releasing ( somehow it's easier to slide with touch screen, and the software will fire drag event earlier than release event ), so will need to handle _unhandled_input to do the release code ( not fixed for the UIDice drag, however did it for all other UI elements ). Should this be considered a flaw of the engine?

Dynamic text

Used DSEG by keshikan (Open font license), a very well made font which has 7segment and 14 segment font, however this is somehow nostalgic and may not play well with genz who grew up with touch screen ( I may be wrong )

Procedural texture

This is a very interesting concept that generate texture through algorithm ( mostly making use of perlin noise and existing patterns )

There generator widely used by industry like poliigon , also the poor man's version: material-maker by RodZilla which I tested here.

Had a taste of how procedural texture work, however there are much more to dig into, did not install the generator plugin for project, used it to generate static texture to save computing on android device

GLES3 vs GLES2

GLES3 has good effect, however android performance is horrible

GLES2 is much faster however all the material set looked different on android ( may be a point where I could improve in the future , optimizing effect in GLES2 )

Texture inconsistancy

Did not find any post and do not know how to look for, as setting the texture into certain size like: 800x600 with alpha channel may result in it showing all black on android ( running on windows shows normally ), if further test shows that the help button also has same problem on some devices, will need to make that texture 512x512 too.

Viewport as dynamic texture seems not to play well with transparent background

Seems to be existing problem and there's post [here]

However as my viewport is square, I manage to get away with it (however the LCD surface texture I made in material maker isn't able to show, and is covered) I did manage to get a real LCD display's feeling out of it so not too bad

Font

Thanks to Roberto who teaches in communication design, he suggested vectora and bell for small number display, however avoiding copyright issues, the final versions did not utilize the fonts in texture ( although could view much clearer number display, because of shrinked corner ), used system included Arial instead

Publishing process:

Most out of my expectation is that there are a lot of extra steps to fulfil

It's reasonable as google will be liable if they skip any of the proper legal steps

Good thing that this app doesn't need to collect and handle any personal information

The process overall is quite easy and straight forward

20200602 submitted waiting for review

20200605 Published

Problems

First before export need to double check the com.x.x

Because the last one is the package name, I thought it was the app name, it ended up to be the project name

Bug: Dice can be put in/out when lid closed (need to recreate the problem)

Current download addr: https://play.google.com/store/apps/details?id=com.victorzzt.dicenew

Posted by Victor Zhang · Permalink