December 2016 Game Dev: 2D PCG Shooter

We’re out of time, so I can run with anything.

I replaced the original hero sprite because it’s stock photography.

I’m in the camp where the user should have a very specific story and background, because that’s how you build a solid story about them. Not by them being generic. Either way, we’re good to go so far.

I’ll check in roughly 12 hours from now (10pm EST).

From a code perspective, I have crushed the last of the known bugs.
The remaining issue is just a minor performance concern.

We never did write a title screen/main menu, but that does not appear to be in the MVP scope on the github checklist.

Graphically I think the game still needs a lot of polish, but as you say we are out of time.
We are still running a lot of the original place holder sprites.

Beyond this, some more enemy types, etc would be nice but that is a list that can go on forever and is outside of the MVP scope.

Feel free to do anything you feel would add value. There’s always a risk of breaking existing stuff with new stuff, so I hesitate, but there you have it. I would like to release this today, perhaps.

Other than play-testing, it sounds like everything else is done. So why not play the game, and see what you think of the overall experience?

I think I need to nerf some stars and stuff.

For the title screen, I was thinking of either a simple splash-screen like the others, or title text that fades out immediately after the intro story panels. Either should be a piece of cake.

I forgot that we have a family invite today, so my contribution may be reduced. A thousand (actually, make it a million) apologies for not being available as much during the last few critical days. May Allah forgive our shotcomings and accept our humble efforts (ameen).

Just out of curiosity, how do you personally guage the success of a project?

From my perspective I have always thought that a successful game dev project is where the total play hours > total development hours.

I have more than a few projects from my younger years where I would spend a week coding a game, only to get bored of the result less than an hour in.
The most successful game I ever created was a 2 hour long project I coded idley while watching tv.

  • Just a black screen with a heap of circles bouncing around the screen boundry.
  • If a circle collides with the mouse pointer it is game over
  • pressing the left mouse button put a blue shield circle around the mouse.
  • Points are earned for every frame the player survives
  • Every time the circles bouce of a wall they gain speed
  • Every time the circle bounces off the sheild, they gain Lots of speed.
  • Sheilds consume energy which replenishes at a much slow rate than it is consumed.
  • Instead of clearing the screen and redrawing the buffer on each frame, I would draw randomly sized and placed black circles over the existing buffer.
    • This created object trails with a cool disolve effect.

The project in total took me 2 hours to write and I would play in batches of about 5 minutes here and there.
But the game was fun, very easy to jump in and out of so it go so many plays sitting on my desktop over the following year that I would have played that amount of time many times over.

My point is looking at this project. I have put in an average of 2-3 hours / night, placing me at about 60-90 man hours all up. You have likely put in the same and with the art team we are likely looking at about a 200+ hour project easily.

Looking at the content and game mechanics, I would estimate the average player would b retained for 15-30 minutes? meaning by my estimation we would need roughly 800 unique players for this project to be an overall success.

So looking at the project as it currently is, my 1st thought is what theoretical time investment would do the most to improve average player retention time.

  • Polishing art assets could help retain players who are initially turned away by the art style
  • Adding more content (Discreet stages, unloackable enemy types, etc) would reward players for getting further in the game.

If we continue this project as a 2nd phase for our 2nd project, do you think we could do more than double average player retention time as a trade off for doubling our development time?

I have a very shallow criterion: did I launch the game or not?

If I launched it, even if it’s not that great (there’s always room to improve) and hardly anyone plays it, it’s still a success. Because that’s what matters: I set out to make a solid Islamic/educational game, and I finished, alhamdulillah, and the reward is with Allah.

My typical experience is something like 10 hours of development for 1 hour of gameplay. A Day and a Night’s final incarnation took 6 weeks initially, and another six weeks; so I’ll estimate 120+ hours of dev time, for something that takes, at most, 30 minutes of gameplay (240:1).

The more you polish the game (features, bugs, UX, art, etc.), the more it goes from “dressed-up half-baked toy” to “awesome, real game.” So there’s a long-tail where you get diminishing return. That’s what makes a good vs. great game.

I can say a lot more, but let’s leave it there for now. We still need more playtesting before I can release it. I think we’re done, right?

While we’re done, I think there’s at least a few days more worth of work that we should do before we can release this and feel comfortable that it’s a really polished product. There’s more polishing we can do, and it does look awkward.

Since I subscribe to the cult of done manifesto, I’m going to label this in GitHub as release 1.0, but not crank the Marketing Machine yet.

I’ll close the GitHub issue and open a new one, and we can proceed as usual… @severok please join me in creating a priority list of the minimum we need to make this game feel complete, let’s aim to ship 1.1 on January 7th.

Do you disagree?

Personally, I think it needs a proper name, titlescreen or equivalent, and the art still needs tweaking. The gameplay feels imbalanced, but I haven’t played enough games for the sake of playing to be clear on what to fix. There’s some internal clean-up we can do too.

v1.0 is nowpublished on GitHub. Tell your friends, if you like.

v1.1 backlog is here. I think we should discuss adding more types of enemies (three seems like too few), and maybe different ships (eg. light / fast / shoots-slowly or can only handle pistol/machinegun vs. larger / slower / more health / heavy weapons only)

