Word Blocks began during an intensive period of mobile game ideation and Unity prototyping at No-Pact, the independent game studio I had co-founded. I developed the original core-loop idea and made a simple animation to communicate it to the team.

After that concept handoff, I was not involved in the game's subsequent production. I returned after the game had gained traction, taking over ad creative production and later developing related workflows for video and playable ads.

The board gives the player two kinds of information at once: incomplete words and the shapes of the spaces they occupy. Familiar block-puzzle pieces complete several words as they are fitted into the board.

Each placement reduces both the word puzzle and the remaining spatial problem. A dense board gradually opens up and becomes easier to read, giving the solve a visible sense of release.

The same visual structure is also legible in short video: familiar block shapes, a crossword-like board, and progress that can be understood within a few seconds.

The starting point varied. I might notice a useful control or camera structure in another game, separate a mechanic into parts, combine two familiar forms, use a generated constraint, or begin directly in Unity with a movement or physics question.

The cycle was usually short: isolate the question, build the smallest scene that could answer it, record or share the result, then continue, rework, or stop. The dated work log moves back and forth between idea generation, market review, scene setup, and playable builds rather than treating them as separate phases.

Ball Sweep was developed at No-Pact as a mobile physics-puzzle prototype. Each level arranged groups of balls, sweepers, platforms, and a collection target into a compact chain of physical actions. The player had to read the route, trigger mechanisms in a useful order, and deliver enough balls without losing them along the way.

The project grew beyond an initial mechanic test into a large level-design and review process. The working notes cover level ordering, tutorials, camera transitions, aspect-ratio framing, physics failure cases, difficulty, visual clarity, and recordings prepared to compare different level and presentation choices.

Thieves.io was developed at No-Pact as a top-down Unity arena prototype. I developed the original concept and worked with a programmer as it grew from a first playable into a working game with multiple internal builds.

Each round connected two kinds of play. The player first arranged defenses and obstacles around a base, then entered an arena against AI rivals to collect or steal gold and carry it home. A larger stack represented more progress, but it also made every collision, trap, and risky route more consequential.

After I left No-Pact, the studio continued the project and developed it into the fuller game released on Steam in 2016. That later production added the environments, interface, level content, multiplayer, achievements, and release material.

The released game retained the central head-controlled premise and expanded it into target-based levels across three locations, scoring and streak systems, and local hot-seat multiplayer. A 2017 update increased the level count from 18 to 45.

Different lattice morphologies can now produce successful target-directed movement. When a body encounters a passage it cannot cross directly, trial and error can lead it to movement and deformation patterns that solve the obstruction.

The next focus is coordinated, task-specific movement within a single lattice: selected particles will take on movement roles and work together so designated parts of the body can reach their assigned targets.

I began the project in 2025 with a procedural rounded rectangle that could be sized and adjusted directly in Unity's Scene view. The initial aim was practical: make a shape quick to build, tune, and reuse without preparing a separate sprite for every size or corner setting.

Using the tool kept exposing the next set of problems. The same shape needed to work in a Canvas and in a 3D scene, remain editable without losing authored values, respond to scripts and animation, and stay understandable as more appearance and workflow controls were added. The project developed by building those paths, testing them in working scenes, and revising the editor around what became difficult to use.

Orbycra Bilişim Teknolojileri A.Ş. was founded by Giray Ötken, Başak Çakmak, and Ahmet Tolgay Akıncı through the TÜBİTAK 1812 BiGG support programme. The company is based at İTÜ ARI Teknokent and develops medical visualization and patient-specific design systems.

The work has followed two main project lines. GraftEngine focused on AI-assisted graft, mold, and guide design from medical imaging data. The current DICOM Viewer direction focuses on interactive, non-clinical volumetric visualization and reusable visual workspaces.

I built GTaskSystem to keep ongoing work inspectable across different projects, documents, research records, decisions, and conversations with coding agents. It is a local working system rather than a hosted task-management product.

A compact node-edge graph stored in SQLite holds tasks and related records. Small command-line tools retrieve the part of the graph needed for a question, a decision, or a work session. Each source project remains authoritative for its own code, documentation, and detailed state.

The system has not solved prioritization or memory automatically. Its quality still depends on what gets captured, old relationships need maintenance, and several interfaces remain working prototypes rather than a finished application.

The graph is useful when it reduces search and reconstruction. It becomes overhead when the model grows faster than actual use. The current aim is therefore limited: preserve enough structure to recover context, inspect why something exists, and continue work without rebuilding the whole picture each time.

I continue to develop GTaskSystem through daily use and plan to release a public version once the core model and workflows are stable enough to be useful outside my own setup.

The current library contains working analyses for project time allocation, release preparation, creative-production planning, research targets, purchasing comparisons, and staged experiment selection.

The useful result is not a claim that the highest score is objectively correct. It is the ability to see which assumptions produced that result, adjust them, and return to the same decision without reconstructing the whole argument.

The application is a working local v2 prototype. Results, matrix inspection, editable weights, score evidence, JSON import and export, staged analyses, proposals, and version snapshots are implemented.

It is not a decision oracle, and it does not yet have a formal benchmark. Generated starting points still need review, the current persistence layer is JSON-based, and deeper comparison between branches and versions remains under development.