December 2016 Game Dev: 2D PCG Shooter

[Severok]

I have merged the exsisting Ashes and Severok branches.
I am seeing the intro dialog, but NPCs do not appear to be spawning.
Edit: NPC issue resolved.

Bug count: 5 resolved.

• Audio bug under linux

• Screen wrap bug

• Railgun reloads on charging shot instead of after firing.

• NPC not appearing after spawning (Not yet in bug list)

• Possibly fixed: game over not relyably triggering.

• Confirmed un-resolved, but possibly less common?

• Issue repeated upon death while charging railgun

• May be caused by NPCs & sheilds occupying Player_list
  * Done so as convenience method as they fit the profile - Collsision with Bullets + Enemies

• Have Segregated Player from NPCs/Shield. Should Insha Allah resolve issue with triggering Game over.

  • Lose of player now means empty Player_list

Now working on: Game Slowdown - Slowdown on holding attack button

Additional:

• Railgun can be obtained in game from drop.
• Bullet frame processing time decreased
• No need to recalculate rotation of bullet sprite as bullets have no change of direction after spawning.
• Bullets now have simplified move function in their subclass.
• Rotation is assigned to bullet sprite in bullet subclass init.
• Finished Player Deflector shield (Formally sword)
  • Provides mouse-controlled point defence over a small area
  • Can be used to push back enemies or deflect enemy weapon fire.
  • Fun to use and feels more thematically approriate.
• Tweaked player ship speed. Much more responsive now.
• Doubled NPC movement speed.
• Intend to NPC to be valnerable to make them a higher immediate priority for players. Boosted speed as per request on github issues page.

Issues encountered:

• Pistol reloading instantly bug - Can not be reproduced. Can you please confirm this bug still exists?

---

Audio bug under linux has been resolved. - Culprit appears to be syntax of calling sound to be played, EG

Original:

def update(self): 
    if self.__shots_left == 0 and not self.is_reloading(): 
        self.__shots_left = self.__total_shots 
        self.reload_sound.play

Corrected:

def update(self): 
    if self.__shots_left == 0 and not self.is_reloading(): 
        self.__shots_left = self.__total_shots 
        self.reload_sound.play()

Adding ‘()’ calls for play function of player class to be processed.
I am guessing that the python interpreter used on your windows system is less particular than the version I am using. Once I added the (), reloading sound plays as requested.

---

Player screen-warp bug resolved.

• I am allowing the player to wrap from 1 side of the screen to the other in the style of Asteroids. A bug allowed the player to screen wrap on the bottom and left, but not top and right.
• Old code was in place to keep player on screen. Code kept player contained in upper and right regions preventing screen wrap.

---

Ammo decreases on player triggering attack.
Usually not an issue, but for charging attacks this causes premature reloading.

Solution: Added conditional to player.fire() to check current weapon type is not ‘rail’ before decreasing ammo count.

On rail_charge entity death (Transition from charging to firing), player.reload() (Manual reload function attached to key:r) is called to trigger reloading after fire.

---

NPC AI function started with check ‘NPC.is_on_screen’.
NPC spawns off screen, thus never recives command to wander on screen.
Removed check. NPC AI should never direct an NPC off screen.

---

On player death (In event of bug):

• Onscreen text removed
• No game over text or score displayed.
• AI persists.
• Occurs regardless of player weapon (previous theory of occuring during rail charge)
• NPCs still spawning
  • Subsequent crash occured when left to run in failure state as Player_list[0] now contains NPC not Player entity. Some code triggered player weapon swich on entity that does not have this function.

Possible solution:

• in object move function on evaluating health < 1: Added self.on_death() call.
  • Not sure if good fix, but Game over now triggers reliably.
  • No error state triggered since fix implemented. Previously occured roughtly 50%
  • Error state occured again. Significantly less common than before.

Better solution:

• Added NPC_list and segregated Player object from NPC
• Player list now empty on player death, probbably as intended during original game-over scripting.

Checking out now.
3 remaining bugs

• Minor: Player ship does not spawn in correct position. Updates as soon as moves.
  • Looks strange
• Minor: Slowdown on players continual attacking
• Possibly due to rapidly checking and comparing timestamps to find when ready to fire again? Otherwise possibly due to checking for existance of rail-charge from bullet list while holding button.
• Minor: Pistol reloading instantly bug from github list - Can not reporduce.

The remaining bugs are fairly minor. With the exception of the player ship originally appearing in wrong position, remanining bugs not particularly noticeable.

If time tomorrow, will attempt the player ship bug again. Otherwise shifting to aiding art team with sprite assets.

---

Quick question regarding the config file for storing variables.
Is there much consideration needed for time required to pull a value from the config file using your function?

Earlier I was considering setting the ship thrust and rotation variables in the config file so that blood can tweak it, but those values are read fairly regularly and I was concerned about the required overheads vs having those values hard-coded.

As far as I understand it, the config code reads the file on each request?

[Severok]

Salaam all.
How’s the team going today?

Last push tonight I guess.
Where should I be focusing my efforts?

[ashes987]

Wa’alikum as-salaam,

Sorry, personal stuff happened (eg. sick kids). You are a wizard with bugs, mashaAllah tabarakallah. And those awesome planets NEED to get into the game, like, now.

Could you please see how far you get through these, in order:

• Make the captain look less evil (unless you think it’s fine)
• UX tasks (text appears and disappears shortly when you get attack rate up, etc. and also crew lost and jump-drive charging)
• Re-do the ship. Honestly, it looks too big, and at that scale, it aliases really hideously.
• Make a proper escape pod image
• Delete (or recreate, if there’s time) any planets/suns/etc. that don’t fit in with our style? Deleting is easier.
• Make the rocket look nice. Brown, maybe? White looks hideous.
• Make an app icon? Using the ship is fine.

