Jump to content
  • Advertisement
  • entries
  • comments
  • views

Entries in this blog


Week of Awesome V: Post-Mortem

Greetings and salutations!   The competition is over, and the results are in. I came in thirteenth out of twenty--not a result that I'm happy with.   So, what went right, and what went wrong?   What went right: - Panda3D Once again, I'm overall rather happy with my engine of choice. There were a few difficulties to deal with, but I think that it served me well in this. - Vertex colours: By simply painting the vertices of my enemies, I was able to roughly colourise them without creating individualised texture-maps. The resulting appearance is a little basic, perhaps, but I feel that it was appropriately expedient! However, see below under "what went wrong"...  - Music: This is a field in which I've previously had pretty poor scores, as I recall. For this year's Week of Awesome, I set aside my old source for royalty-free music, instead turning to Kevin MacLeod's Incompetech. It's a well-used source, but I found music there that I feel fit my game rather well, and the scores given (sevens and eights out of ten) seem to support this.   What went wrong:   - Scope: Simply put, the game is perhaps just a little too big for the time allotted. Had I had another two days to work on it, I suspect that my entry would have been much better. Aside from various bugs, the level was rushed--I think that I only spent somewhere around five or six hours on it in total. Indeed, I recall that right at the start I had reservations about the scope of this project--but at the time I had no other concepts that I was sufficiently happy with and that fitted the themes well. My thinking at the moment is that, for future jams, I should perhaps look for a concept that I feel that I can complete in five days; if I find myself with only a concept that seems too big (as was the case this year), I should perhaps nevertheless set it aside and keep looking.  - Vertex colours: Unfortunately, I managed to miss a caveat in the version of Panda3D that I was using: Simply put, when a shader that uses vertex colours is applied to a model that lacks them, the result is undefined. On some machines--including the two on which I tested--the result is white; as I was using the colours, this more or less amounted to "no change", and thus looked fine, I believe. On other machines, as it turns out, the result is black. Since the majority of the level has no vertex colours, this meant that all looked well on my end, but for some of the judges the environment (and the player's on-screen hand) turned pitch-black, rendering navigation somewhat problematic.  - Projectile appearance: I fear that I spent a little too much time attempting to get my projectiles to fit the look that I had in mind for them. It might be wiser in general for me to think of the game as a prototype, and not spend quite so much time on such elements of polish unless there's time to spare at the end. (Although I do feel that the scoring category for graphics provides incentive in the other direction...)   That's all for now, I think--stay well, and thank you for reading!




Week of Awesome V: Day 6: The Tower of Chains

Greetings and salutations! This is, for me, the final day of the jam; thus, what I've completed today is intended to be my final submission... First, once again, a screenshot showing some of that final submission: So, what does that submission include? First of all, I'm not terribly happy with what I achieved this year. While I like at least some of it, and rather like the concept, what I managed to do by the end didn't match up to what I'd hoped to make. In particular, the level is brief, has no true end, and isn't terribly interesting to look at, while the gameplay wants for some serious tuning. Still, I do rather like the "chain" mechanic; having the various chunks of the level rearrange under the influence of the chains is something that I find neat, and interesting. As for what, precisely, I got done today, let's see--off the top of my head:
 - A custom cursor for the menus
 - Player death, a new popup menu that appears on death, and the option to restart the game should one die
 - Cheat codes ("i" toggles invincibility, while "m" gives the player the two collectible weapons)
 - An on-screen player-character hand (begun yesterday, as I recall)
 - Adjustments to the player-spell casting effects
 - Sound effects
 - A quick-and-dirty level
 - Various tweaks and bug-fixes (I may well be forgetting something.) So that's it! Whether my entry is judged good or not, I very much enjoyed the jam--it's a little gruelling, as I run it, but thoroughly enjoyable. That's all for today--stay well, and thank you for reading!




Week of Awesome V: Day 5: A Little Magic

Greetings and salutations! Today was pretty productive, I do feel! Once again, I didn't get done quite as much as I might have liked, but nevertheless feel that I got a fair bit done. First of all, a screenshot, showing the main menu (and the title that I've selected for the game): So, what was done today? The UI has been completed, I believe (with the exception of a custom cursor, which I think that I forgot about). It's fairly simplistic, and one or two bits are a little rough (the key-binding UI could use a re-skin, in particular), but it all works and for the most part looks acceptable, to my eye. This includes some work on the in-game UI; for example, spell-icons are now visible and highlight to indicate the currently-selected spell, and flashes occur at the edges of the screen when the player is hurt or healed. Connected to and part of the work on the UI is that I've implemented pausing of the gameplay, with the option being given to either resume play or quit the game. As to the gameplay, I think that I finally have an effect for my spell-bolts that I'm sufficiently happy with. As I believe that I mentioned, I had hoped to try something fancy, creating a solidly-glowing effect--and indeed, another entrant gave me a suggestion for a potential approach. However, I didn't manage to succeed to my satisfaction. So I fell back on a venerable method: three orthogonal quads, double-sided, textured to look like bolts of magic, and rendered additively. It's not what I had in mind, but it looks decent, I find! In addition to this, I've added impact-effects for the two spells that were previously sharing the effect intended for the first weapon. Speaking of those spells, one of them has been changed: The spell in question is one that the player can charge to a certain degree. Previously, this affected the resulting bolt's speed and damage. However, I realised that the latter left it too similar to the other spell that could be acquired--and which I think is a bit more interesting. So, while the effect on speed remains (if I recall correctly), instead of dealing more damage, the spell now deals its damage in a spherical area-of-effect, with the radius of that area being determined by the charge given. And once again, there are likely sundry changes that don't seem worth mentioning here! That then is all for today--stay well, and thank you for reading!




Week of Awesome V: Day 4: Strange Crystals

