DEV Community: Dinesh

Why Switching from Unreal Engine to Unity Felt Surprisingly Difficult

Dinesh — Fri, 03 Jul 2026 07:51:00 +0000

I thought learning Unity would be easy after spending months in Unreal Engine.

Instead, even simple tasks felt surprisingly difficult.

That's when I realized I wasn't learning a new engine—I was trying to use Unreal Engine habits inside Unity.

This post is part of my daily learning journey in game development.

I’m sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 105 of my game development journey, I explored what it feels like to switch from Unreal Engine to Unity.

What I Used to Think

Since I already knew Unreal Engine, I assumed Unity would be easy to learn.

After all, both engines are used to build games.

I expected my existing knowledge to transfer almost instantly.

What I Realized

The concepts are similar.

The workflow isn't.

Unity revolves around GameObjects and Components, while Unreal Engine is built around Actors, Components, and Blueprints.

Both engines can create the same types of games, but they organize everything differently.

Even simple tasks like:

Creating objects
Navigating the editor
Finding settings

felt unfamiliar because I kept expecting Unreal Engine's workflow.

Why This Matters

The biggest challenge wasn't learning game development again.

It was changing the way I think.

I realized I wasn't struggling with Unity.

I was struggling with my Unreal Engine habits.

Every time I searched for an Unreal equivalent instead of learning Unity's approach, I slowed myself down.

What Finally Clicked

The problem wasn't Unity.

The problem was my mindset.

Once I stopped comparing every feature to Unreal Engine and started learning Unity on its own terms, everything became easier.

Instead of asking,

"Where is the Unreal Engine version of this?"

I started asking,

"How does Unity solve this problem?"

That small mindset shift made a huge difference.

Practical Fix

Learn Unity terminology before comparing engines.
Build a small Unity project from start to finish.
Accept that both engines have different workflows.
Focus on one engine while learning.
Don't expect menus, tools, or shortcuts to be in the same place.

One Lesson for Beginners

Game development concepts transfer between engines.
Workflows do not.
Every engine has its own design philosophy.
Small projects help you adapt faster.
Be patient while rebuilding your muscle memory.

Why This Matters in Real Projects

Professional developers often work with multiple engines during their careers.

The valuable skill isn't memorizing editor layouts.

It's understanding game development fundamentals and adapting to different workflows.

Once I accepted Unity as its own engine instead of treating it like "another Unreal Engine," learning became much more enjoyable.

Switching engines doesn't mean starting from zero.

You already have the fundamentals.

Now it's just about learning a different way to apply them.

Slow progress — but I’m building a strong foundation.

If you’re also learning game development, what was the first thing that confused you when you switched engines?

See you in the next post 🎮🚀

Why Switching from Unreal Engine to Unity Felt So Difficult

Dinesh — Thu, 02 Jul 2026 07:57:00 +0000

I thought learning Unity would be easy after spending months in Unreal Engine.

Instead, even simple tasks felt surprisingly difficult.

That's when I realized I wasn't learning a new engine — I was trying to use Unreal Engine inside Unity.

This post is part of my daily learning journey in game development. I'm sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 100 of my game development journey, I explored the biggest challenge of switching from Unreal Engine to Unity.

What I Used to Think

I assumed my Unreal Engine experience would make Unity easy to learn.

After all, both engines are built to create games.

So I expected to recognize most of the workflow immediately.

What I Realized

Both engines solve the same game development problems — but they do it in completely different ways.

Unity

Uses GameObjects and Components
Most functionality is added through Components
C# scripts control behavior

Unreal Engine

Uses Actors, Components, and Blueprints
Gameplay systems are organized differently
Visual scripting is deeply integrated into the workflow

The concepts are similar.

The workflows are completely different.

Why This Matters

The hardest part wasn't learning game development concepts.

It was changing my habits.

I kept searching for Unreal Engine features inside Unity.

Even simple tasks like navigating the editor, creating objects, and finding settings took much longer — because I expected Unity to behave like Unreal Engine.

Game development knowledge transfers.

Muscle memory doesn't.

What Finally Clicked

The problem wasn't Unity.

The problem was my mindset.

I stopped asking:

"Where is the Unreal Engine version of this feature?"

And started asking:

"How does Unity solve this problem?"

That shift made everything click faster.

Practical Fix

