I recently engaged in a conversation with someone about religion and games; specifically, about me showing, explaining, and playing the audio of verses of the Qur'an in my games. This discussion lead me to think about, question, evaluate, and eventually understand (at a deeper level) why I do this, and why I included that section in that game.

To summarize: I think the use of religion (specifically, elements of Islam and Muslim culture) in games is essential for many reasons, including breaking stereotypes and building a deeper understanding of what Islam's canonical texts really mean. In fact, the word "deen" in "Deen Games" means religion, but it also means "a way of life."

Why Integrate Religion Into Games?

So, the core issue: why bother mixing religion with games? Certainly, this is not something people ask for (barring a very narrow definition of "game" and focusing on educational aspects, usually in the form of quizzes).

Some thoughts that come to mind: - Religion, in general, is something that is often looked down upon as "backward," "violent," and not useful. - Religion in games, is seen as almost a taboo; something people just don't do. - In the past, some people have made thinly-veiled religious propaganda as games

In particular, if you look at the demographic of Muslims, it paints a similarly bleak picture: - Muslims are often portrayed as terrorists, oppressors, and backward in media - Games are no better - Muslims commonly appear as the antagonists in first-person shooters, supplanting Nazis

Knowing all this, a not-so-obvious solution becomes obvious: why not use games to counter the negativity and stereotypes around religion and Islam in particular? Games reach around the world, but can uniquely engage players interactively; can create fantsatic scenarios that don't exist outside; and can cast players in the role of those they wouldn't normally choose to be. Games can show an alternative view, and potentially build empathy for marginalized groups. (In fact, some ideologies already use games to achieve all these goals.)

That brings us back to Deen Games. Our mission is not to create religious propaganda or poorly-disguised quizzes. We actively work to create fun, innovative, unique, accessible games that include Muslim culture, history, and beliefs as an integral part of the game universe.

As one person aptly tweeted:

If your beliefs do not bleed into your creative process on some level, they are not your beliefs. I expect a game made by Muslims to have some aspects of their beliefs even if they're not overt. Scrubbing games of every hint of a belief system to avoid offense is imo offensive.

What we can Learn from Islamic Games

My specific interest within Islamic games is to create games that leave the player with an understanding and practical application of canonical texts of Islam through games. Because games allow us to create arbitrary fantastical scenarios and situations (fantasy and sci-fi in particular), this provides us a rich, fertile ground for creative expression and building a real understanding.

Creating Islamic games with visibly Muslim characters not only breaks stereotypes, but it also normalizes us in popular culture, contrary to how we're often portrayed in media.

It also confers an additional benefit: it allows us to easily break the common tropes/stereotypes of games. For example, a fantasy game like Eman Quest might contain slimes, bats, sentient rocks; but also jinns and other creatures/elements drawn from our Islamic theology and history.

It's a Trade-Off Though

Like choosing a pixel-art or low-poly aesthetic to your game, choosing to include Islamic elements comes with some down-sides. I expect the benefits to (greatly) overwhelm the downsides, which include:

• This can break immersion. In particular, the Islamic content must be well-integrated into world lore.
• It doesn't appeal to everyone. A rather vocal group exists decrying religion in games. Even Nintendo has a history of removing religious elements from various games.
• It takes practice to integrate religious identity and iconography and beliefs in games - especially if you don't want a very superficial integration.
• Not every religious quote, source, message, symbol, etc. can or should be integrated into games.

Closing Thoughts

Thanks for taking the time to read this! I highly encourage you to drop me some comments on Twitter and let me know your thoughts.

Or, if you feel up to it, why not include a visibly Islamic element/character/outfit in your next game? I would be happy to work with you on this to define something you feel happy about including in your games.

Welcome to the rather large retrospective on Eman Quest. Eman Quest, if you haven't heard about it, is a "procedurally-generated mini-RPG with memory mechanics." You can try the full game, for free, on Itch.