Greetings and salutations! Today was fairly productive, I feel! To start with, some screenshots showing the current state of the game:     The three powerups thus far implemented--from left to right, I believe: A "spread-fire" weapon, health, and a "charging blast" weapon.       Some of the current state of the game--note the three enemies, the health bar, and the new texture on the level-geometry.   As to specifics, read on: You may recall that I mentioned in my previous entry that the flying enemy might be scrapped; well, it's working now! It doesn't behave as I had originally intended, but I'm happy with its new (preliminary) behaviour, I do believe. Speaking of enemies, they now react visibly to taking damage: they "flinch" a little to one side or the other, may be pushed back by some weapons, and release a quick burst of particles. Weapons have seen a little work: I have a basic implementation of one weapon's appearance, and an impact-flash for the same. I had hoped to produce something fancier that I have now--I wanted a 3D model that shaded from bright at its visual centre to darker at the edges, giving a nice, glowy look. I attempted to implement this by looking at the model's normals in the relevant shader, with normals pointing towards the viewer being bright and normals pointing tangential to it being dark. This sort of worked, but not to my satisfaction. I also started in on menu-screens today: there is now an incomplete main menu, a possibly-sort-of-complete options menu, and a probably-near-complete credit-text screen. On a similar note, I selected fonts to use in my UI, including the above-mentioned menus. This took a little searching, especially as I wanted to avoid licences that might be problematic. In the end I found two that I'm reasonably happy with, at least! I've even made a first step on the in-game UI: as shown above, there's now a simple health bar near the bottom of the screen, which decreases when the player's health drops, and increases when it rises. Powerups have also been implemented: small red orbs replenish the player's health, while oddly-shaped crystals provide new weapons. And once again, the game saw various tweaks, changes, and additions that don't seem worth mentioning here! That then is all for today--stay well, and thank you for reading!




Week of Awesome V: Day 3: Links of Iron

Greetings and salutations! Today was a fairly productive day, I think--although I'm starting to feel a little behind my preferred schedule. The end of the week is creeping closer... As to a screenshot, have a GIF showing the new chains in action (albeit with some cuts; the process is rather longer in-game): (Sorry that it's in Tweet form--for some reason my attempts to upload the GIF as an attachment repeatedly failed.) Perhaps the biggest change made today is the one shown above: the chain mechanic has been implemented! Chunks of level can now be joined by great chains. When these are shot, they disintegrate, sending the chunks flying apart. However, after a short time the chains reach out again, joining the chunks and drawing them back together. Thus far, this all seems to work reasonably well, I think. I also switched from using Panda3D's auto-generated shaders to my own. These new shaders are stripped down and heavily-modified copies of one of the main shaders from my primary game-development project (A Door to the Mists), with one variant for the chains (which implements their disintegration and link-by-link extension) and one for projectiles (which may well be changed in the future). On the downside, I accidentally saved over the working file for one of my enemies; while I do have last night's backup, some changes were made today. That said, I do still have the exported version, so as long as that holds this may not be an issue. And even if it is, the changes made today weren't huge, from what I recall. Speaking of enemies, a new one was implemented today--although, alas, I may well end up scrapping it. It's a flying creature, intended to harry the player from the air, unbound by the edges of the level-chunks. However, it's not behaving as well as I'd like, and I'm having some trouble getting it to quite work correctly. We'll see how things go, perhaps. Finally, there were sundry other changes that don't seem worth mentioning in full. That's all for today--stay well, and thank you for reading!




Week of Awesome V: Day 2: Strange Creatures

Greetings and salutations! Day two of the fifth Week of Awesome has concluded for me! It's been a fairly productive day for me, I think--although I'll confess that I didn't manage to finish quite everything that I had wanted to. First, however, a screenshot showing some of the game's current state:
Not terribly pretty just yet, but early days (I hope). You can see some of my little prototype level, and the two enemies thus far implemented--the further, taller enemy shoots at range, while the smaller, spidery fellow attacks in melee. So, what did I get done today? First of all, as shown above, I have some enemies now! In addition, I have some simple weapons implemented, and the player can select between available weapons and kill the enemies with them. No GUI has yet been implemented to display what weapons are available, or which is selected, however. The enemies can fight back, and do damage--but this currently has no effect beyond lowering a number and printing to the console the damage dealt. Alas, in taking the screenshot above I discovered that the "spider" seems to have become broken at some point, no longer attacking. Something to look into, I fear. Speaking of damage, I've implemented simple falling damage: if a creature (I think that I implemented this for both player and enemies) lands after building up too much speed, they should now die. (Or harmlessly take damage equal to their health, in the case of the currently-invulnerable player.) I've also implemented in-level music, employing some royalty-free pieces by Kevin MacLeod via his site http://incompetech.com. The game should randomly pick from the four pieces that I've downloaded, and once that piece has finished, pick another. I've selected and loaded menu music from the same source, but don't yet have a menu over which to play it. I think that that's everything for today--stay well, and thank you for reading!




Week of Awesome V: Day 1: Chains and Invaders

Greetings and salutations! Once again, the "Week of Awesome" has come around, and once again I mean to enter! The themes for this year are, I believe: "Chain Reaction", "Assassination", "Castles", and "Alien Invasion". I'll confess that these themes gave me some trouble: it took me some time to find a concept that I was quite happy with--and even then, I'm not quite sure of the one that I've picked. Of the four, I wasn't inclined to "Assassination". "Castles" I like, but setting the game in a castle felt a little obvious--something that I prefer to avoid. As to "Chain Reaction", the direct interpretation--gameplay involving one thing setting off another in rapid succession, as with explosive barrels placed beside each other--simply didn't interest me much. I did fairly early come up with an approach to "Alien Invasion" that I rather liked: this needn't be a sci-fi concept. There's no reason that the aliens couldn't be from another dimension, or another celestial sphere, or even simply another world. And indeed, I intend to use this theme, under that the interpretation. What then to use with it? Another thought that I had fairly early on was to reinterpret "Chain Reaction" not as a set of reactions, one prompting another, thus forming a "chain", but rather as reactions to or from chains. I toyed with a number of ideas here--ghosts in chains, swinging from chains, playing as a chain swinging itself around, and so on--but struggled to find something that both sufficiently met my liking and seemed like a good interpretation of the theme. What I settled on in the end is this: The game-world is composed primarily of chunks joined by great chains. The player's weapons-fire can break these chains, sending the chunks flying apart, until at last they stop. After a brief pause, the chains reappear, and the chunks pull together again. Thus the chunks react to the presence or absence of the chains. This way I intend to make an exploratory first-person-shooter: the player navigates from chunk to chunk, trying to find the way towards the top of a sort of "tower", where the game's goal (and final boss ;)) lies. Along the way they face enemies in old-fashioned shooter gameplay: quick movement, slow bolts of magic, etc. I also want there to be rewards for exploration: it's how additional weapons are found, as well as the traditional health powerups. I'm a little nervous about how the judges will feel about this interpretation of the "Chain Reaction" theme. We'll see, however! As to progress, I believe that I have the bare basics done: movement, an initial pass at weapons-fire, and some prototype geometry. I don't yet have chunk-movement in, or the chains, or enemies. Still, for the first day's work, I'm fairly happy with it! That's all for today--stay well, and thank you for reading!