BTW, all branches are cross-merged as of my main commit (tutorial). Please merge mine in (new art etc.)

Signing out

[Severok]

I have resolved the bug where the player ship sprite initially spawns off center.
Once the player object is spawned, just call player.move()
This function calculates the sprite center for the current position/rotation and updates the sprite w/ offset so the center of the sprite is object x,y rather than the bottom-left pixel.

---

I have still been having some issues with the bug where player death does not always trigger game_over.

A few times I thought the issue had been resolved, only to have it randomly occur again later.
So far I had not been able to reliably reproduce the issue:

• Death by collision
• Death by bullet
• Death with NPC on screen
• Death during continual firing

etc, No attempted stimulus reliably seemed to result in the issue reoccuring.

By current theory is that the issue is caused by the player having the health regen upgrade (from crew).
While the player health shows as an integer, behind the scenes this is serviced as a float where the crew regen the ship health by a decimal value every frame. When this passes the next whole number, the player lives count visially increases.

The function that detects an objects health = 0 (move()) defines the objects death as health < 1. In the event of the player taking a hit when the health is 1 < health < 2, the players resulting health is < 1 resulting in the player object being despawned. This however might cause a discreprency elsewhere if the code to trigger the player.on_death callback function defines player death as health = 0.

To remedy this, I added a line of code stating if health < 1: health = 0.

This bug has not reoccured since, though I am hesitant to call it closed given my past experiences.

---

The final registered bug regards a slowdown that occurs while the player is continually firing.

I have optomised the code in several places, removing much unneded maths and other processing, however this seems to persist for me.

The issue is in no way game breaking, just a drop of a few FPS for a second or so when the mouse is pressed and held.

Not sure if you can confirm this is being observed elsewhere, my machine is admitibly very underpowered.

---

I don’t have any big issue with the appearence of the players space suit in the into dialog.

We associate the space suit design with humans, so contrasted against the inhumane vissage of the Dajjal; it is sypathetic or even heroic.

I am in the school of thought that says you want the protagonist in action based media to be a blank slate (EG in action movies the main character is always bland in contrast to some sidekick or villan) as it helps the viewer to project themselves into the role while watching/playing.

The space helmet also lets us side-step the issue of drawing human faces which I find challenging artistically and some will have issue with theologically.

Edit: So I just pulled the repo because apparently I had not done that yet, and I now see this avatar has changed drastically.

What prompted the change?

---

How does this design look for the player ship?
I am using the dimensions of the original triangle sprite and a softer colour pallet.

The design incorperates the general style of the 2nd version sprite with the front and rear facing thrusters, Cental mounting point (If I have time to add the weapon turrets) and now a forward positioned viewing window to communicate the size of the ship.

---

I am basing the design of the crew pods on the escape pods from Starwars

Im not satisfied with it yet. I would like to match the colour pallet with the player ship so the player knows straight away that they are connected.

The sprite is roughly half the size I am planning the player ship to be, This along with a common colour scheme should Insha Allah communicate to the player that they are on the same team, but these guys are weak and need protecting due to their smaller size and round shape in contrast to the players larger size and jagged shape.

---

I have removed the lense flare and sun sprites as they seem to difficult to translate into pixel art for the moment.

The nebulas remain, but I am considering removing the brighter coloured one ans it clashes with the current player/escape pod colour scheme

---

Shrunk the width of the rocket to make it more streamlined.
Replaced the white chassis with Brown/Gray, Black stage banding and a red-tip warhead.

---

Im not sure if this is more an Icon or a movie poster.
This was cobbled together in a few minutes using existing assets.

I had an idea in my head for the Dajjal watching over the players struggle as some sort of futuristic gladiator

Or if you just want a minimalist image:

---

I started adding a function to the ui_manager class called alert() which accepts arguments for x, y, text, colour and timeout.

The idea is that when you want to spawn a temporary label you call this function indicating the position, message, colour and how many frames the message will be displayed from. Some possible implementations being:

EG: On weapon pickup
ui_manager.alert(self.x, self.y +100, "New weapon: " + PickupType[Target_object.id], ‘White’, 60)
is intended to display a white message just above the players ship on collecting a shotfun pickup saying “New weapon: Shotgun”

EG: On Crew pod reaching player agro range
ui_manager.alert(self.x, self.y + 100, “Help me!”, ‘Blue’, 60)
is intended to display a “Help me!” Message above the crew pod in the event of the player entering into range where they are noticed by the pod.

EG: On Crew collection - in player.upgrade()
ui_manager.alert(self.x, self.y+100, "Crew collected: " + Message[Crew_count], “Green”, 60)
is intended to display a green message just above the player ship on collecting a crew pod with a message referenced by a dictonary against the current crew count. Should display a Green message like; “Crew collected: Ship Repair team upgraded”

The issue however is that given ui_manager is a class that is originally called from the main.py file, I am not entirely certain how to call this function from obj.py where the relevent event is located.

I am imagining this object hirachy as a tree main -> proc -> ui_manager.class and main -> obj -> object.pickup().
I am not entirely certain how a function in 1 branch references a function of an object in a completely seperate branch other than just making the relvent object global.

If you can run with this, than please do otherwise just disregard this function.

[ashes987]

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).

[Severok]

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.

[ashes987]

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).

[Severok]

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?

[ashes987]

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?

[ashes987]

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)

[Severok]

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.

[ashes987]

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.

[ashes987]

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

[ashes987]

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.

[ashes987]

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.

[ashes987]

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.

[ashes987]

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.

[ashes987]

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.

[ashes987]

@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%

[ashes987]

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.