Greetings and salutations!
Three of the four judges have given their feedback, I believe; this, I feel, is enough feedback for me to be confident of my thoughts in reviewing my Week of Awesome entry:
Tuesday, September 6. 2016
WoA IV, Post-mortem
What went well:
Focussing on the gameplay early
One thing that I've found, this year and in others, is that having the base gameplay in place early can be very important. While I think that my entry's gameplay was far from perfect, I do think that the early start helped.
Low-poly flat-shaded art, with edge-lighting.
In short, it's quick to produce--there's no time spent on UV-mapping or texture-painting, and generally only a little time on vertex-painting--and I feel that it can look pretty good.
At least one judge gave me a poor score in the graphical category (fourteen out of twenty), but the other two seem to have liked it better (one giving me sixteen, and the other twenty). It's possible that this reflects differences in the judges' feelings about the art-style itself--but the division could also come from the fairly limited palette that I chose, or from the areas in which I perhaps skimped a bit too much.
The simple lighting technique that I employed made it quite easy to add basic edge-lighting to the enemies, allowing black shadow-beings to stand out a little against a black background. Fading that edge-lighting with the light-level allowed them to nevertheless fade into the distant dark, and thus be lost from the player's sight. (I also think that it looked cool. ^_^)
If I'm not much mistaken, the judges liked my enemy models (and likewise, I'm quite happy with them).
A simple framework for game-objects
Over the course of a number of projects made with Panda3D, I've developed a few tricks and patterns for the base structure of games like this. The structure that I put in place for game-objects and attacks, based on previous projects, made it fairly easy and quick to implement new enemies and new attacks.
(For example, between this and the fact that one of my enemies already fires multiple shots per attack, the boss's spray of projectiles was actually fairly easy to implement, as I recall--something that I'm thankful for, given how late I implemented that boss.)
Panda3D
Using a third-party engine--or at least a third-party engine that one is familiar with--means that there's much that one doesn't have to worry about, doesn't have to implement: one can largely just get on with the game. Panda3D has served me well for some time now, and continues to do so, I feel.
Aside from 3D rendering, one way in which this applied to my entry was in the form of the game's physics, which use Panda3D's built-in physics system. It doesn't stack up (so to speak
) against more dedicated physics solutions, but I really wasn't looking for anything that complex for this project. Conversely, it's fairly straightforward to set up, and--for simple applications, at least--seems fairly reliable. Panda's built-in collision system thus allowed me to fairly quickly and easily implement the basic first-person-shooter mechanics on which my game as built.
What went poorly:
Difficulty!
One thing that's become clear over the past few years is that my entries tend to be far more difficult than I realise. In and of itself, I see no problem with a game being difficult (indeed, there are those who prefer such experiences), and I find that I enjoy crafting such games. However, as an entry into a game-jam, a difficult game has the disadvantage of reducing the probability of the judges seeing all that the game has to offer.
To some degree I think that the level of difficulty that I keep producing comes from my failing to get feedback during the competition (more on that presently): the game is, naturally, rather less difficult for me--the person who made it--than for a new player. Feedback might help me to discover how difficult a game is for a new player, and thus tune it as called for.
That aside, however, I do want to--in general--aim to produce slightly easier experiences in future game-jam entries.
Feedback
I really ought to look for alternative methods of getting feedback on my prototypes in future jams. I hold that it can be invaluable to have an outside perspective on one's work, perhaps even more so when one is working under so intense a schedule as I take on during a one-week jam. Offhand, In future jams I might try posting my prototypes on TIGSource, or asking friends to try my builds.
Modelling a 3D environment
Creating the environments in which my entry takes place took up a significant chunk of time. While I did make use of reusable models in composing the rooms, a number of factors resulted in the process nevertheless being perhaps lengthier than I might have liked.
In retrospect, I feel that tile-based approach is perhaps a better idea for short game-jams like this: Model a few tiles, and then create a means of putting them together to form rooms. It comes with its own complications (collision geometry would likely be generated, not modelled, for example), but I suspect that it would overall take less time to implement than did the fully-3D approach that I used here.
Would a tile-based environment have worked for this game? Likely not, or at least not nearly as well. But perhaps I should have looked for an idea that would have worked with such an environment, or accepted a potential hit to my score in the graphical category in exchange for the extra time that it might have allowed for work on the rest of the game.
Informing the player
As entered, the game does a poor job of informing that player that they're being hit--nothing beyond the health-bar falling, something that I feel is quite easy to miss. Perhaps it would have been better to have given up time spent on some small feature for a little bit more sound-work and/or some form of visual feedback (such as a "pain overlay").
The boss-fight
Simply put, while planned fairly early, this was implemented very late indeed. This shows in just how poorly designed, modelled, and implemented it is, I fear. That said, I don't think that I regret leaving it for a late point in development: Time is short in these jams, and sometimes things don't get the time that one wants to give.
(I do still like its firing pattern, at the least.)
The third, "blocking" enemy
This enemy doesn't dance around: it heads directly for the player. It has the ability to block attacks when not in a (somewhat poorly-conveyed, I fear) "tired" state. On top of all that, the enemies don't collide with each other; while most enemies move around enough that this isn't an issue, these enemies can quite easily end up "stacking".
The result is, quite frankly, a little boring. They're just not all that fun to fight. If I were taking this project further, I would likely remove their ability to block, and enable collision between enemies, at the least.
What I'm uncertain about
The AI
The enemies in my entry were fairly quick, and inclined to dodge around the player. At least one judge liked this, while at least one other mentioned it in a negative light. In the latter case, however, I wonder whether this might not be a result of other elements of the gameplay--such as the aforementioned difficulty and lack of damage-indicators--souring the effect of the enemy AI.
(Personally, I like the movement-patterns of my enemies: I find that it makes them a little more interesting than the basic "run at the player" AI, and like that it makes them a little harder to hit. But then I am biased, after all.)
Audio
My scores here ranged from half-marks to full-marks. One thing that I think wasn't well-conveyed was that the "hissing" or "wind" noise was that of the enemies moving--perhaps something more distinct (voices?), or starting off with only a single enemy, might have made that connection clearer.
Either way, I do think that I tend to leave sound rather too late in these jams; I think that in future jams I should perhaps start working on it a little earlier.
Another point is that sound is, I feel, not my forte; this is perhaps something to think about for future jams.
Conclusion
Overall, I'm fairly happy with what I produced, but not as happy as I'd hoped.
I don't think that I'm going to take this project further: I have a primary project to attend to, and I don't want to devote to this project that additional time that I imagine is called for.
(To that end, I've removed the "Week of Awesome IV" project page, which also removes its associated button on the general "Projects" page, I believe.)
However, the base on which this game is built may yet have some use: I'm fairly happy with it, and am tempted to use it for future jams (likely not the Week of Awesome jam, given the rules). I even have in mind an idea for a first-person hack-n-slash game, should I do so.
Thus ends, I believe, the story of my entry in the Week of Awesome IV! It was a really enjoyable experience, and one for which I'm grateful to the organiser (slicer4ever). I'm eager to enter next year's competition, and intend to keep my eyes open for other interesting game-jams in the meanwhile.
Stay well, and thank you for reading! ^_^
Focussing on the gameplay early
One thing that I've found, this year and in others, is that having the base gameplay in place early can be very important. While I think that my entry's gameplay was far from perfect, I do think that the early start helped.
Low-poly flat-shaded art, with edge-lighting.
In short, it's quick to produce--there's no time spent on UV-mapping or texture-painting, and generally only a little time on vertex-painting--and I feel that it can look pretty good.
At least one judge gave me a poor score in the graphical category (fourteen out of twenty), but the other two seem to have liked it better (one giving me sixteen, and the other twenty). It's possible that this reflects differences in the judges' feelings about the art-style itself--but the division could also come from the fairly limited palette that I chose, or from the areas in which I perhaps skimped a bit too much.
The simple lighting technique that I employed made it quite easy to add basic edge-lighting to the enemies, allowing black shadow-beings to stand out a little against a black background. Fading that edge-lighting with the light-level allowed them to nevertheless fade into the distant dark, and thus be lost from the player's sight. (I also think that it looked cool. ^_^)
If I'm not much mistaken, the judges liked my enemy models (and likewise, I'm quite happy with them).
A simple framework for game-objects
Over the course of a number of projects made with Panda3D, I've developed a few tricks and patterns for the base structure of games like this. The structure that I put in place for game-objects and attacks, based on previous projects, made it fairly easy and quick to implement new enemies and new attacks.
(For example, between this and the fact that one of my enemies already fires multiple shots per attack, the boss's spray of projectiles was actually fairly easy to implement, as I recall--something that I'm thankful for, given how late I implemented that boss.)
Panda3D
Using a third-party engine--or at least a third-party engine that one is familiar with--means that there's much that one doesn't have to worry about, doesn't have to implement: one can largely just get on with the game. Panda3D has served me well for some time now, and continues to do so, I feel.
Aside from 3D rendering, one way in which this applied to my entry was in the form of the game's physics, which use Panda3D's built-in physics system. It doesn't stack up (so to speak
) against more dedicated physics solutions, but I really wasn't looking for anything that complex for this project. Conversely, it's fairly straightforward to set up, and--for simple applications, at least--seems fairly reliable. Panda's built-in collision system thus allowed me to fairly quickly and easily implement the basic first-person-shooter mechanics on which my game as built.What went poorly:
Difficulty!
One thing that's become clear over the past few years is that my entries tend to be far more difficult than I realise. In and of itself, I see no problem with a game being difficult (indeed, there are those who prefer such experiences), and I find that I enjoy crafting such games. However, as an entry into a game-jam, a difficult game has the disadvantage of reducing the probability of the judges seeing all that the game has to offer.
To some degree I think that the level of difficulty that I keep producing comes from my failing to get feedback during the competition (more on that presently): the game is, naturally, rather less difficult for me--the person who made it--than for a new player. Feedback might help me to discover how difficult a game is for a new player, and thus tune it as called for.
That aside, however, I do want to--in general--aim to produce slightly easier experiences in future game-jam entries.
Feedback
I really ought to look for alternative methods of getting feedback on my prototypes in future jams. I hold that it can be invaluable to have an outside perspective on one's work, perhaps even more so when one is working under so intense a schedule as I take on during a one-week jam. Offhand, In future jams I might try posting my prototypes on TIGSource, or asking friends to try my builds.
Modelling a 3D environment
Creating the environments in which my entry takes place took up a significant chunk of time. While I did make use of reusable models in composing the rooms, a number of factors resulted in the process nevertheless being perhaps lengthier than I might have liked.
In retrospect, I feel that tile-based approach is perhaps a better idea for short game-jams like this: Model a few tiles, and then create a means of putting them together to form rooms. It comes with its own complications (collision geometry would likely be generated, not modelled, for example), but I suspect that it would overall take less time to implement than did the fully-3D approach that I used here.
Would a tile-based environment have worked for this game? Likely not, or at least not nearly as well. But perhaps I should have looked for an idea that would have worked with such an environment, or accepted a potential hit to my score in the graphical category in exchange for the extra time that it might have allowed for work on the rest of the game.
Informing the player
As entered, the game does a poor job of informing that player that they're being hit--nothing beyond the health-bar falling, something that I feel is quite easy to miss. Perhaps it would have been better to have given up time spent on some small feature for a little bit more sound-work and/or some form of visual feedback (such as a "pain overlay").
The boss-fight
Simply put, while planned fairly early, this was implemented very late indeed. This shows in just how poorly designed, modelled, and implemented it is, I fear. That said, I don't think that I regret leaving it for a late point in development: Time is short in these jams, and sometimes things don't get the time that one wants to give.
(I do still like its firing pattern, at the least.)
The third, "blocking" enemy
This enemy doesn't dance around: it heads directly for the player. It has the ability to block attacks when not in a (somewhat poorly-conveyed, I fear) "tired" state. On top of all that, the enemies don't collide with each other; while most enemies move around enough that this isn't an issue, these enemies can quite easily end up "stacking".
The result is, quite frankly, a little boring. They're just not all that fun to fight. If I were taking this project further, I would likely remove their ability to block, and enable collision between enemies, at the least.
What I'm uncertain about
The AI
The enemies in my entry were fairly quick, and inclined to dodge around the player. At least one judge liked this, while at least one other mentioned it in a negative light. In the latter case, however, I wonder whether this might not be a result of other elements of the gameplay--such as the aforementioned difficulty and lack of damage-indicators--souring the effect of the enemy AI.
(Personally, I like the movement-patterns of my enemies: I find that it makes them a little more interesting than the basic "run at the player" AI, and like that it makes them a little harder to hit. But then I am biased, after all.)
Audio
My scores here ranged from half-marks to full-marks. One thing that I think wasn't well-conveyed was that the "hissing" or "wind" noise was that of the enemies moving--perhaps something more distinct (voices?), or starting off with only a single enemy, might have made that connection clearer.
Either way, I do think that I tend to leave sound rather too late in these jams; I think that in future jams I should perhaps start working on it a little earlier.
Another point is that sound is, I feel, not my forte; this is perhaps something to think about for future jams.
Conclusion
Overall, I'm fairly happy with what I produced, but not as happy as I'd hoped.
I don't think that I'm going to take this project further: I have a primary project to attend to, and I don't want to devote to this project that additional time that I imagine is called for.
(To that end, I've removed the "Week of Awesome IV" project page, which also removes its associated button on the general "Projects" page, I believe.)
However, the base on which this game is built may yet have some use: I'm fairly happy with it, and am tempted to use it for future jams (likely not the Week of Awesome jam, given the rules). I even have in mind an idea for a first-person hack-n-slash game, should I do so.
Thus ends, I believe, the story of my entry in the Week of Awesome IV! It was a really enjoyable experience, and one for which I'm grateful to the organiser (slicer4ever). I'm eager to enter next year's competition, and intend to keep my eyes open for other interesting game-jams in the meanwhile.
Stay well, and thank you for reading! ^_^
Trackbacks
Trackback specific URI for this entry
No Trackbacks