This retrospective covers two parts: first, the overall idea (what did I plan to achieve? What did I actually achieve? Reflections), and the key lessons learned (mostly specific to Godot).

The Overall Idea: A Procedurally-Generated RPG

I really like procedural content generation (in general), although it's deceptively difficult to implement correctly (corner cases really get you). I always wanted to make a "procedurally-generated Chrono Trigger-like RPG," although that's a huge undertaking; Eman Quest was the first step: creating a small, "lightweight" or "mini" RPG.

What, exactly, did I include in Eman Quest?

• A fixed story about life, faith, and family
• Seven different areas; these are three geographies (forest, cave, and dungeon) each with multiple biomes (frost forest, death forest, desert dungeon, etc.)
• A unique world: each time you play a new game, it picks three out of seven biomes, and generates the required maps for each.
• Unique enemies, two per area, statically-generated and balanced with careful trade-offs (eg. glass cannon, tank), and a unique boss per biome.
• Procedurally-generated equipment (weapons, armour), including their stats
• A battle system that relies on not puzzle/thinking or skills/reflexes, but memory: remember the selected tiles, pick them to get action points, chain them to get tech points, and then use them for your turn.
• Two fixed skills in battle
• A progression system with experience, levels, and stats points you can distribute to your liking (respeccing is free).

I didn't include many things in Eman Quest; specifically, I analyzed Bastion, how they cut corners to cut down on the amount of content they needed to complete the game, and applied it to my game. Specificially:

• I scrapped procedural story-, world-, event-, and character-creation, and wrote a fixed story instead
• I scrapped the world map, because it adds little or no value
• I didn't incude any NPCs or shops, because those require a lot of art/coding. (You always find better equipment in chests than what you're using.)
• I cut a few things in content: avatars, some biome variants (crystal caves), variant bosses, and unique final-boss skills.

What Went Well

Overall, I am very happy with the result, and thankful that I could finish this project, although it doesn't come quite close to my initial vision (due to scope cuts and resource/time constraints).

Things I really like about Eman Quest:

• It "feels" like a procedurally-generated RPG.
• It's balanced (monsters seem quite distinct/different to fight) even though it's on the easy side
• Quite a few people completed the game
• The memory mechanics received some compliments (more on the design below)
• I shipped. Especially considering I tend to abandon long-running projects, this is especially important to me
• I polished the game considerably, including audio (background and sound-effects)
• I received some fan-art, and several questions about my protagonist; which prompted me to create an elaborate background, and a character representing many minorities: a strong woman, a Muslim, and an African
• I represented Muslims and Islam positively, and communicated one of our values (good treatment of parents)
• I learned a lot about game accessibility, and added a few accessibility options into my game

Below, you can see the fan-art of the protagonist, Aisha.

As my first full Godot project, I'm not really proud of the code quality; as I joked on my Discord server, code quality decreases as you get closer to production!

Memory Mechanics

Aside from the technical challenge of creating a procedural RPG, I challenged myself to create a fun battle mechanic based on memory instead of reflexes or puzzles. I also received lots of good feedback about this from users, who praised the memory mechanic as interesting.

The core mechanic works simply: a 5x5 grid appears, some squares highlight for a fractional second, and then disappear. You need to click on those highlighted tiles to accumulate "action points," which you can use for different actions (attack costs 2, critical costs 3, and defend/heal costs 1).

In initial prototypes, I experimented with requiring players to pick both energy (action poinst) and actions they wanted to play. This proved to be quite "stressful," because you have a fractional second to look for both required energy tiles and action tiles; midway through development, I streamlined it into what it is now. I also tried several variations (incluiding a "simon says" type mini-game and a stream of "which of these items did you never see before"), both of which didn't seem fun enough to include in the final.

I also found that battles become somewhat rote and mechanical/deterministic after a while: you pick the five specified tiles, then pick crit, attack, and repeat, healing as necessary. To change it up, and to reward skillful play, I added techniques/skills and technical points.

