Development log - GDice

Last modified by Victor Zhang on 00:25, 22/07/2020
  • 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
            DevWall.png
          • 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
          DevLCD.png
      • 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
          1591099777616-107.png
  • 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

Posted by Victor Zhang  ยท Permalink

Created by Victor Zhang on 19:20, 02/06/2020

Navigation