Learn Unity terminology before comparing it to Unreal Engine
Build one small Unity project from start to finish
Accept that workflows are different — and that's okay
Focus on understanding Unity's architecture on its own terms
Avoid searching for Unreal Engine equivalents every time you get stuck

One Lesson for Beginners

Game development concepts transfer between engines
Editor workflows do not
Every engine has its own philosophy
Small projects help you adapt faster
Be patient while rebuilding muscle memory

Why This Matters in Real Projects

Many developers eventually work with more than one game engine.

The real skill isn't memorizing menus.

It's understanding the underlying concepts and adapting to different workflows.

Once you stop comparing engines and start learning each one on its own terms, switching becomes much easier.

Learning a new engine doesn't mean starting from zero.

Your knowledge comes with you.

You just need to learn a different way of applying it.

Slow progress — but I'm building a strong foundation.

If you're also learning game development, what was the biggest surprise when you first switched tools or engines?

See you in the next post 🎮🚀

Why 2D Animation Setup in Unity Is Harder Than the Game Logic Itself

Dinesh — Wed, 01 Jul 2026 07:51:00 +0000

This post is part of my daily learning journey in game development. I'm sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 103 of my game development journey, I worked on 2D animations in Unity — and realized that writing the game logic was the easy part. Setting up the animations was a completely different challenge.

What I Used to Think

I assumed 2D games were simpler than 3D.

Less geometry. Less complexity. Less setup.

So when I started building a basic 2D game in Unity, I expected everything to feel easier — including the animations.

I was wrong about that last part.

What Actually Happened

The game logic came together faster than I expected.

Moving the character. Detecting collisions. Handling jumps. Writing C# scripts for these felt straightforward once I understood Unity's component system.

Then I moved to animations.

I had my sprite sheet ready. I had my frames. I thought it would be a simple drag and drop.

It wasn't.

Where It Got Complicated

Unity's animation system has multiple layers working together — and as a beginner, I had no idea going in.

First there's the Animation Clip — the actual recorded movement. Each action like idle, run, and jump is its own clip.

Then there's the Animator Controller — a state machine that decides which clip plays and when. You build it visually using nodes and transitions inside the Animator window.

Then there are Parameters — boolean, integer, float, or trigger values that your script sends to the Animator to tell it when to switch states.

And finally there's the Animator component — attached to your GameObject — which connects everything together at runtime.

Four separate things. All connected. All needing to be set up correctly before a single animation plays.

The game logic was one script. The animation system was an entire pipeline.

What Confused Me

I kept asking the same questions.

Why is my character stuck on the idle animation even though the player is moving?

Why does the transition not trigger when I press the key?

Why is the animation playing but the character isn't moving with it?

Each problem had a different answer. A wrong parameter name. A missing transition condition. A script referencing the wrong Animator component.

Small mistakes. Big confusion.

Why It Happens

Game logic in Unity is mostly linear. Write a script. Attach it. Test it.

Animation in Unity is a state machine. You're not just writing logic — you're building a visual flow of states and rules that the Animator follows at runtime.

State machines are powerful. But they have their own rules, their own vocabulary, and their own way of breaking when one thing is off.

For a beginner coming from basic scripting, it's a real mental shift.

What Finally Clicked

The Animator Controller isn't just a tool — it's a second layer of logic on top of your scripts.

Your C# script controls the game. The Animator Controller controls the visuals. They talk to each other through parameters.

Once I started thinking of them as two separate systems that communicate — instead of one thing — the setup started making sense.

// Example: telling the Animator the player is running
Animator animator = GetComponent<Animator>();
animator.SetBool("isRunning", true);

One side handles the rules. The other side handles what the player sees.

Practical Steps That Helped

Slice your sprite sheet properly in the Sprite Editor before doing anything else
Create one Animation Clip per action — idle, run, jump, fall
Open the Animator Controller and add each clip as a state
Set up transitions between states with the right conditions
Create parameters in the Animator that match exactly what your script sends
Use SetBool, SetFloat, or SetTrigger in your script to drive the transitions
Test one animation at a time — don't wire everything up at once

One Lesson for Beginners

The Animator Controller is a state machine — understand that concept first
Parameter names in the Animator must match exactly what your script uses
Transitions need conditions — they won't switch automatically without them
Slice your sprite sheet before creating clips — order matters
Debug one animation state at a time, not the whole system at once

Why This Matters in Real Projects

In professional 2D game development, animation is one of the most time-consuming parts of production.

