DYNCAST / THE DEVELOPER BEHIND THE CODE

15+ years in the game.Still building what’s next.

What started as a fascination with Metin2 became a lasting curiosity about how games work, how systems connect, and how code can transform the player experience.

A little about the person behind it

DynCastIndependent Metin2 developer

Status unavailableLet’s talk

Need a starting point?Message template

Make it yours, then copy it into Discord.

Sent by you, when you’re ready.

DynCastA place for systems, ideas & conversation.

The communityJoin my server

INSIDE THE SERVERUnavailable

Channel preview is temporarily unavailable.

Explore what’s being built. Share what you have in mind.

15+YEARS IN METIN2

C++THE LANGUAGE OF MY CRAFT

01OBSESSION: THE DETAILS

It started with
curiosity.

Over 15 years ago, Metin2 was a game I enjoyed. Over time, it became something I wanted to understand, explore and improve.

THE QUESTION THAT CHANGED THE WAY I LOOKED AT IT“What if we could
make it better?”

LOOKING BENEATH THE SURFACE

I started looking beyond the interface: how a feature works, how efficiently it runs, and how naturally it fits into the game. Small details began to feel like opportunities.

BUILDING WHAT COMES NEXT

That question became the foundation of DynCast. Today, I build custom Metin2 systems that bring careful engineering and thoughtful interfaces together. The curiosity is still the same.

02 / THE PHILOSOPHY

Built with intention.

Different parts of the work.
The same attention to detail.

01less overhead. more possibility.

Performance is a feature.

Clean architecture, efficient execution and careful resource management. A system should feel effortless, even when the work behind it is complex.

02every interaction counts.

Details define quality.

The timing of an animation. A useful tooltip. An interaction that simply makes sense. These aren’t finishing touches — they’re part of the system.

03clarity today. confidence tomorrow.

Built to last.

Readable code, thoughtful structure and room to evolve. I want the next change to feel like a natural extension, not a fight with what came before.

03 / THE CRAFT

More than just
making it work.

From server-side gameplay logic to client interfaces, I care about the entire experience — the architecture players never see and the details they interact with every day.

Modern C++ gives me the tools to express that intent clearly. The real work is choosing the right structure, handling the awkward cases, and making a feature feel at home in Metin2.

Explicit intent: Clear contracts. Fewer surprises.
Thoughtful structure: Code that can evolve with the system.
Careful execution: Attention to what happens beyond the happy path.

A small, compilable statement of philosophy. The commercial implementations stay with their products.

BuildPolicy.cppHover the underlined conceptsC++23

1#include <concepts>
2#include <cstddef>
3#include <cstdint>
4#include <expected>
5#include <type_traits>
6
7namespace DynCast {
8	enum class QualityAspect : std::uint8_t {
9		Performance, Precision, PlayerExperience, Reliability, Maintainability
10	};
11
12	enum class RequirementStatus : std::uint8_t {
13		Pending, Satisfied, Rejected
14	};
15
16	enum class QualityError : std::uint8_t {
17		RequirementNotSatisfied
18	};
19
20	template <QualityAspect Aspect, RequirementStatus Status>
21	struct Requirement final {
22		static  QualityAspect Category = Aspect;
23		static  RequirementStatus State = Status;
24
25		 static  auto Satisfied()  -> bool {
26			return State == RequirementStatus::Satisfied;
27		}
28	};
29
30	template <typename RequirementType>
31	 QualityRequirement =  {
32		{ RequirementType::Category } -> <QualityAspect>;
33		{ RequirementType::Satisfied() }  -> <bool>;
34		typename <QualityAspect, RequirementType::Category>;
35		typename <RequirementType::Satisfied()>;
36	};
37
38	template <QualityRequirement... RequirementTypes>  (sizeof...(RequirementTypes) > 0)
39	struct EngineeringPolicy final {
40		static  std::size_t RequirementCount = sizeof...(RequirementTypes);
41
42		 static  auto Ready()  -> bool {
43			return (RequirementTypes::Satisfied() && ...);
44		}
45
46		 static  auto Evaluate()  -> <std::size_t, QualityError> {
47			if (!Ready())
48				return { QualityError::RequirementNotSatisfied };
49
50			return RequirementCount;
51		}
52	};
53
54	using Philosophy = EngineeringPolicy<
55		Requirement<QualityAspect::Performance, RequirementStatus::Satisfied>,
56		Requirement<QualityAspect::Precision, RequirementStatus::Satisfied>,
57		Requirement<QualityAspect::PlayerExperience, RequirementStatus::Satisfied>,
58		Requirement<QualityAspect::Reliability, RequirementStatus::Satisfied>,
59		Requirement<QualityAspect::Maintainability, RequirementStatus::Satisfied>
60	>;
61
62	(Philosophy::Ready(), "DynCast: Quality is never optional.");
63} // Namespace DynCast

A STATEMENT OF INTENTDemonstration source

04 / FROM SOURCE TO EXPERIENCE

The player feels
the whole system.

A feature doesn’t end at a working function.
It ends with the person using it.

Engineering underneath.

Reliable logic, clear boundaries and considered resource use form the foundation. The parts players shouldn’t have to think about.

Clarity on the surface.

Interfaces should explain themselves. Useful feedback, readable information and purposeful motion make a system easier to understand.

A better moment in-game.

When the two work together, the feature fits the game. Less friction, more intention, and more attention left for playing.

HAVE SOMETHING IN MIND?

Great systems start
with great ideas.

Looking for a custom Metin2 system, have a technical question, or simply want to discuss an idea? Let’s talk.

Let’s Build Something Explore my systems

DynCastIndependent Metin2 developer