Solfreaks Games is how we build mobile and casual games for Android and iOS, in 2D or 3D, using Unity, Godot or native Kotlin and Swift code depending on what the game needs. We also take work-for-hire jobs from studios and publishers who want extra development capacity on a game they already own.
Most games don't fail because the graphics were weak. They fail because players try them once and don't come back the next day. So we build the smallest playable version first, put it on real phones and look at retention before anyone pays for art and content.
What a game project includes
- A playable prototype of the core loop on a real phone, usually within two to four weeks, with placeholder art.
- A short design document covering the loop, progression, difficulty curve and in-game economy, written to be read rather than filed.
- Level tooling that keeps levels in data files, so someone can adjust difficulty without waiting for a programmer.
- Monetisation wiring for rewarded ads and in-app purchases, with ad frequency and prices adjustable remotely instead of through a new release.
- Analytics events for level starts, fails, retries, session length and the point where players quit, so retention is something you read instead of guess.
- Low-end phone testing of frame rate, memory, download size and battery drain on cheap Android devices as well as flagships.
- Store release with signed builds, listing assets, content rating forms and a staged rollout.
From first sketch to the store
- Concept call. We talk through the idea, the audience and what the game must do in its first two minutes. A one-page concept follows within a few days, including what we'd cut.
- Prototype. Two to four weeks to a playable core loop with placeholder art. This is the cheapest moment to learn that an idea isn't fun.
- Retention test. A small group of real players gets the build. We watch who retries, how long sessions last and where people stop, then decide together whether to carry on, change direction or stop. Stopping is sometimes the right answer.
- Production. Levels, art, sound, menus, progression and monetisation get built in fortnightly builds you can install and play. A simple casual game typically needs two to four months from the start, and 3D worlds or online play take longer.
- Soft launch. We release to a limited audience first, through a closed test or a few smaller markets, tune difficulty and ad frequency from real data, and put the game through app QA and testing on a spread of cheap and mid-range phones.
- Live updates. New levels, events and balance changes ship regularly, because a game that never changes gets uninstalled. Proper analytics setup tells us which updates actually bring people back.
Who this suits, and who should look elsewhere
It suits founders and small studios with a casual or hyper-casual idea, brands that want a game as part of a campaign, and publishers who need a dependable build partner for a title already in production. A design with no programmers works, and so do programmers who have never shipped to a store.
A different studio will suit you better if you're picturing a large 3D multiplayer game with console-quality visuals on a modest budget. That takes a bigger team than ours, and we'd rather say so now than in month three. It's also not for you if you need guaranteed downloads or a guaranteed hit. We build the game and the measurement around it. Nobody can promise that players will turn up.
Game costs and release timing
Price follows scope: 2D or 3D, how many levels and how much content, who produces the art, whether there's multiplayer or an online backend, and if you want one store or both. We work on fixed scope for the prototype and production phases, or monthly for live updates or for a developer embedded in your studio.
As a rough guide, a prototype takes two to four weeks and a simple casual game usually takes two to four months overall. Income from ads and purchases is easier to plan once app monetisation is designed alongside the game instead of bolted on. The quote follows a short discovery call, and we don't give figures before it because they would only be guesses.
Why Solfreaks for games
We're based in Rawalpindi, next to Islamabad, and work in Pakistan time, which overlaps with the Gulf and UK working day. We have apps published on Google Play, so the store side of a release isn't new to us. The team is small, you deal directly with the people building your game, and the source code, project files and store accounts are yours. If you have an idea or a project that needs more hands, tell us what you need and we'll arrange a short call.
Open-source tools and references
A few public projects that come up a lot in this kind of work. They belong to other people and teams. We link to them because they are worth a look, not because anyone pays us to.
- godotengine/godotOpen-source game engine.
- libgdx/libgdxCross-platform Java game framework.
- Unity-Technologies/UnityCsReferenceReference source of Unity's C# layer.
Frequently asked questions
Unity, Godot or native: which would you choose for my game?
It depends on the game. Unity is our usual pick for 3D, for games that need many third-party SDKs, or when you plan to hire Unity developers later. Godot suits lighter 2D games and has no licence fee. Native Kotlin or Swift only makes sense for very simple games. After the discovery call we write down our recommendation and the reasons, so you can argue with specifics.
I have an idea but no artist. Can you still start?
Yes. The prototype uses placeholder art on purpose, because at that stage you're testing whether the loop is fun, not whether it looks good. For production we can work with your illustrator, bring in freelancers, or use licensed asset packs. We'll list which assets are bought and under what licence, so there are no surprises when you want to publish or sell the game.
How do you find out early whether people will keep playing?
We build analytics into the prototype and give it to a small group of real players. We look at whether they restart a level unprompted, how long a session lasts and where they quit. It isn't proof that the game will succeed, and we won't pretend a magic number exists. It does expose the obvious problems while changing them is still cheap.
Who owns the game, the code and the store accounts?
You do. That covers the source code, the project files, the art and sound we produce for you, and the developer accounts the game is published from. Third-party items such as the engine or bought assets keep their own licences, and we point those out. For work for hire with a studio, ownership follows the contract we agree with you.
Can you join our studio's project as work for hire?
Yes. We can take a feature, a port, a set of levels or the day-to-day development of a game you already own, working in your repository and your tools under an NDA. Pakistan time overlaps with the UK and Gulf working day, so daily stand-ups are practical. The arrangement can be fixed scope or monthly.
Talk it through with us
Tell us what you are building and where it hurts. You get a straight answer, a plan and a price, and if we are not the right people we will say so.