Even simple characters need multiple states — idle, walk, run, jump, fall, attack, hurt, death. Each state is a clip. Each transition is a rule. The Animator Controller grows fast.

Understanding how Unity's animation pipeline works early — the clips, the controller, the parameters, the component — saves a lot of frustration later when the character count and animation count grow.

Game logic tells the game what to do. Animation tells the player what's happening.

Both matter. But animation takes more patience to set up right.

Slow progress — but I'm building a strong foundation.

If you're also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀

Why Beginners Skip Version Control and Regret It Later

Dinesh — Tue, 30 Jun 2026 07:48:00 +0000

This post is part of my daily learning journey in game development. I'm sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 101 of my game development journey, I explored Unity Version Control and Git integration inside Unity Hub — and honestly, I wish I had looked at this sooner.

What I Used to Think

Version control felt like a professional developer thing.

Something for big teams. Big projects. Not for a beginner working alone on small games.

So I skipped it completely.

My backup system? Duplicate folders. Zip files. Files named like project_final, project_final_v2, project_ACTUALLY_final.

It worked. Until it didn't.

What I Was Doing Instead

Every time I made a big change, I copied the entire project folder and renamed it with a date.

It felt safe. It wasn't.

One wrong save. One bad import. One afternoon of breaking something I couldn't undo — and I lost hours of work with no way to go back.

That's when I started taking version control seriously.

What I Found in Unity Hub

I expected version control to be complicated.

Install Git separately. Configure terminal commands. Write commit messages into a black screen.

But Unity made it much more approachable than I expected.

Inside Unity Hub, you can link a Git repository directly to your project. Unity also has its own dedicated system called Unity Version Control — previously known as Plastic SCM — which goes even further with visual branching, file locking, and full project history.

Unity Version Control has its own UI built directly into the Unity Editor. I didn't need to touch a terminal to get started.

That surprised me.

What Unity Version Control Actually Does

Unity Version Control tracks every change you make to your project.

Every scene edit. Every script change. Every asset added or removed.

If something breaks, you can roll back to a previous version in a few clicks. If you want to try something risky without ruining your current progress, you create a branch — a separate copy of your project — experiment freely, and merge it back if it works.

Git integration works similarly. You connect your local project to a remote repository — GitHub, GitLab, or Bitbucket — and push your progress as you go.

Both options give you a safety net that zip files never could.

What Finally Clicked

Version control isn't just for teams.

It's a safety net for solo developers too.

Every time you commit your progress, you're creating a restore point. Like a save state in a game — but for your entire project.

The moment I understood that, it stopped feeling like extra work.

It became part of the workflow.

Why I Actually Liked Unity's Approach

Unity made this easier than I expected.

Unity Version Control is built specifically for game projects. It handles large binary files like textures and audio better than raw Git does — because plain Git wasn't designed for large assets. Unity Version Control was.

For solo developers and small teams, the free tier covers everything you need to get started.

It felt designed for people like me — not just experienced developers.

Practical Steps to Get Started

Install Git from git-scm.com if you want to use Git with a remote repo
Open Unity Hub → connect a Git repository to your project from the project settings
Or enable Unity Version Control directly from the Unity Editor under Edit → Project Settings → Version Control
Make your first commit after every meaningful change
Use branches when trying something experimental
Never rely on folder duplication as a backup again

One Lesson for Beginners

Version control isn't just for professionals — solo devs need it too
Unity Version Control is built for game files, not just code
It handles large binary assets better than plain Git out of the box
Commit small and often — don't wait until a feature is "finished"
A project without version control is one bad save away from disaster

Why This Matters in Real Projects

Every professional game studio uses version control. No exceptions.

Learning it early — even on small solo projects — builds a habit that carries into team environments. You learn how to commit, how to branch, how to roll back. These are skills studios expect you to already have.

Unity's built-in tools lower the barrier enough that there's no good reason to skip it anymore.

Start now. Your future self will thank you.

Slow progress — but I'm building a strong foundation.

If you're also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀

Blueprint vs Unity Visual Scripting — A Beginner's Honest Comparison

Dinesh — Mon, 29 Jun 2026 07:53:00 +0000

This post is part of my daily learning journey in game development. I'm sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 100 of my game development journey, I explored visual scripting in both Unreal Engine and Unity — and tried to figure out which one actually makes sense for beginners.

What I Used to Think

I thought visual scripting was just "coding without typing."

Same logic. Same power. Just drag and drop.