I am very conflicted about how to proceed from here.

On one hand we have done a lot of work on this 1st project and would love to see this brought to completion.
On the othe hand, the whole point of this project is to manage resources and timelines to see what we can produce in 1 month.

At this point of time, I am considering this 1st project to be completed as per the scope of this project, but appriciate it does need more work before it is released properly.

In terms of this overarching project I recommend shelving V1 of this project as our official submission for the Dec 2016 project and commence work on the Jan 2017.

Something I noticed in the previous project is that we really need a soild design foundation as we move into these projects in terms of genre selection, game themes, art style, game mechanics as the design-as-we-go method we used last time leaves a lot to be desired in terms of making a cohesive product.

What I propose is:

Project 2 starts now,
Week 1 - Design phase:
Week 2 - Initial coding phase & Early art assets
Week 3 - Feature coding phase & Art integration
Week 4 - Testing, polishing and balancing

Right now we need Ashes, Blood and Rocket working together to select a new genre, game mechanics and overall design.
This time I want some sort of design documents/plan to work to with outlines on paper for the parts required for the game and how they all work together.

We should pick a Genre / Theme that opens up for better story telling as our genre/mechanic selection last time ultimately put that to waste. Maybe we can shoot for a low scale turn-based RPG?

If we go this way, My coding isn’t really needed until week 2 when we have the design set, so I can spend this week working on V1.1 of the previous project, ready to hit the ground running on the current project once the team is ready.

Blood is out and Roket is 50-50 at this point. I wouldn’t count on them for now.

I appreciate your perspective. I think your suggestion of shelving V1 is a good one. Cutting off and starting fresh is more towards the over-arching goal. Slipping in a second release in a week just seems like going back to the old (mostly broken) way of doing things.

I honestly feel the last few days were really stressful for me, and overall I’m not sure if I pulled my weight. If I’m just project-managing and not designing, coding, etc. then what am I really accomplishing? I’m a coder, not a team lead or a manager.

You mentioned you’re unavailable for two weeks in Feb, so we can treat this as “Jan + Feb together” one month with some downtime.

Lines of code is a horrible metric, but regardless, here’s how our contributions worked out: https://github.com/MuslimGamer/pcg-shooter/graphs/contributors

It looks like you may have reintroduced a crash bug (import bug) on Linux (?!), which I again just fixed now, so it’s worth explaining.

TLDR: to resolve recursive imports, we import a.b.C instead of from a.b import C

We have a depdency cycle; here’s a crash stack:

Traceback (most recent call last):
  File "main.py", line 30, in <module>
    from shooter.player import Player
  File "/home/user/Dropbox/Python/pcg-shooter/source/shooter/player.py", line 8, in <module>
    from shooter import obj
  File "/home/user/Dropbox/Python/pcg-shooter/source/shooter/obj.py", line 643, in <module>
    from shooter.bullets.bullet import Bullet
  File "/home/user/Dropbox/Python/pcg-shooter/source/shooter/bullets/bullet.py", line 2, in <module>
    from shooter.bullets import rocket, basic, melee, explode, railcharge
  File "/home/user/Dropbox/Python/pcg-shooter/source/shooter/bullets/basic.py", line 2, in <module>
    from shooter import obj
ImportError: cannot import name 'obj'

It looks like the cycle is main.py => player.py => obj.py => bullet.py => basic.py => obj.py

The resolution is, everywhere (or in particular, in basic.py for a quick fix), use import shooter.obj instead of from shooter import obj.

This works because import shooter.obj does some sort of future-declaration where it says “oh yeah when this thing is imported, come back and we’re good” instead of “import this right now and oops, we’re not done importing that so we can import that.”

I’m trying to build the final binaries and it’s frustrating that things keep breaking. Apparently, hiding the splash screens also hid another bug.

I also added source image files and reorganized the folder structure.

I’ll do more testing tonight inshaAllah on the final binaries and ship it if it works. If you would like to help (I’m waiting for your feedback on the January thread), please run build.bat and then dist/main.exe to see if you find any bugs. After pulling from master.

Signing out. I found three bugs:

  • Shields don’t die when you die (fixed)
  • Game over noise is almost inaudible (fixed)
  • Start a new game (re-run game), don’t move for a minute. Then move/shoot. You get swarmed.

I’ll see what else I can find/fix tomorrow.

Finding the last bug gave me a perverse sort of joy I can only describe as:

ZERGLING RUSH KEKEKEKEKE ^________________________^

It looks like the spawning is happening correctly (NPCs and enemies), and they’re spawning off-screen. And they’re not dying. But once you twitch, they all mob, and at THAT point somehow some of them die (I can only blame the flies with their PEW PEW laserz).

Fixed: looks like we were incorrectly handling tutorial button clicks and stuff.

If I must soldier on alone, so be it.

I started logging everything I find/fix here: https://github.com/MuslimGamer/dajjals-minions/issues/4

I have again reached the point of “zero known bugs” and I’m resuming my methodology of “build binaries, play binaries” until I find bugs; then switch to source, fix, and back to binaries.

