Hey, I'm Jonathan.
I started working on an android project a a few weeks back (really rough prototyping, code was completely unmaintainable)
but I wanted to join the jam, so someone on discord gave me the idea to build it again from scratch for this jam.
So I am! never made a Devlog before but I figure this could be a good outlet for successes and failures.
I'm making it with an artist (Lena) that I met irl, it's her first game ever. I'm also fairly new to dev and this is my first time tackling mechanics as complex as this.

some quick info about the game:

-Platform: android
- Engine: Unity
- Genre: 2D platformer (?)
- Theme: Japanese/Chineese caligraphy and art
- Core mechanic: drawing caligraphic brush strokes on screen that act as platforms.
- Basic story: a Monk finds a dying wolf (or some sort of cainine), helps his soul ascend to heaven (?)
and is followed by the ghost/spirit of the wolf. it's your job to keep the monk from falling to his death(lemmings style)

My goal in this jam is to be motivated by the deadline to finish a bare-bones version of the game with a few levels finished!

Edit: added the fact that I'm doing this in Unity. seemed relevant

:Oc ohhh dang i'm not too familiar with line + trailrenderers to give any advice but this looks like an interesting solution so far! i'm curious to see it implemented!

So I've gotten a bunch done since I last posted here, so far the systems are working surprisingly good, though the Shodos still look a little off and the monk can get stuck in them.
I figure I'll chronicle some of the technical stuff I did and put with progress gifs at the bottom for a TL;DR version.

#region Technical Rant

So since my original implementation idea I came across a bunch of problems. most of them were small bugs in my code, but the biggest issue I had was the PolygonCollider2D.
at first I just set a bunch of points into it (my Slice.edges) as vertices (that were supposed to match the bounds of the LineRenderer that you see, so what you see is what you collide with.
However, since I'm an idiot and can't read documentation properly, I assumed the order of points passed to collider didnt matter, and it just created a convex shape from whatever you plug in.
Not so. each path is cyclic, so you should end up where you started. this created intresting collisions, as seen in (A).

So I figured I'd try making lots of paths, each one a little BoxCollider2D-like rectange that was self contained. what could go wrong, right?
wrong. apparently having hundreds of paths being set every Update() is not the best thing for your game. I was getting crashes and hangs like crazy.
it took me the better part of a day to figure out it wasn't a bug in my code,but rather a constraint of the engine that was causing the hangs.

After that I had to refactor, which ended up being a good thing because I cleaned up the hell out of my code.
after going back to using a single Path for the polygon, and setting the logic up so it goes around the line (and not just iterating over Slices), it just worked. (B)

So now that the actual Shodo object was working, I started working on implementing multiple Shodos at once.
I wanted to pool my shodos to avoid memory issues from instantiating new Shodos constantly.
my implementation for that was a class that is structured as so:

 public class ShodoPool{
  private Queue<Shodo> availableShodos;
  private Queue<Shodo> detachedShodos;
  private GameObject shodoPrefab;
  private Camera mainCam;
  
  public ShodoPool(GameObject shodoPrefab, Camera mainCam, Transform shodoParent)
  
  public void StartDrawing(ref Shodo currShodo)  
  public void StopDrawing(ref Shodo currShodo)

  private GameObject CreatenewShodoObject()
  public void UpdateShodoQueues()
  public void AddToPool(int amount)
  private bool NotOnScreen(Shodo shod)
}

So this is my first time making an object pool. I have no idea how they aare usually made, but I'm happy with how this turned out.
it basically recycles Shodos into the detached/availableShodos Queue.
The detachedShodos Queue for shodos that are not currently in use by the player, but may still be rendered.
when a Shodo has either erased itself completely, or is off camera, it will move that shodo from the detached queue to the available queue.
I start off filling the pool with 3 Shodos, and more are created if they run out when

The pool is used by ShodoManager to abstract the recycling of Shodos,
and ShodoManager handles adding points to the currently used Shodo by grabbing mouse position.
This is done either every set time, or in Update as soon as the mouse has traveled a minimum distance. (to avoid stacking points close together at odd angles, which looks and acts terrible)

Today I worked a bit on the monk's AI (very simple, I want him to stop when close to an obstacle, and to jump when theres a gap with no platform underneath.
I thought of doing an arc-raycast type thing for him to check if he can jump before he tries, but after some consulting on Discord, decided it's simpler to just jump whenever theres a gap. The monk is basically a Lemming anyway, he's not supposed to have particularly intelligent AI.

#endregion

(A) first attempt at collisions, didn't go to well

(B) refactored collisions, Much better!

(C), (D) Multiple Shodos Recycled via Shodo Pool

(E) Monk jumping when reach gap

(F) Stopping when path blocked

(G) Using Shodo to block falling objects

Onwards-

The biggest thing that bothers me with the system right now is that sometimes a Shodo is drawn that is lumpy or has some edges, and the monk will get stuck on it. I'm thinking of doing a pass on the polygons vertices once per frame to smooth them out. we'll see how it ends up.

Also- we need to start thinking level designs and systems to support them! maybe an "ink level" to limit how much you can draw