So it shouldn't matter which engine I use — right?

That was wrong.

What I Tried

I opened Unreal Engine and created a simple Blueprint to move a cube when I press a key.

Then I did the same thing in Unity using Visual Scripting (formerly Bolt).

Same goal. Two completely different experiences.

Blueprint (Unreal Engine)

Blueprint felt built into the engine from the ground up.

Everything was connected — the editor, the assets, the events. It didn't feel like a separate tool layered on top.

The node graph was large and detailed. A lot of nodes at first. But once I understood the core flow — Event → Condition → Action — things started clicking.

Blueprint in Unreal Engine is not a workaround. It's a first-class system. Epic Games has shipped entire games using Blueprint alone.

The learning curve felt steep early on. But the feedback was immediate — I could see results fast, which kept me going.

Unity Visual Scripting

Unity Visual Scripting felt like it was added on top of the engine rather than built into it.

The node graph looked cleaner and simpler — easier to read at first glance.

But connecting it to GameObjects and components felt less intuitive. I had to understand Unity's component system first before the visual scripting started making sense.

It's genuinely powerful — but it needed more setup before I could see real results.

The Real Difference

Blueprint is deeply integrated into Unreal Engine. It shares the same event system, the same component references, the same asset pipeline. Everything talks to everything naturally.

Unity Visual Scripting is more modular. It sits on top of Unity's existing C# architecture — which makes it flexible, but also means more steps before things connect properly.

For pure beginner speed — Blueprint wins.

For long-term flexibility and an easier transition into code later — Unity Visual Scripting has a smoother bridge to C#.

What Finally Clicked

Visual scripting is not just "no-code."

Each engine has its own logic, its own node system, its own rules.

Learning Blueprint teaches you how Unreal Engine thinks.

Learning Unity Visual Scripting teaches you how Unity's component system works.

They're not interchangeable. They're two different ways of understanding two different engines.

Which One Should Beginners Start With

If you're starting with Unreal Engine — use Blueprint. It's the natural entry point. Almost everything in Unreal has a Blueprint equivalent.

If you're starting with Unity — get comfortable with GameObjects and components first. Then move into Visual Scripting. It'll make much more sense once that foundation is there.

Don't try to learn both at the same time when you're just starting out. Pick one engine and go deep.

One Lesson for Beginners

Blueprint is Unreal Engine's native language — treat it seriously
Unity Visual Scripting is built on top of C# — understanding Unity's component system first helps a lot
Both systems can build real, complete games — neither is just a toy
Visual scripting has performance costs compared to native code — keep logic simple while you're learning
Pick one engine, learn its visual scripting well, then decide if you need to go deeper

Why This Matters in Real Projects

In real game development, visual scripting is used for prototyping, gameplay logic, and rapid iteration.

Blueprint is used professionally in the Unreal Engine ecosystem. Many shipped titles — including AA games — rely on Blueprint for core gameplay systems.

Unity Visual Scripting is more common in indie and solo projects, especially for teams without strong C# experience.

Understanding both helps you read other developers' work, follow tutorials across engines, and make a smarter choice about where to focus your time.

Choosing the right tool early saves a lot of frustration later.

Slow progress — but I'm building a strong foundation.

If you're also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀

Why MetaHumans Make Unreal Projects Heavy

Dinesh — Thu, 14 May 2026 03:37:59 +0000

I added a MetaHuman to my project. The character looked amazing… but my project suddenly became much heavier.

This post is part of my daily learning journey in game development.

I’m sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 99 of my game development journey, I learned why MetaHumans and realistic assets require heavy optimization in Unreal Engine.

What I Used to Think

If Unreal Engine supports realistic graphics, why not use maximum quality everywhere?

More quality should always mean better results… right?

But after importing a MetaHuman, I noticed:

Bigger project size
Longer loading times
Lower performance

That’s when optimization finally started making sense.

What I Realized

Realistic assets are expensive.

MetaHumans use:

High-resolution textures
Dense meshes
Complex materials
Advanced rigs and shaders

All of this increases:

Storage usage
Memory usage
Rendering cost

So games cannot use maximum quality everywhere.

Why This Matters

Modern games must balance:

Visual quality
Frame rate
Hardware limitations

Optimization is not about making games look bad.

It’s about removing details players usually won’t notice during gameplay.

What Finally Clicked

Good graphics are expensive.

Optimization = smart compromise.

Not every object needs ultra quality all the time.