I fixed a number of bugs, including:

  • Enemies accumulate and spawn en-masse if you leave the tutorial window open a while
  • Enemies accumulate and spawn en-masse if you leave the game paused
  • Reloading when dead causes a crash dump in the console window

I still (occasionally) see the pistol reload instantly, but I can’t figure out reliable steps to reproduce it.

I must once again put on the game-designer hat. While we built some really cool weapons (rocket launcher, rail gun, machine gun) they are, practically speaking, flawed in their balance and almost impossible. I feel like I’m fighting the controls (knock-back on firing shots, weapon reload times) to stay alive, not that I die because I made mistakes.

So I’m accumulating a list of game-design fixes, including:

  • Firing shots doesn’t move you
  • Shotgun spreads wider
  • Machine gun spreads less
  • Rocket-launcher reload is too long or bullets are too few
  • No feedback on health loss. You should stop dead in your tracks and hear an audio.

I’ll keep GitHub updated, please use that as THE place to find work inshaAllah.

Signing out.

Signing out.

Quick list of stuff done:

  • Audio feedback when you collide with enemies
  • Bullets don’t send you flying (toggleable by apply_recoil config setting)
  • Shotgun spreads shots evenly (toggleable by even_bullet_spread config setting)
  • Shooting doesn’t apply recoil to you
  • Bug: railgun doesn’t deplete bullets
  • Bug: you can reload with full ammo
  • Design: tweaked shotgun spread to be a bit wider

If you have time, I would really appreciate it if you could finish the alert label thing.

@Severok we’re a team, so we should stick together (on one project). I understand the allure of new projects. new technologies, new cool stuff to engineer, so I’ll let it slide if you’re not interested in picking this up again.

My wife played this today (she’s not much of a gamer at all). I got some feedback from her, but more importantly, I got to observe how she played.

I need a second opinion @severok @bloodmoney should we go back to the old control scheme? It’s much easier to master. I still feel the current controls, you have to wrestle them into submission.

I also got a bunch of feedback/usability/balancing tweaks from my observations which I plan to add.

Today, I just…messed around with guns for fun. Yeah, I know, it’s pointless.


Signing out.

  • Fixed a bug where spawn income is incremented twice.
  • Enemies are slower to appear on new game
  • Enemy spawn rate nerfed to 50%

Today is a good day. I feel that hyper-motivation rekindling as the project practically comes together to completion. It’s almost there!

I completed several seemingly-inconsequential but wonderfully-usable tasks:

  • Flies are twice as large. This makes it very, very easy to distinguish them from escape pods in the heat of battle when you’re surrounded and only have your peripheral vision to rely on.
  • Nailed that sporadic-reload bug to the wall. Turns out when you fire, wait (eg. 5 seconds), then hit reload, we say “oh you reloaded five seconds ago, full ammo!”.
  • Escape pods blink. Makes them discoverable to the user (why is this one thing blinking? let me touch it!) and hopefully more easy to see in a pitched battle.
  • Healing is about twice as effective. This makes it almost possible for me (“expert” gamer – I know how all the systems work, mostly) to win. It feels like victory is achievable now.
  • Lots of alerts: when you get hurt, when you heal, when you have a full crew and your drive boosts 10%, weapon pick-ups (from before). This removes those “huh?” moments when you “suddenly” die (didn’t realise how much you got it). Ditto for those “huh?” moments when you don’t die (thanks to healing).

Over and out.

That’s a wrap.

Final highscore (no cheating, I promise):

Today’s achievements:

  • Better end-game victory story sequence
  • Alerts when you lose crew members, get upgrades
  • Fixed a splash-screen/UI bug I introduced recently
  • Updated icon to use Severok’s ship one (more or less)
  • Fixed: alerts should disappear on death
  • Nuked some dead code

Alhamdulillah, I’m very happy with the final product.

I’ll crank the Marketing Machine on this tomorrow inshaAllah. Lots to do – screenshots to take, blurbs to post, people to bug on FB, etc. etc. ad nauseum.

May Allah reward all you guys for your hard work and efforts/intentions, even if you didn’t deliver as much as you would have liked. I’ve donated $20 in your name (all of y’all, like one $20 not each ya’ne) as a sadaqah jariya to build a water detoxification system in Gaza.

Onward and forward (but for now, outward)!

Awesome stuff.

I look forward to playing the release version to see how it all came together.
Jazakallah for the final push to polish it all up.

This, in my experience, is what makes or breaks Deen Games. May Allah accept all of our efforts. Without the team effort, honestly, it wouldn’t be a quarter of what it is today.

For posterity: I added (very, very ugly) gamepad support for my Logitech F310. InshaAllah I will push it to my ODroid console and see how my 8yo does.

For reference, I added it to the Deen Games fork of the MG repo (I can open a PR if you want): https://github.com/deengames/dajjals-minions

He will do fine.
I was gaming by time I was 4 on my families Amiga.

I would try with my 1 yr old but he already trashed my PS3 controllers and rips the trackpoint off my Lenovo laptop every chance he gets.

1 Like