Add a post-mortem, crudely

This commit is contained in:
Jahn 2025-08-02 22:23:31 -04:00
parent 42caa9e724
commit e1cfcee8aa
2 changed files with 34 additions and 9 deletions

View File

@ -1,4 +1,4 @@
# doodle game concept # Doodle Game Concept
A game about using your finger/mouse to draw circles around moving game objects. A game about using your finger/mouse to draw circles around moving game objects.
It works by instantiating an `Area2D` node with a polygon collision shape, and can probably It works by instantiating an `Area2D` node with a polygon collision shape, and can probably
also be mildly modified to draw level geometry dynamically. also be mildly modified to draw level geometry dynamically.
@ -6,11 +6,34 @@ also be mildly modified to draw level geometry dynamically.
In either case, the challenge is taming an otherwise automatic system. In either case, the challenge is taming an otherwise automatic system.
Objects move on their own. You only control the ~~pencil~~ pen. Objects move on their own. You only control the ~~pencil~~ pen.
# TODO: # CANCELED
* swap pencil out for pen - consistent with the ink metaphor A brief post-mortem.
* add a snap effect when within snap distance confines
* filter all non-colliding points at beginning and end of gesture ## What Went Wrong
* add grouping code It's had been a minute since I attempted a proper game jam, and while I could tell I was much more
* multipliers for combos *skilled* this time around, my *execution* was what caused this fumble. I've been programming mostly
* penalties for not-combos websites (server-side and client-side), applications, and tooling. *Games are a different,
* ignore all erroneous gestures, gesture recognition is probably my fault cross-disciplinary beast.*
* Stick to the plan. The plan was visual metaphor to game ideas to game. I discarded all metaphor planning
in favor of a novel UI, which has worked in the past but this time set me back.
* Too much emphasis on doing something differently, rather than well. Yes, most of my initial ideas
were also built around by other developers and teams. No, that doesn't mean we'd be making the same
game. Build games that interest you, that you want to play, and fit your scope. Doesn't matter if
it's *unique.* This game isn't being presented to a general audience (yet)
* Core gameplay of mechanic was not considered enough before starting. Should have paper-tested it,
would have likely found it more akin to Fruit Ninja than a Wario Ware game.
* Too much aesthetic, too soon. Focusing on the smaller details (theming, sprites, UI) before ironing
out the large ones. This is a great little morale boost, but it is too much commitment too early on.
## What Went Right
I don't think the initial approach was wrong, however I think I rushed into starting too soon. I initially
just wrote down a bunch of visual metaphors for loops on paper and thought about each one in the context
of a game. I had 8, with a nebulous mound of ideas using them. I went on to observe many other teams make
games using some permutation of those same 8 metaphors.
* Spend time really considering the theme. As much as you can.
* Come up with many metaphors, not just one. It doesn't start with a game idea, necessarily, it starts with
an analogy.
* Come up with *game concepts* for each before proceeding. As many as you can, but don't spend too
much time on dead ends. I did this, but I didn't write it down.

View File

@ -8,6 +8,7 @@ size = Vector2(48, 46)
[sub_resource type="Animation" id="Animation_dtuyt"] [sub_resource type="Animation" id="Animation_dtuyt"]
resource_name = "Walking" resource_name = "Walking"
loop_mode = 1
tracks/0/type = "value" tracks/0/type = "value"
tracks/0/imported = false tracks/0/imported = false
tracks/0/enabled = true tracks/0/enabled = true
@ -126,3 +127,4 @@ texture = ExtResource("2_dtuyt")
libraries = { libraries = {
&"": SubResource("AnimationLibrary_5hcc2") &"": SubResource("AnimationLibrary_5hcc2")
} }
autoplay = "Walking"