Background assets, distant objects, and hidden details can often be simplified without ruining the experience.

Practical Fix

Use LODs for characters and meshes
Reduce texture resolution where possible
Disable unnecessary material features
Use simpler assets for background objects
Test performance regularly during development

One Lesson for Beginners

MetaHumans are heavy by default
Texture size affects storage heavily
LODs improve performance at distance
Optimization should start early
Visual quality must match hardware limits

Performance Note

Even AAA games sacrifice quality in areas players rarely notice.

Optimization tricks include:

Lower texture resolution at distance
Simpler meshes in the background
Aggressive LOD switching
Baked lighting in some scenes

Good optimization is often invisible to players.

Why This Matters in Real Projects

Professional game development is not about pushing graphics everywhere.

It’s about deciding:

Where detail matters
Where performance matters more

Understanding this early changes how environments, characters, and assets are built inside Unreal Engine.

Realism is not free.

The real skill is making a game look good while still running smoothly.

Slow progress — but I’m building a strong foundation.

If you’re also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀

Why Unity Looked So Confusing at First

Dinesh — Mon, 11 May 2026 16:21:48 +0000

I opened Unity for the first time…and immediately got overwhelmed by tabs everywhere. But after writing my first small script, things finally started connecting.

This post is part of my daily learning journey in game development.

I’m sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 98 of my game development journey, I explored the Unity Editor and basic C# scripting workflow.

What I Used to Think

I thought Unity would work like a simple drag-and-drop tool.

But after opening the editor, I saw:

Scene
Game
Hierarchy
Inspector
Project

Everything looked confusing at first.

What I Realized

Each Unity tab has a specific role.

Scene

Used to build and edit the level.

Game

Shows the final camera output.

Hierarchy

Stores all objects inside the scene.

Inspector

Displays properties of the selected object.

Project

Contains assets, scripts, and project files.

Then I connected Visual Studio Code and created my first C# script.

After declaring a simple variable, I finally understood how scripting connects with Unity objects.

Why This Matters

Unity combines:

Visual editing
Programming

The editor handles the scene visually, while C# scripts define behavior.

That’s why Unity uses an external code editor like VS Code.

Example:

public int speed = 5;

Public variables appear in the Inspector, allowing values to be changed without editing code.

What Finally Clicked

Hierarchy = objects

Inspector = properties

Scripts = behavior

Unity’s editor and code work together as one system.

Practical Fix

Open Unity Hub and create a project
Install Visual Studio Code
Set VS Code as the external editor in Unity Preferences
Create a C# script
Attach the script to a GameObject
Declare simple variables to test behavior

One Lesson for Beginners

Don’t try to learn every tab at once
Inspector changes based on the selected object
Public variables appear in the Inspector
Save scripts before returning to Unity
Use the Console tab to debug errors

Common Beginner Mistake

Thinking Unity scripting works separately from the editor.

In reality:

The editor handles visuals
Scripts control logic
Both are deeply connected

Why This Matters in Real Projects

Understanding the editor layout is the foundation of learning any engine.

Unity’s workflow is designed around:

Fast iteration
Visual editing
Modular scripting

Learning simple concepts like variables early helps build confidence before moving into larger gameplay systems.

At first, Unity looked complicated.

But once the relationship between the editor and code became clear, the workflow finally started making sense.

Slow progress — but I’m building a strong foundation.

If you’re also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀

How to Structure a Beginner Portfolio That Actually Works

Dinesh — Sat, 02 May 2026 13:30:25 +0000

I thought a portfolio needed many sections and a perfect design. But the more I added, the more confusing it became. Then I simplified everything — and it finally worked.

This post is part of my daily learning journey in game development.

I’m sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 97 of my game development journey, I figured out a simple structure for a beginner portfolio.

What I Used to Think

A portfolio should:

Look professional
Have many sections
Show advanced skills

I felt I needed to impress people.

What I Realized

A beginner portfolio can be simple.

Just 3 sections are enough:

1. About

Who I am
What I’m learning

2. Project Overview

Tools I use
Type of projects I build

3. Projects

Actual work
Proof (images/videos)

Why This Matters

Most beginners try to:

Overdesign
Add unnecessary sections
Act like professionals

But viewers usually want:

Clarity
Honesty
Real work

A simple structure makes everything easier to understand.

What Finally Clicked

About = who I am now

Overview = what I’m learning

Projects = what I built

