JDMdev

  Logo by Nicolas Katsis And with that, Van Helsing is done! It is available to download here for anyone to play. But now it's time to sit back and reflect on the project and how it went. Overall, I think it went really well. 3 / 4 of us were really interested and invested into the project, each devoting a lot of time and commitment towards it. From talking with my teammates, we all share the same sentiment that we'd really have liked more time to continue building and fleshing out the game. We see a lot of potential in the concept.  From a technical point of view, there are definitely elements I would change or improve if we continued to develop this: - One of the bigger points would be in the zombies; Currently, upon spawn, all zombies move towards the player, which makes it rather easy for the player to jump over the amassed horde and then beeline it to the exit. If I had time, I'd have implemented a system wherein zombies that are not close to the player roam aimlessly...

Continuing on from the last log: The Ghost The purpose of the ghost is simple: to keep the player moving. Although not refined, there are elevated platforms the player can stand on in the level (i.e. the Statues and Lampposts) and one issue we identified quite early is that the player could take advantage of this to avoid the zombies indefinitely by remaining in one 'safe' spot until they had killed all the zombies. To rectify this, we created the idea of the ghost - an enemy that could reach the player on any y level and could not be killed. They have a delayed start to give the player some time to get moving and then, if not progressing quick enough, the ghost will eventually catch up to the player and nudge them along (or kill them if they fail to do so).     Creating the delay was simple. On level start, the ghost spawns just off-screen with the variable "begin" set to false. Inside the _process function, everything is behind an if statement waiting for begin to b...

  At the end of Part 1, we had a simplistic 2D platformer with a freely rotational gun arm that fired bullets. A good start, but there was more work to be done. Between me and the other programmer, we split the work in two. I was in charge of the foundational gameplay and mechanics, while he was in charge of the lighting, particle systems, sound effects and other fancy stuff that you throw on top. In this log and the next, I'll be covering the remainder of the functionality I added to the game, these being:  - Enemy damage - Player damage & Invincibility frames - Reloading - The ghost - Adding the animations created by our artist    Enemy Damage First of all: zombie damage. This was easy to add. Godot has this node called Area2D that reacts every time an object overlaps with the area that you can draw in the visual editor. This makes it really useful for multiple instances of collision detection. Every time an object enters the collision area, if the object is ca...

  (Bullet sprite by Nicolas Katsis) This part is solely on how I implemented the bullets shown in the video in Part 1. There are two parts to this split across two scripts. The first is its behaviour and the second is the spawning of the bullet. First of all, it's behaviour.   The first thing that occurs on spawn is that the bullet assigns itself to a group of objects known as "P_Bullet". You will notice in all the snippets of code that many of the variables and groups for this object are listed as "P_ something ". This is because we initially considered the idea of giving the player two different guns that they could swap between: A pistol with a higher ammo count and longer range but weaker damage, and a shotgun with a much higher damage but fewer bullets and shorter range. The P_ was a reference to 'Pistol' bullets and S_ was a reference to 'Shotgun' bullets. Unfortunately, due to time constraints, the Shotgun was never introduced. For those u...

  Game Jam #2 began on 13th October and lasted 3 weeks. The goal this time was "Shoot-em up" and the teams had been both expanded to average 4 per group and randomly assorted as opposed to being grouped based on those around you. My team consisted of the following: - Programmer (me) - Programmer - Artist - Designer  Off the bat, we were able to come up with a very solid idea for our game: A side-scrolling platformer where the player can shoot 360 degrees to kill zombies. The player can only see inside a small aura of light around them and must rely on lampposts and other light sources as well as directional audio cues to navigate the level. The other programmer, just like my last partner, had never used a game engine prior to this course. As such, we settled on using Godot for this project. The reason we chose Godot is because its proprietary scripting language, known as GDscript, is pythonic. This means it is eerily similar to python, but enhanced and integrated enough that ...

  The first ever game jam for the game development module of my course began on Friday 29th September. We were paired to those around us and given two weeks to develop a 'One-Button Hyper Casual Game'. Being the first, the rules were it should be kept simple and only use 1 input to interact. My partner was a fellow programmer*, however we did have a problem: Neither of us had ever used a Game engine. We both came directly from OCR A level Computer Science and as such had only ever learnt raw Python and the Pygame plugin, which, while impressive for its capabilities, is impractical for commercial game development. Using the AppsAnywhere service from the University, we initially settled on GameMaker (an older 2019 version as that is what was available) to make our game. Our concept was an autorunner, similar to that of the Chrome offline dinosaur game , using a flying bug as the player character and being able to jump when space was pressed and dive low when space was held. Enem...