Players who pick three or more tiles correctly in a row (with no mistakes) acquire tech points. If you select all five tiles correctly, you get a total of three tech points. You can save these up and use either five or seven for stun/vampire skills respectively. This adds an element of strategy and non-determinism. Tech poinst also persist across battles, adding another dimension of planning.

What Didn't Go Well + Key Insights

I initially planned one month to complete the project; it ended up taking around nine months. Why? Many reasons, including:

• I realized early on that different forests just didn't cut it, and needed both variation (styles of forests) and map types (cave, dungeon, etc.)
• Creating art was not my strong-suite, and I needed three distinct tilesets, each with two unique variations
• Finding, drawing and animating 14 monsters, and their walk cycles, took a lot of effort; even though I found many of the base sprites and received lots of help on the art side.
• I added the story about five months in, and required implementing an entire message dialog system, key-item system, final-game events, and lots of unexpected things.
• Technical struggles with, and crashes in, Godot (more on that below).

I ran into several difficulties along the way. These include:

• Learning Godot's API, which seemed quite foreign to me (anything is a scene and can contain sub-scenes). Also, Godot is quite a wide framework, and it takes time to discover/learn/use things (like UI components).
• Learning about Godot's automatic garbage-collection (free and queue_free) and how they destroy all objects when changing scenes. This caused me to rewrite my early version to completely separate data about maps (tiles, treasure, etc.) from the visual presentation of those, which got GCed.
• I wrote garbage, prototype-quality code throughout. This lead to numerous bugs (some difficult to diagnose and fix), and a cycle of "fix something but break something else" late in development. You can see tweets with some bugs, including a few hilarious ones, here.
• I didn't write any unit or integration tests. This meant I could break things without noticing for days/weeks. I remedied this quite late in development by using GUT (Godot Unit Testing).
• Lack of CI. Unlike other, C#-based projects, I couldn't get Travis to run my tests; so if I forgot to run tests, broken things stay unnoticed.
• The final game crashed a lot, which caused a lot of stress and resulted in a lot of lessons; so I wrote a section just on that.
• Close to the end of development, I lost my GPU on my main development machine, and my main Windows installed contained drivers that didn't run with Godot 3.0.6. I ended up switching to Linux (which included up-to-date drivers), but lost of a lot of time; I also upgraded Godot to 3.1.1, which initially showed a problem with cave maps running at 2-3FPS, but works fine on Linux.
• Serialization for saving games. As the Godot docs on saving games suggests, you need to manually serialize all your (nested, hierarchial) data structures into JSON. This requires a lot of boilerplate, and it's very tedious (you may miss a field and not realize unless you test thoroughly).

The Game Crashed on Release

When I released the game, it crashed. A lot. This undoubtedly resulted in a terrible first-impression, although I received several supportive comments such as "it crashed once and then I reloaded and it was fine" or "it keeps crashing after battles but I completed the game."

Why did it crash, why didn't I notice, and how did I fix the crashes? Well, I'm glad you asked.