No need to fake experience.

Practical Fix

Write the About section in simple, honest lines
Add a short overview of tools and skills
Show 2–5 real projects only
Add images or videos for proof
Keep descriptions short and clear

One Lesson for Beginners

Don’t copy complex portfolios
Keep layout simple
Show progress, not perfection
Be honest about your level
Update your portfolio regularly

Common Beginner Mistake

Trying to look “professional” instead of being clear.

This leads to:

Confusing structure
Empty sections
Fake or exaggerated content

Why This Matters in Real Projects

A portfolio is not about impressing with design.

It’s about:

Showing direction
Showing effort
Showing real work

Over time, this simple structure can grow into a strong professional portfolio.

Start simple. Stay honest. Keep building.

Slow progress — but I’m building a strong foundation.

If you’re also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀

How I Built a Free Portfolio Using GitHub Pages

Dinesh — Fri, 01 May 2026 14:16:05 +0000

I thought I needed money and advanced skills to build a portfolio.

Turns out… I just needed to start.

This post is part of my daily learning journey in game development.

I’m sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 96 of my game development journey, I built my first portfolio using GitHub Pages for free.

What I Used to Think

A portfolio meant:

Professional design
Advanced coding
Paid hosting

It felt like something only experienced developers could do.

What I Realized

A portfolio is simply a place to show your work.

That’s it.

Using GitHub Pages, I was able to:

Create a website for free
Host it online instantly
Share my projects easily

And the best part — I only needed basic HTML and CSS.

Why This Matters

Many beginners delay building a portfolio because they think:

“I’m not ready yet”
“My work is not good enough”

But in reality:

👉 Projects matter more than design

👉 Progress matters more than perfection

A simple portfolio with real work is more valuable than a perfect empty site.

What Finally Clicked

Portfolio ≠ perfection

Portfolio = proof of work

Even a simple site can:

Show skills
Track progress
Help with job or freelance opportunities

Practical Fix

Create a GitHub account
Create a new repository
Add a simple HTML/CSS portfolio template
Go to Settings → Enable GitHub Pages
Upload project screenshots or videos
Share your live portfolio link

One Lesson for Beginners

You don’t need to be a pro to start
Content is more important than design
Keep layout clean and simple
Update your portfolio regularly
Show real projects, not just ideas

Common Beginner Mistake

Waiting too long to build a portfolio.

Your early work may not be perfect, but it shows:

Growth
Consistency
Learning mindset

That matters more.

Why This Matters in Real Projects

A portfolio is your digital identity as a game developer.

It helps you:

Showcase skills
Get freelance work
Apply for jobs
Build credibility

Free tools like GitHub Pages remove barriers, so you can focus on building and sharing your work.

Your portfolio doesn’t need to be perfect. It just needs to exist.

Slow progress — but I’m building a strong foundation.

If you’re also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀

Unity vs Unreal Engine for 2D Games

Dinesh — Fri, 03 Apr 2026 16:10:11 +0000

I tried building a 2D game in Unreal Engine. It worked… but something felt off. Then I looked at Unity — and the difference was clear.

This post is part of my daily learning journey in game development.

I’m sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 95 of my game development journey, I compared Unity vs Unreal Engine for 2D development.

What I Used to Think

Unreal Engine is powerful.

So it should be good for everything — including 2D.

But when I started building, the workflow didn’t feel smooth.

What I Realized

Both engines can make 2D games, but their focus is different.

Unity

Built with strong 2D support
Better tools for sprites and tilemaps
Large 2D community and resources

Unreal Engine

Primarily designed for 3D
Uses Paper2D for 2D
Less actively developed 2D pipeline

Why This Matters

The difference is not about power.

It’s about workflow and specialization.

Unity has:

Dedicated 2D tools
Cleaner sprite-based workflow

Unreal has:

Strong 3D systems
Better support for hybrid (2.5D) games

What Finally Clicked

Unity = specialized for 2D

Unreal = stronger in 3D

Both can create 2D games.

But one feels more natural depending on the project.

Practical Fix

Use Unity for pure 2D games
Use Unreal for 2.5D or 3D-heavy projects
Try small prototypes in both engines
Choose based on workflow comfort
Focus on learning fundamentals first

One Lesson for Beginners

Engine choice depends on project type
Unity has a stronger 2D ecosystem
Unreal shines in real-time 3D
Tools matter more than raw power
Comfort and workflow speed are important