WoAIII: Powerthief

It's done! The (intended) submission version of my entry, Powerthief, is complete, and should be available via the link below:

[s]Powerthief (v1)[/s]

A new version, with working sound:
Powerthief (v1.1)

I pulled and all-nighter in order to get it done (finishing at some point after nine a.m., by my time), and am thus feeling a little out of it, so I'll leave this journal entry after a quick listing of major changes to the game. However, a more detailed post-mortem entry will likely follow, perhaps in a few days' time.

Major changes:
New models for the player and enemies, with animations
Alas, my animation logic seems to be faulty, as the walking animations seem to end up jittering horribly. It's worth leaving in for the sake of the "flinching" animations, which do (more or less) work, I think.

Some new special effects
Some of these are repurposings of previous effects, but there are a few new items, such as the lightning ball and firebird.

Sounds and Music
The music comes courtesy of Eric Matyas, while the sound effects largely come courtesy of me making noises into a microphone, then messing with the results a little in Audacity.

A very simple "intro" screen.

A number of "placeholder" models remain in place, I'm afraid--the powerups in particular still use the models that they had in the prototypes.




WoAIII: Death and the Boss Monster

Day 5 draws to a close. The deadline is near (more so because I don't intend on working on Sunday, a possible all-nighter notwithstanding).

I have a new prototype: Powerthief v0.2

(I won't post a new screenshot today because the game is visually much the same as it was yesterday--the changes are primarily in gameplay.)

I feel that I got a fair bit done today--amongst other things, I made the following changes:
The "death" mechanic is now in!
When the player dies, the spell which served them best should now be given to the enemy that did the least damage during the run
These changes should also persist between play-sessions

The main boss has been implemented!
Two new spells are available: Lightning Ball and Spark Spray
A simple "you win" screen has been added
Health powerups now sometimes appear on completing a room
A weapon powerup should now appear on completing a level
A new enemy type has been introduced
The movement of one of the pre-existing enemy types has been made a little more complex
Some basic tutorial imagery has been added to the first room
Enemies should no longer spawn near the player
There was a bug that caused the "game over" screen to cover the play-area when starting a new game, preventing play; this should now be fixed.

I attempted to implement a simple options menu--only to discover that my previously-functional key-mapping GUI broke at some stage in the past, and that furthermore my splash screen's code was interfering with it! Attempting to fix the problem was taking up too much time, so I decided to dump that feature, for now, at least.

In the new day I intend to create a few models with a handful of animations, create some basic sounds, find a few music tracks, and keep polishing the game. I'd like to add basic special effects, some new spells, some level-geometry, a simple intro and perhaps a better outro, and maybe the mid-boss and a new enemy-type or two.

I'll confess that I'm not entirely happy with the way that this game is turning out--the gameplay feels a little messy, a little cluttered. And yet, I've actually had some fun play-testing it, so I'm not entirely unhappy, either.

The schedule is looking tight, and I'm not sure that this game is coming out as well as I would like, but I'm not entirely unoptimistic: even if I don't complete all of the above, I may yet produce something that I can feel at least somewhat happy with.




WoAIII: Prototype!

It's... It's day 3, right? Right...?


At long last I have a prototype available! The art is placeholder (although some might end up in the final product due to time constraints), the gameplay is likely rather unbalanced, the enemies are simple, there's little feedback on hits, the thematic element isn't yet there, there is neither sound nor music, and there are bugs--but you can now at least try it for yourself!

You should be able to download the prototype via the link below:

(I'm not hugely happy with the name, and may change it in future versions.)

Feedback would be appreciated, I do believe!

[indent=1]Movement: WASD
[indent=1]Aiming: Mouse
[indent=1]Casting: Left mouse-button
[indent=1]Spell-selection: numbers 1 through 4, or scroll the mouse-wheel up and down.
[indent=1]Return to menu, or from menu to game: Escape
To entice at least a little, have a new screenshot (cropped to show just the interesting bits):

A quick summary then of the major changes that I've implemented (as far as I recall): The game now has four spells available, and two types of enemy; both the enemies and the player can be killed. When the player is killed, a game-over screen appears, and after a short delay the player is free to return to the main menu. Objects all have a simple blob -shadow or -"light".

I'm tempted to take an idea mentioned in one of DifferentName's journal entries, giving the basic enemies movement patterns that are more complex than their current "charge!" approach.

There are some known bugs, I'm afraid:
Enemies occasionally spin wildly around the player.
When the frame-rate drops too low, something occasionally goes wrong with the movement code, and things seem to lurch a bit.
Enemies can spawn very near to the player.

The following, then, is my list of remaining major goals for this project (in rough descending order of importance--if nt implementation):
Implement death-related changes
Saving of the various pieces of data such that the death-related changes persist between plays
More enemy types
More spells
Sounds and music
Some basic special effects (explosions and the like)
A very simple options menu (allowing for key-rebinding and volume control)
The main boss
The mid-boss, with some means of altering it to reflect a player-death
Interior walls and pits, the latter being a hazard for the player.
Proper level geometry, including outer walls, inner walls, and pits

So, plenty to keep me busy over the next two days!




WoAIII: Spells and Doorways

Day three has ended, and I'm running late--more than a day beyond my schedule, by my reckoning. It's a good thing that I have those two buffer days at the end of the week! (I hope that it's enough...)

Late or not, I'm not entirely unhappy with the way that my game is shaping up. I made progress on several fronts:
Basic level- and room- progression has been implemented, including the basics of a simple "tutorial level" that provides the player's first spell.
There is, admittedly, a bug in the door-placement; I think that I may know what the problem is, however.

Collectibles offer a selection of three randomly-selected weapons, from which the player may pick one.
Weapons now have their base functionality (although they don't yet do damage), and an on-screen GUI shows the player's collection of spells and the mana available to each.
Two simple weapons have been created: a rapid-fire spell and a spread-fire spell.
The player character now rotates to point towards the mouse cursor, which is used for aiming

The following screenshot shows most of the above:

[indent=1](The player is casting a rapid-fire spell; note that the second spell is the one in use, and that the first is still recovering mana after heavy use. The door near the top-left provides passage to the next room, or the next level in the case of the final room in the level.)

There are still no enemies; that I hope to rectify in the new day, along with more and more-complex weapons, and perhaps a better algorithm for picking weapons to present to the player (simple randomness produces too many duplicates, I feel).

If I'm not much mistaken, and if nothing intervenes, I should be able to release a simple prototype early (as I account things) in the new day.




WoAIII: Your Power is Mine!

I'm rather tired as I write this, so my apologies if it's a little short, or a little fuzzy!

However, I finally settled on a concept!

My game--which is as yet untitled--is intended to be a near-top-down procedural shooter with perma-death. Each level is divided into a series of rooms, in which the player is tasked with killing all enemies before being allowed to move on. (I suppose that this technically qualifies for "death being useful, but that's not what I have in mind--read on...)

Turning to the theme, it occurred to me that the theme states that "death is useful"--but it doesn't say to whom death is useful. In this game, the player's death is intended to be useful to the enemy. Specifically, when the player dies, their most successful (or perhaps most used) spells are distributed amongst the various enemy types--that wonderful fire spell that you so enjoyed using to fry monsters might be turned on you in the next run! Furthermore, if the player dies far enough into the game on a given run, the mid-game boss is replaced by one based on the player. Finally, enemies that perform poorly against the player will likely be given a lower weighting during level generation, and perhaps those that do well will be given a higher weighting.

I may also add some small bonus for the player on reaching their body (placed at an appropriate point in the next run's levels)--perhaps some sort of boost or powerup.

The game is intended to be short and linear: at the moment I intend four levels of four- to seven- rooms each, with a final boss at the end and a lesser boss at the mid-game point.

As to my progress, I'm a little behind, I'm afraid. I'd hoped to have a prototype out before bed, but it's late and I'm exhausted--it will wait for the new day, I fear. I've thus far implemented basic movement, the beginnings of spell collectibles, and some basic level generation, all using place-holder models (although I might keep the floor texture). Take a look:

[indent=1](The little T-form fellow near the centre is my place-holder character, the large red-based object near the top-left is a place-holder spell collectible, and the tubes are walls.)

Here, then, is my list of intended goals (presuming that I'm forgetting none):
Four or five types of enemy, each with their own patterns of behaviour--some might charge in, others might hug the walls, still others might leap about, and so on.
Lots of spells!
A mechanic that allows the player to select from three randomly-selected spells on collecting a spell powerup
Player death, the distribution of their spells
Progression through the rooms of each level, and from one level to the next.
The main boss
The mid-boss, with some means of altering it to reflect a player-death
Saving of the various pieces of data such that the death-related changes persist between plays
Interior walls and pits, the latter being a hazard for the player.
Proper level geometry, including outer walls, inner walls, and pits

And finally, a list of "nice-to-haves", in rough descending order of preference:
Side-quests: short excursions from the central path, perhaps providing powerups at the risk of death.
Alternative texture-sets for the levels, in order to reduce the monotony.
More enemies!
More levels
Perhaps procedurally-generated spells




WoAIII: The Dilemma

Two points do not a pattern make, but both this theme and last year's have proven difficult for me!

For the past few hours I've been struggling to find an idea that satisfied me. I've had ideas--I posted some of them in my previous journal, I believe--but I've found problems with all: some didn't seem to use the theme well enough, others seemed to require grinding, a few just seemed insipid, and so on.

However, I think that I now have two concepts that might work, and have only to decide between them before I start developing a prototype:

First is a design mentioned in my previous post: the player controls a set of cultists attempting to perform a ritual sacrifice at several particular locations, while avoiding heroes intent on stopping them. At its heart this would be a stealth game: the player attempts to reach the ritual site without being spotted by either civilians (who might raise a "suspicion" meter) or guards and heroes (who would kill the character, and who are alerted once the suspicion meter becomes full). Death would be useful in two manners: first, performing the sacrifices advances the game, and second, being killed by a hero "outs" that hero, making them visible from the outset of subsequent attempts.

I really like this idea, but I'll confess that I have qualms about making a game in which one plays a set of villain-protagonists of this sort. To some degree this might be ameliorated by making the sacrifices be ritual suicide, removing the element of murdering others, and by the fact that I would intend to portray the outcome of completing the game as something very unpleasant: "winning" would produce a screen that depicts the horrible arrival of the being summoned by the ritual, while losing would announce that the world is safe from the player.

My second idea is something new. The theme is that "death is useful"--but it doesn't say to whom death is useful; in this concept, player-deaths are useful to the enemy. Specifically, this game would be a procedural shooter with perma-death. When the player dies, their most-successful (or most-used, perhaps) weapons are distributed amongst the enemies, and a boss based on the player. (This is likely to be somewhat weighted according to the player's success in the run: a player that did poorly might end up "donating" only one or two weapons, and might not be made a boss.) Furthermore, enemies that performed poorly against the player receive a lower weight during the generation of the next run.

Again, I rather like this idea. On the other hand, my submission last year was a procedurally-generated game, and that took long enough, and was judged poorly enough, that I'm hesitant to follow so similar a route this year. On top of that, there's a danger in using an idea that just recently came to me: I've found in the past (including last year's submission) that it can take time for me to spot the problems with a concept; I recall that this was, after all, part of the reason that I wanted to dedicate a day to concept-work.




WoAIII: Contemplating Concepts

So, the contest has begun, and the theme revealed: "Death is Useful".

An interesting theme, if not an easy one, I'm finding. Funnily enough, I believe that I saw a theme rather similar to it in a game-development challenge on another forum, years ago. (While I think that I recall the concept that I had for that, I naturally don't intend to use it here.)

I've had a number of ideas thus far; the following are those that have caught my interest:

One idea was to make the player's death a doorway leading to other worlds, and perhaps new incarnations. However, I was troubled by the thought of depicting death in this way: I don't want to depict suicide as something desirable. Further thought suggested that this might be ameliorated by making it advantageous to stay in a given level for as long as may be (perhaps amassing score, items, or character levels), but with death leading on to the next level--the player is thus encouraged to survive, but when death comes it is nevertheless a form of progression, not defeat. I quite like this idea, although it leaves the actual core gameplay somewhat unspecified, which both implies more design work and suggests that death's utility may not be sufficiently central.

Another thought was that the theme doesn't specify that it is the player's death that is useful, only that death be useful. Thus perhaps the player might have access to necromancy or blood magic, allowing them to raise dead enemies or gain power through killing; this might have the additional challenge or requiring that the player perform these actions in specific places. However, another contestant has subsequently settled on something rather similar, and (I feel) rather clever.

Building on that, though, was something somewhat darker: a stealth-based game in which the player takes the role of a cultist--or rather, a series of cultists--attempting to complete a human blood sacrifice in order to summon something horrific. These sacrifices would involve killing someone at each of a series of specific locations--perhaps randomly generated. Further, the good guys know about the sacrifice, and are watching for our cultists, knowing them by sight; if they spot a cultist, they will attack and likely kill him or her. On the other hand, the cultists don't know the good guys, nor where they hide--unless they expose themselves to slay a cultist. There are only so many members in the cult, and losing all of them loses the game. Thus death is useful in two ways: performing the sacrifices advances the game, and dying exposes the good guys involved in that death, allowing the player to more easily spot them the next time.

(I'm currently somewhat leaning towards this idea.)

Last on this list (thus far), I had the idea of some sort of roguelike in which not only is there meta-progression (such as unlocking of items, statistical increases, or mechanical advantages), but the player's corpse appears at an appropriate point in the next run and provides some sort of advantage, allowing the player to press on more effectively once found (perhaps via providing access to an alternate world in which powerups are available, or which lead to the next part of the game). Additionally, the corpses of certain enemies might provide similar advantages. completing the game without a death might be impossible, calling for the player to make at least one brave, doomed run. I somewhat like this idea, but I'm not sure that the roguelike genre is one that I'm well-suited to.

At the least I intend to sleep on these ideas, and may indeed come up with others. Only tomorrow do I intend to select one and build a prototype.

On the technical side, I used some of this time to put together the bare framework in which the game is intended to sit. This largely amounts to a copy of core- and likely-looking- parts from my current main project, placed into a new folder and gutted of most game-specific elements. The new folder was further populated with appropriate empty sub-folders (such as "Music" and "Sound" folders). I also implemented a simple splash-screen class and used that to add the required splash to my game; it could further be used to create additional splashes, and perhaps sub-classed to produce basic cutscenes. There's no gameplay code thus far, but the project runs: it first shows the splash screen, then, after a key-press or mouse-click, fades to a bare-bones main menu with a "new game" button (which does nothing), a "credits" button (which does work, but at the moment shows the credits from my main project), and a "quit" button (which works just as expected! ).




The Week of Awesome III: A Prenatal

So, the competition draws nigh, less than two weeks hence! As suggested in the discussion thread, here are my thoughts, plans and feelings ahead of it...

Given that we're not to start coding until the official start of the competition, that the theme is being released only on the same day, and that I'm using a set of tools that I'm already familiar with, there's little preparation to be done, I feel.

That said, I intend to use a slightly older--and more saliently, a slightly more reliable--version of the Panda engine than I generally do. Between that and the fact that it's been a little while since last I built a distributable version, let alone in the older version of the engine, I wanted to perform a quick test. I happened to already have a small test-program, so I simply built that, installed it, and tried it. Thankfully there was only two hiccups, neither a serious issue:
First, I found that I hadn't reinstalled the NSIS installer generator after a recent OS upgrade that seemed to result in the OS losing track of which programs I had installed. Reinstalling it solved the problem.
Second, while the Windows build worked just as expected, the Linux version failed. This, however, isn't a major issue--I'm in any case a little hesitant to support two platforms under so tight a deadline, so I'm comfortable with just dropping the Linux version.

Here's the result:
(It's not apparent in the following screenshot, but the text switches between various colours, which can be toggled with the space-bar.)

[indent=1]I... I like cats. C-can you tell?

I've also given some thought to how I'll implement the splash screen; I'm glad to say that, using my menu framework, this should be quick and easy.

As with last year, I intend to start with my "template" project, and I'll likely make use components that I've made previously, whether separate and intended for such use, or torn raggedly from their native projects.

I've given some thought to how I want to approach the competition. None of the following is set in stone, however; it's a guideline for myself, an aid to planning. I don't plan on working on day seven (although it's quite possible that I'll end up pushing that a little by working through the night of day six), so my list runs up to day six.

Day 1: Conceptualisation.
[indent=1]My experience leads me to feel that I tend to benefit from taking time with design decisions. Naturally, the rather tight schedule of this competition doesn't leave much space for that, but I nevertheless want to avoid being hasty with my choice of game. If I find myself either having only one concept, or very confident of my choice of concept, I might decide to take only half a day for this step.

Day 2: Prototyping

[indent=1]I feel that one of my mistakes last year was not getting a prototype out for people to play. This year I hope to rectify that by completing a prototype by the end of the second day. It will (most likely) have models/sprites/whatever thrown in from those that I have lying around, and neither sound nor music, but it should at least allow me to test the mechanics of my game.

While the following days have other tasks as their identifying elements, they will likely all have at least some time--quite a bit of time, I imagine--dedicated to improving upon the prototype, especially based on feedback given.

Day 3: Graphics
[indent=1]Here I hope to finish at least a first pass at the graphics for the game.

Day 4: Sound and Music

[indent=1]The primary focus of this day is trawling through Sound Image for appropriate music, making sound effects from miscellaneous objects (my own mouth likely included), and implementing these into the game.

Days 5 and 6: Polish and Buffer
[indent=1]As the title suggests, these days are intended to be dedicated to completing and polishing my entry--and also to give me some space into which to expand, against the (very likely) possibility of the project taking longer than intended.

My main anxiety, I suppose, comes from learning the theme only on the day. While I realise that not doing so would likely incur all too high a probability of cheating, I do generally prefer to have some time to think about a game before I actually start working on it. Nevertheless, I take it as part of the challenge!

I've spent some time "practising": taking themes that don't on their surface appeal to me, and turning them into projects that I might enjoy making. My favourite thus far was for the hypothetical theme of "combos". I don't like traditional combos--by which I mean abilities that are activated by some often-arbitrary collection of actions in real-time, as in fighting games. I find them generally unintuitive, and rather un-fun. So, if the theme were "combos", what might I make? In short, what I came up with was a turn-based single-character tactics game in which (known) sequences of single-turn actions produce powerful "combo" abilities. Since the game is turn-based, one doesn't have to remember the arbitrary sequence in the heat of action, and the combos are intended to be attractive due to sheer power and utility. On the other hand, one can only perform a single action per turn, meaning that the player may find themselves with decisions involving whether to go for a combo, or cancel it to deal with an imminent threat--is it better to tank some damage in order to use the combo, or avoid the damage but lose the opportunity?

The other issue that I have in mind is one that I often face in short competitions like this: I like at least a degree of complexity in my projects, but the constraints of a competition like this call for very simple gameplay. The trick for me is to find a concept that's sufficiently simple that I'm likely to complete it in time, but nevertheless sufficiently interesting to me that it sustains my enthusiasm.

But all of that aside, I'm looking forward to the competition: It's a change of pace, a fun contest and challenge, and an opportunity to see what interesting creations my fellow competitors come up with!




Darkholm: An Exhumation

(Why an "exhumation"? Well, a post-mortem has already been done: this is me digging up the corpse to re-examine it in light of new evidence.)

So, what went so wrong? Having read the reports given by the judges, here are my thoughts on the worst of the game's issues:

Combat was never intended to be the player's primary approach in this game. I intended it to be a survival horror experience; I wanted players to be scared of the toys, and to avoid them rather than engaging. (Indeed, the more toys one breaks, the worse the ending one gets if one reaches the end of the game!) I wanted to create a "weak" horror protagonist, not a monster-slayer.

With this in mind, I fear that I sent mixed messages--or simply the wrong message entirely--with regards to combat. I made combat slow and dangerous (overly so, I gather)--but nevertheless provided a weapon at the very start of the game.

Looking back, perhaps it would have been better to have left out the combat entirely and instead provided some other item for slot one.

Toys are small (for the most part). Given this, it was perhaps a poor idea to choose a perspective that makes everything smaller still! The result seems to have been that the judges had a difficult time interpreting the enemies as the toys that they were intended to be: the headless doll--the first enemy encountered--seems to have been consistently misread as a headless baby or ghost, and at least one judge didn't recognise the wooden crocodile at all (and thus gave me a zero in the "theme" category, having not identified any toys in the game)!

(With regards to the doll, I had hoped that its lack of feet and inhuman movement would be enough to convey that it was intended as a doll, but in retrospect I wonder whether those traits might not have been a little subtle to be noticed at that scale in the middle of gameplay.)

This might have been solved by either choosing a different perspective (such as first-person, while would also have saved me creating a model for the protagonist), or by choosing toys that were more easily recognisable.

Overall and in conclusion
I think that one of my main failings in this competition is that I never released a prototype during the week: at least some of the game's issues--especially the problem of combat--might have been ironed out if I'd known about them during development.

In addition to that, I think that the project may have been just a little too large for the time-frame, given that I was working alone (albeit with music from an outside source)--something that I keep bumping into in short competitions like this. A number of the points that were criticised--in particular the very limited number of items, poor enemy placement, repetitive rooms, and lack of variety in "props" (the tables)--were the result of cutting corners (and features!) due to time constraints.

I still think that the concept was a good one: with a few more days and some prototype feedback, I think that I could have made a decent horror experience of it.

That said, I do now wonder whether I might not have been better off going with the other horror idea that I had--a first-person exploration game taking some gameplay cues from P.T. (specifically in having the player's gaze be a form of interaction). It would likely have called for a larger initial investment of time in modelling a small house (of a few rooms only), but the gameplay may have been simpler, and the first-person perspective might have made the toys more recognisable...




The past lingers.

A post-mortem for Darkholm, as best I recall.

Only one week in which to make a game. Not much time at all: a short dash, top speed all the way, exhausting and exciting. It can be a competition concept at once intriguing, enthusing and intimidating.

Things started on a somewhat mixed note. On the surface, the topic didn't much interest me: as much as I enjoy the aesthetics of the cuter entries produced by others, it wasn't a style that I particularly wanted to make. However, I have some experience in twisting topics to my liking, and had already had it in mind to do so--and thankfully arrived in short order at the thought of creating a horror experience.

One of my first thoughts was a first-person house-exploration, taking some inspiration from P.T., but the issue of content creation--in particular the thought of creating a house of any useful size--put me off.

The other idea that I had was to create a rogue-lite--a genre with which I had been toying in concept at the time. The main question was one of gameplay: my previous conceptions of a rogue-lite had focussed on the standard action-centric fare of the genre, but action makes for poor horror in many cases--after all, the power to destroy the objects of one's fears can greatly weaken those fears.

But I worked on it a little more, and realised that I could build such a game around the idea of escaping rather than combatting; that combat could be a last-resort, or the province of particularly skilled players. (And I might note that players who take that route might find a nasty surprise waiting for them in the final version of the game... ;P)

I started to make notes, jotting down possible enemy toys (one of my first, and still my favourite, both in concept and execution, was the crocodile toy), room types, potential props, and collectable items.

Once I had enough that I was confident that the concept was sound, I set to work: I sat down with my template code and started building.

Through the days the game changed, primarily in features dropped:
I originally planned to have "administrator"/"staff" rooms, in which the items were found, perhaps bought from the spirits of the long-dead administrators of the orphanage; this was pared down to an empty dorm-room (another room-type that I'd hoped to have anyway) in which a single object appeared, chosen at random.
One of my earliest ideas involved rooms that were pitch-black, or nearly so, perhaps lit intermittently by windows, possibly by lightning-flashes, and players would be able to collect candle-stubs with which to light a single room per stub; this fell away, in part because I decided that it meshed very poorly with the idea of avoiding the mobile toys.
I had hoped to have a variety of items available, but the list was reduced to a bare four.
I had several enemy concepts; only three made it into the final game, simply by virtue of not having time to implement more.
The levels were originally intended to be more varied, and more interactive: offhand, I recall mirrors that showed glimpses of shadowy figures, and simply more types of prop than the tables that made it in.
Various concessions were made in terms of art--for example, the very first room is intended to represent the orphanage grounds just outside the main entrance, and, unlike the current, rather hacky implementation of that, was originally to have a custom building-facade and door, fences to either side, and a more detailed depiction of the ground.

Yet even with all of those elements dropped, I like the game that I created: it's not as I'd hoped that it would be, but I think that it's at least somewhat fun and has some aesthetic quality. While there are several elements that I'm not happy with, there are others that I rather like.

At last my deadline loomed. Final changes were made (the options menu, although long-intended, was added only late, and the options to alter the game's resolution and switch to and from fullscreen only barely squeezed in). I made builds, and prepared to submit my entry.

The actual building of distributable versions went fairly easily: having used it before, I have a process in place for building with Panda, and I was fairly comfortable with building so late. What kept tripping me up was forgotten things: in particular realising that an innocuous-seeming change was causing the game to crash, and discovering that I had dummied out two of the three levels.

(The latter I discovered when going back to take some screenshots. If I hadn't done that, I might have submitted the game as it was...)

To conclude, a few thoughts:
I'm particularly happy with the room generation--I still enjoy seeing the odd twists and passages that it produces, and I'm rather happy with the code that prevents the formation of unreachable islands (even if it does fail sometimes, prompting a complete re-generation of the room ^^; ).
My favourite enemy, both mechanically and aesthetically, is one of the first that I came up with: the crocodile; I rather like the effect of is tail following after it, and especially like its AI and movement.
It's a pity to have compromised on certain elements, but under time pressure expedience may demand it.
The competition makes at the least for a decent object lesson in just how short six days is in which to make a game.

So, what's next?

Over the next few days I might work (at a rather less arduous pace than in the competition!) on a "version 2" of my game: more room types, more enemies, more interactivity, more polish and re-worked gameplay. I don't intend to build from scratch--for one thing I'm actually fairly happy with my entry, and think it to be a fairly good base from which to start.

But first, I think, a rest...




Darkholm awaits.

And at last, it's done! It lacks both elements of polish and features that I'd hoped to include, and a few bugs and issues remain yet (the options menu is a bit of a mess, for one, and I left the frame-rate meter in) but it seems to work, and even has a (hacky) means to set resolution and toggle fullscreen.

Competition entry

The download link.
(Windows installer.)

Competition entry

There are three levels, and three enemy types to be encountered. There are five items to be discovered (a hint: aside from the easiest to gain, all are found in a particular room that is somewhat different to the others). There are also three endings to be seen, and four in-game deaths to be heard.


(I'm aware that the deadline is Sunday night, not Saturday (I'd be past the deadline if it were Saturday, I believe), but I don't intend to work on Sunday, and so for me the deadline is (somewhat flexibly--it's morning here) on Saturday.)

When building this version I kept running into small issues that I'd missed--having forgotten to reinstate levels removed for testing purposes, or an issue created by the renaming of control-names, for two examples; I sincerely hope that I haven't missed any others! ^^;

And now, to convalesce after the stresses of the past six days!




Things move that should not...

Day five!

I feel that I got a fair bit done today: I fixed my nascent enemy creature, then implemented two more; I implemented a (very, very basic) cutscene system (albeit that it's not yet fully tested, I fear); I found and began implementing music, and have put in place the skeleton of sound handling; I changed the player's attack animation; I fixed an issue in level generation (by virtue of telling it to keep trying until it gets it right); I made small progress on various other items. I even put together text for a "credits" screen. A busy day!

I think that I may have alluded to this at some stage, but I don't intend to work on Sunday; as a result, tomorrow is my final day, ending (likely) on what is technically Sunday morning. There's much to do in that last day, but I do think that I can do it!

Finally, two more teasers: my two newest toys, a far-too-realistic cannon and an aimless wandering doll.




Here the toys do not lie still...

More progress, I do believe: I now have the basics of collectable items, good progress on weapons and attacks (not that there are many weapons available), the basics of the player's death, a loading screen (complete with fades to black), simple blob shadows, and a (buggy) first enemy.

It's none of it quite finished, and there's much yet untouched (sound and music, for example), but it's getting there, little by little...

A new screenshot:

This is taken in the "starting room" of standard levels, the staircase landing. To the left and top doors open onto other rooms. Just above the player a wooden plank sits--a potential weapon. At the bottom we see the player's current health, and the bar in which items are displayed.

And finally, a teaser, I suppose: a shot of the first enemy that I've thus far implemented:




The doors open, revealing shadowy halls beyond...

A short entry today:

Yesterday, I believe, I had a single, doorless room being generated; today, I have a full, randomly-generated map of rooms, joined by doorways, and a special "starting room" for standard levels.

There's still a lot to do: enemies, items, "special" rooms (such as the starting and ending rooms), sound and music, various level objects, bug-fixes and more. Little time, and much to do!

(No new screenshots today: I'm tired, and the changes are sufficiently minor on the visual side that I deem it not worth the bother.)




Welcome to Darkholm Orphanage...

Forgive me please that this is a somewhat brief journal: it's very late here, and I'm very, very tired. However! Let me make up for that somewhat with my first screenshots!

Welcome, dear visitors, to the place that once was Darkholm Orphanage:

Most of today's work went into the code that generates rooms, I believe, and I'm fairly happy with the results. There are still some issues--the code that detects isolated regions of the room (in order to prevent regions that the player can't reach) seems to be missing some cases, for one--but I'm glad of the progress that I've made thus far.

The pits that you see don't yet kill the player, but the framework for doing so is now there, I believe.




Darkness Falls, and the Toys Move...

So, the theme is "the toys are alive". I'll confess that I wasn't enormously enthused when first I read it: a cutesy game wouldn't work well with my current mindset, and toys seem to be harder to twist to my liking than other themes.

However, ideas began to flow; turning away from the cute, the next clear option was horror. Now, I'm no great fan of Chucky-style slasher or gore-fest horror, so that's out. On the other hand, I have been thinking of late about ghosts. This led me to two main options: a first-person haunted house mystery, perhaps taking some cues from the gaze-related gameplay of P.T., and a horror-themed rogue-lite (similar to The Binding of Isaac, but without the nausea-fuel or religious-horror overtones).

The former I very much like--it's a game that I could see myself playing, I think--but is somewhat light on gameplay (which is, of course, a category in which out entries are judged), may involve more complex core gameplay (even if I use only very simple "physics", there's still somewhat to be done there) and involves a fair bit of content-creations.

The latter is of a genre that I find fascinating, but don't much play. On the other hand, I've been toying of late (pun intended ) with rogue-lite ideas, the interactions should be relatively simple to make, and content-creation might be reduced via tile-based 2D graphics and random generation of levels.

For now, at least, I've settled on that latter idea: a horror-themed rogue-lite.

To be specific, I have in mind what is more or less a small-scale survival-horror rogue-lite: the player finds themselves exploring a haunted orphanage, assailed by toys controlled by the spirits of children who died there. Health is in very short supply, items are few, and there are no lives (perhaps barring some rare item or other). The player has some ability to attack, but it's very limited.

I'm hoping to manage three randomly-generated levels, three endings, and some implied story.

Alas, I do realise that there's quite a bit of cliche there, and I'm not happy about that. But, well, time is limited...

Thus far I've come up with concepts for several toys, a handful of room types, some props, a few items, scattered events, the basics of the three endings and a skeletal (so to speak ) backstory concept. On the technical side, I've started a new project in my personal source control repository, and have the basic template program up and running (ah, the joy of finding all the bits that you forgot had become important to the running of a given piece of code...).




Preliminaries: My tools of choice, and pre-created components

Greetings all, and welcome to my "Week of Awesome II" blog!

To start with, the tools that I intend to use:
(This list should be much the same as that which I posted in the competition thread, save that I've settled on a source for game music.)

Language: Python
SDK/Engine: Panda3D
Pre-created Components: This depends on what game I end up making; I have several bits and pieces that might prove useful.
Graphics: To some degree this depends on the art style that I settle on, but my main raster-art program is GIMP, my 3D modeller is Blender, and, should I want vector art, possibly Inkscape.
Hosting: Dropbox
Sound: Sound Recorder (either Windows or Ubuntu) and Audacity, most likely.
Music: I'll most likely use music taken from Sound Image (which provides music under a Creative Commons Attribution licence, I believe).

Now, as mentioned under "Pre-created components" above, I have a number of modules and pieces of code that I might make use of in the competition, but that, without knowing what game I'm going to make, it's difficult to say which might end up being used. However, this early post makes, I think, for a good opportunity to talk about these components, and to give the community opportunity to object to any that they feel stray beyond the province of reasonable reuse.

So then, my components:
(It's possible that I've forgotten something in the below; if so, then my apologies; hopefully any such will be mentioned as it is discovered.)

The Template: This is perhaps the most fundamental and least important component: it is simply the skeleton of a project, allowing me to get started that much more quickly, without worrying about getting the basics working.
This includes:
Importation of various Panda3D and basic Python modules.
A "framework" class; this handles the overall flow of the game, controlling key-events, game-state, updates to the "world" class (below), menus, etc.
A "world" class; in template form this is merely an outline. Part of the process of making the game would be fleshing out this class with the actual game-logic.
An abstract global "common" class; this provides varous services that I want to have available at any given point in the program, such as access to the "framework" and "world", a simple fade effect, and a few more functions.
Importation and initialisation of the KeyMapper class (below).

KeyMapper: This is a module that handles both basic key-event initialisation and key-remapping, including a basic (customisable) GUI for the latter. If you use Panda3D, you should find it here.

GameSaver: A module that handles saving and loading, including a base class from which classes that are intended to be saveable should derive in order to specify what data is to be saved, and how to restore it on loading. If you use Panda3D, you should find it here.

TabbedFrame: A GUI class that provides a tabbed gui that can hold other gui items in its "pages". This has not yet been released anywhere.

SoftActor: A class that extends Panda's "Actor" class (which handled animated models) in order to provide automated blending between successive animations. As with TabbedFrame, I don't believe that I've released this anywhere.

My menu system: A combination of an abstract "controller" class that maintains a stack of menus, and a base "menu" class that can be handled by the "controller".

A pencil-sketch shader: This is a shader that I've been tinkering with of late, originally intended for an game expansion that may well not happen now; it renders geometry in a manner intended to emulate a shaded pencil sketch. This is, of course, pretty specific--it may very well not be used. But I'd like to make use of it at some stage, and may decide that my competition entry is the right opportunity.



  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!