Godot runs the game in the editor, somewhat differently from when you export the final platform-specific release. This includes differences such as caring about case-sensitivity (which the Editor doesn't, on Windows), and - critically - crashing when you do Bad Things (like waiting for an event and disposing the scene before it comes back).

I always tested Eman Quest from within the editor, so I never noticed (or cared to notice?) the errors. The game also crashed on Linux and (troublingly) MacOS (which I don't have hardware to test with), but not on Windows, so I failed to catch it in my pre-release testing.

In the end, I upgraded Godot from 3.0.6 to 3.1.1 (someone commented that it didn't work with their graphics card, and 3.1.1 works with OpenGLES 3.1 and earlier), and the crashes disappeared. I also:

• Tested on Linux (after switching to Linux) and found I could reproduce, and fix, one crash
• Fixed sporadically-appearing errors that Godot printed out, which fixed at least one crash
• Received great offers of help from people on Twitter, specifically running MacOS, who found workflows in-game that reproduced the crash, and verified after I fixed them.

Action Items

I learned several key lessons out of this. Learning about Godot itself proved invaluable; beyond that:

• Write clean code. (Clean meaning, as good as you can make it.) This results in less bugs and less painful troubleshooting later on when things turn bad.
• Export and test your project often. This catches bugs, crashes, and all kinds of badness that you don't want players to find first.
• Fix all runtime errors, and any errors/warnings Godot generates. These often foreshadow crashes when the game runs (sometimes, only on select platforms - Windows seems fairly resilient)
• Unit test everything. Unit testing is cheap, runs quickly, and pays for itself in spades; you can quickly catch issues without manually retesting everything.
• Set up a continuous integration pipeline to run your tests. With GitHub and Travis, you can check in code, and get an email whenever you broke some tests (but didn't notice by running them manually). That can be invaluable to avoid breaking things that work.
• The Godot community is awesome. Ask on Discord, open a GitHub issue, post a tweet - there are experienced developers who will get back to you, promptly, with solid solutions. Just be careful what you ask for! (I upgraded to Godot 3.1.1 and needed to redo all my UI to fix a tiny bug with one slider.)
• Always update to the latest version of Godot. It really works better, and often clears up hard-to-fix bugs.
• Make friends on Twitter. You never know who will like, follow, comment, download your game, and - critically - help often comes from those who we least expect it from.

Finally, I want to personally thank everyone who helped me with the project - you know who you are. Without your help, coaching, support, and mentorship, I would never actually finished the game.

July brought a lot of challenges. @Chemical_Ink's internet went down for several days. I ran into a very busy work schedule. All of this meant less time for Abu Hamid X; but walhamdulillah, we still managed to ship a lot of changes.

Perhaps most importantly, we decided to drop the adventure/open-world concept and stick to what we prototyped and proved as fun: the arena combat challenge. This introduced a lot of story/worldbuilding challenges, but we managed to work something out.

New features include:

• Half-hidden assassins who lunge and stab from out-of-sight
• Lava eruptions that mean instant death
• Proximity mines that explode
• Jumping enemies
• Spike traps
• And more!

For our Patreon supporters, you can download the prototype here. If you're not a Patreon supporter, consider joining us; your feedback shapes the direction of our games.

Once we get feedback, our plan is to start the actual production version of the game. You can follow us on Twitter for updates.

With the end of Ramadan cutting through the first half of June, we made little progress in the first two weeks. That makes it even more exciting that we completed the prototype of our new game, tentatively titled "Abu Hamid!"

Every prototype aims to answer a question. This prototype answers the question: "can a jetpack-toting samurai with a gun, flying around and killing hordes of enemies and giants, be a fun gaming experience?" We believe the answer is "yes!"

You can see the core gameplay elements in the screenshot:

• Running around, jumping
• Flying with a jetpack with limited fuel
• Attacking enemies with a sword
• Shooting with a gun
• Fighting giant, semi-invincible monsters (the juggling is a physics bug)

For our Patreon supporters, you can download the prototype here. If you're not a Patreon supporter, consider joining us; your feedback shapes the direction of our games.

Once we gather some feedback, we can plan the next phase and start on the actual game: planning, coding, art, sound, and more. (You can also follow us on twitter for more frequent updates.)

This month, we spent quite a lot of time planning and articulating our next project. It's a big one! Unlike previous projects, we decided to bite on something large and ambitous.

We're in the early stages of prototyping, so I can't share too many details right now (as things are scarce). Our major Islamic/educational goal for this project is to show world events through an Islamic lens. How that will play out, we will see.

As far as prototyping, we have our basic jetpack/combat system in place. You can fly around the screen and strike enemies, and they can harm you (sort of).

There's a lot of work left to be done in prototyping, but we're fairly optimistic that this will result in a fun core game loop with lots of interesting side gameplay.

We're also breaking from game development for a couple of weeks, as we're now entering the last half of Ramadan. You can expect game development to resume its regular schedule in mid-to-late-June.