بناء UX ملموس باستخدام Lottie: عندما تقود الحركة المصممة هندسة التفاعل
يشرح Alexey Kopytin من Isadora Agency كيفية بناء لعبة ويب تفاعلية باسم Stress Release تمنح المستخدم إحساساً بالضغط والارتداد من دون Matter.js أو WebGL. يعتمد الحل على تحكم برمجي دقيق في مقاطع Lottie، وأحداث DOM، وحساب المسافة بين موضع النقر ومركز الشخصية، للحفاظ على الحركة التي صممها فريق التحريك إطاراً بإطار.
أبرز النقاط
- المشروع استبدل physics engine بتحكم برمجي في حالات ومقاطع Lottie للحفاظ على حركة صممها المحركون مسبقاً.
- يُحسب بُعد النقرة عن مركز الشخصية عبر Math.hypot() لتحديد النقاط وشدة التفاعل وموضع مؤثر الانفجار.
- يعتمد hit detection على دوائر متحدة المركز، لا على تعقيد شكل SVG أو تفاصيل الرسم المتحرك.
- تُشغّل حالات idle وsqueeze عبر نطاقات frames باستخدام playSegments()، مع تعطيل النقر مؤقتاً أثناء تشغيل رد الفعل.
- يعالج المشروع الاستجابة عبر CSS variables، ويخفف كلفة Lottie بالتحميل التدريجي وإدارة الذاكرة وتخفيض الجودة لبعض الرسوم.
في التجارب التي تبدو قابلة للمس والضغط على الويب، يكون اللجوء إلى physics engine مثل Matter.js خياراً شائعاً. لكن فريق Isadora Agency اختار مساراً مختلفاً عند بناء Stress Release، وهي تجربة تتيح الضغط على شخصيات متحركة وتشويهها بصرياً: الاستغناء عن محاكاة الفيزياء لصالح تحكم دقيق ومباشر في حركة Lottie.
الفكرة الأساسية هي أن الحركة المطلوبة لم تكن مجرد ارتداد «مقنع» فيزيائياً، بل ردود فعل صممها المحركون مسبقاً بتسلسل محدد. مثال ذلك تفاعل mega squeeze الذي يتضمن بناءً من 181 إطاراً ثم تسلسل إطلاق معين. لذلك استخدم الفريق Lottie API لتشغيل نطاقات frames محددة، بدلاً من ترك محرك فيزياء يولّد حركة قد لا تطابق الـ keyframes المقصودة.
تُعرض رسوم Lottie بصيغة SVG داخل DOM، بينما تُدار التفاعلات عبر أحداث النقر واللمس المعتادة. عند النقر على الشخصية، يحوّل الكود إحداثيات النقر إلى مساحة الشخصية المحلية، ثم يحسب المتجه بين النقرة ومركزها. وتُستخدم قيمة المسافة الناتجة عبر Math.hypot() لتحديد النقاط وشدة الاستجابة ومكان ظهور حركة الانفجار.
ينتج عن ذلك hitbox دائري مكوّن من مناطق متحدة المركز، شبيه بلوحة رمي السهام: كلما اقتربت النقرة من المركز زادت النقاط. والأهم أن حركة الانفجار تُنقل إلى الموضع نفسه الذي استُخدم في الحساب، ما يربط بصرياً بين موضع النقر ورد الفعل الذي يظهر للمستخدم.
أما تسلسل التفاعل نفسه فيُدار عبر نطاقات frames. يمكن للشخصية أن تبقى في idle loop، ثم تنتقل عند النقر إلى مقطع squeeze خفيف أو متوسط أو قوي عبر playSegments(). ويوقف الكود النقرات أثناء تشغيل المقطع، ثم يعيد الشخصية إلى حالة الخمول عند اكتماله. بهذه الطريقة تكون طبقة الكود مسؤولة عن الاستماع والحساب والتشغيل، فيما تبقى تفاصيل الإحساس بالحركة داخل منحنيات التحريك التي أعدها المصممون.
اختيار DOM أضاف فائدة مرتبطة بالاستجابة للشاشات المختلفة. بدلاً من إعادة حساب bounding boxes ومتجهات التصادم عند تغيير الأبعاد، يعتمد المشروع على CSS variables تُحدَّث عند resize، بينما تتمدد SVGs الخاصة بـLottie داخل حاوياتها مع الحفاظ على حالتها.
لكن التحكم الفني جاء بتكلفة أداء، خصوصاً مع 21 حركة شخصية ونسخ متعددة من مؤثرات الانفجار. لذلك راقب الفريق زمن تحميل الأصول ورصد الاتصالات البطيئة عند تجاوز التحميل خمس ثوانٍ، وحمّل الرسوم على دفعات من شخصيتين بدلاً من تهيئتها كلها دفعة واحدة. كما دمّر مؤثرات الانفجار وأعاد إنشاءها عند الحاجة لتقليل استهلاك الذاكرة في وضع الخمول.
وطُبقت أيضاً جودة وسرعات مختلفة بحسب دور الحركة: شخصيات الرف يمكن أن تعمل بجودة 50% وسرعة 60%، بينما تعمل الشخصية التي يتفاعل معها المستخدم بالجودة الكاملة. المقال، وهو برعاية Isadora Agency، يقدّم بذلك مثالاً عملياً على أن اختيار التقنية لا يبدأ من أكثر الأدوات شيوعاً، بل من مقدار التحكم الذي تتطلبه الحركة والتوجيه الفني في التجربة.
لماذا يهم؟
يوضح المثال أن التجارب التفاعلية الغنية لا تحتاج دائماً إلى محاكاة فيزيائية أو WebGL. عندما تكون الحركة جزءاً أساسياً من الـart direction ومحددة إطاراً بإطار، قد يمنح الجمع بين Lottie وDOM وحسابات الإحداثيات تحكماً أوضح في النتيجة، مع بقاء تحسين التحميل والذاكرة ضرورياً على الأجهزة المحمولة.