Why This Matters in Real Projects

Choosing the right engine affects:

Development speed
Tool efficiency
Long-term scalability

Even though Unreal is powerful, Unity’s dedicated 2D ecosystem makes it more practical for sprite-based games, especially for beginners and mobile development.

There is no “best engine” for everything.

The right choice depends on what you want to build.

Slow progress — but I’m building a strong foundation.

If you’re also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀

Why MetaHuman Felt Too Easy in Unreal Engine

Dinesh — Thu, 02 Apr 2026 14:32:28 +0000

I wanted to create a realistic character. But modeling from scratch felt impossible. Then I tried MetaHuman… and everything was ready.

This post is part of my daily learning journey in game development.

I’m sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 94 of my game development journey, I explored MetaHuman in Unreal Engine.

What I Used to Think

Creating realistic characters requires:

Modeling
Rigging
Texturing

It felt like a huge task.

I thought it would take weeks or months.

What I Realized

MetaHuman is not just a model.

It’s a complete character system that includes:

High-quality mesh
Realistic materials
Full body rig
Facial rig and animation support

All generated through a web-based MetaHuman Creator.

Then imported directly into Unreal using Quixel Bridge.

Why This Matters

MetaHuman uses:

Pre-built assets
Procedural customization
Optimized pipelines

So instead of building everything manually, you get a production-ready character quickly.

That’s why:

Everything is already rigged
Materials are complex
Files are heavy

What Finally Clicked

MetaHuman is not a simple asset.

It’s a full pipeline.

It saves time by giving:

Ready-to-use characters
High-quality visuals
Built-in animation support

Practical Fix

Create a character in MetaHuman Creator
Open Quixel Bridge inside Unreal Engine
Download and add the MetaHuman to your project
Place the character in the level
Use the provided Animation Blueprint to control movement

One Lesson for Beginners

MetaHuman is a system, not just a model
High quality comes with heavy files
Everything is pre-rigged and ready
You can still customize after import
Focus shifts from creation to usage

Why This Matters in Real Projects

MetaHuman changes how characters are built in modern pipelines.

Instead of spending time on:

Modeling
Rigging

Developers can focus more on:

Gameplay
Storytelling
Interaction

MetaHuman shows how tools are evolving — from manual creation to smart systems.

Understanding this helps you work faster without sacrificing quality.

Slow progress — but I’m building a strong foundation.

If you’re also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀

Why One Texture Didn’t Look Real in Blender

Dinesh — Wed, 01 Apr 2026 14:44:41 +0000

I added a texture to my model. It showed color… but looked flat. That’s when I realized one image isn’t enough.

This post is part of my daily learning journey in game development.

I’m sharing what I learn each day — the basics, the confusion, and the real progress — from the perspective of a beginner.

On Day 93 of my game development journey, I understood the difference between Image Texture and Texture Maps in Blender.

What I Used to Think

I thought adding one texture image would complete the material.

Just plug it in → done.

But the result looked flat and unrealistic.

What I Realized

An Image Texture node is just a way to load an image.

But that image can represent different types of data.

These are called texture maps:

Base Color (Albedo) → surface color
Normal → surface detail for lighting
Roughness → how shiny or matte the surface is

So one material uses multiple maps, not just one.

Why This Matters

Each map controls a different part of how light interacts with the surface.

Color alone does not define realism
Lighting response comes from other maps

That’s why materials look flat without:

Normal maps
Roughness maps

What Finally Clicked

Image Texture = tool to load an image

Texture Maps = data that defines material behavior

One material = multiple maps working together

Practical Fix

Add multiple Image Texture nodes
Connect Base Color to Base Color input
Connect Normal map through a Normal Map node
Connect Roughness map to Roughness input
Use Principled BSDF for a PBR workflow

One Lesson for Beginners

One texture is not enough for realism
Normal maps affect lighting, not geometry
Roughness controls surface reflectivity
Use correct color space for each map
PBR workflow uses multiple maps

Quick Debug Tip

If your material looks flat:

Check if the Normal map is connected through a Normal Map node
Ensure Normal map is set to Non-Color
Add a Roughness map to improve surface response

Realistic materials are built from layers of data, not a single image.

Understanding this helps create better assets in Blender and ensures correct results when importing into Unreal Engine.

Slow progress — but I’m building a strong foundation.

If you’re also learning game development, what was the first thing that confused you when you started?

See you in the next post 🎮🚀