Welcome, young traveller. Rumour has it that some human crash-landed on this planet before you did. The nerve of the guy! This is our crash site! But before you contemplate how to enjoy the rest of your painful stranded life, some armored creature calling himself 'Demiurge' is already offering you a helping hand with your very immediate escape, by means of pure force. This would be helpful, if that escape in question wasn't death, and he wasn't trying to kill you.
Fortunately, a wannabe villain so bumbling as Demiurge only reveals weaknesses in the cultural hiearchy of this planet of strange creatures. For one thing, while they worship him for his seemingly godlike modern technologies, they don't seem to like him as much as... well... he does; and resultedly your popularity seems to be growing the more you treat the creatures as soulful sentient beings. Perhaps there is hope after all for you to escape the peaceful way, but not before giving Demiurge a taste of his own medicine!
Featuring karma-based combat where peaceful and deflective fighting styles will win over the natives of this lost planet, Demiurge is an action-story sci-fi game with a funny tone and a feeling of player participation. You play as Yourself, a boring regular individual with a fairly unremarkable face and a proneness to stare at computer screens and read the Internet (with a particularly good taste in blog posts, such as this one).
The gameplay of this prototype is designed to be simple and accessible. You are equipped with a shield and a laser gun. To give yourself a fighting chance, use your shield to deflect enemy shots back at them. Defeating enemies with their own projectiles, or each other's, earns you karma. Karma charges your weaopn, making the shots much more powerful.
As an innocent traveller, your only role in this game is to survive. However, to survive you must give the misguided population a taste of their own medicine.
Hi there! I'm Louis. Let me introduce you to my role in the development of Demiurge. Actually, truth be told, there are many. For example, I've broken the engine enough times to deserve a new role of fulfilling the the team's GDP quota (Generally Destructive Person). But I'm asked not to talk about that, particularly by myself, who wishes to be correctly recognised as the most fabulous and amazing person ever.
My work on Demiurge includes:
And to a lesser extent, helping with miscellaneous design contributions, creative directions, and promotion efforts with the team (gameplay footage, presentations, trailer music, etc).
But primarily, I was a generalist programmer. The majority of the game as made in blueprints. This is a shame, as C++ is my favourite language, and I began by writing the dialogue system in it. However, noting a lack of team C++ experience, its crash-proneness, long compile times, and the fact that several computers refused to compile it entirely, I believe to use Blueprints was almost certainly the more productive decision. As a result, I took a conscious decision not to nag my team mates to use my favourite language, and my work beyond the dialogue system was written entirely in Blueprints.
The game follows a traditional Unreal Engine hiearchy: Player and enemy subclasses inherit from a base character with movement and physics components. Control of the character types, also known as 'pawns', is handled with character controllers: classes which control the actions of a character, in such a way that a character could be reused by AI, the player, or a networked player.
There is a slight snag: I notice that player control is actually handled through its pawn class, rather than a controller. That implementation was made by another programmer whilst learning unreal. It is unconventional, but it came at no particular cost to us, so I didn't rush to move them into a character controller. It does, however reflect something I might change for next time (although in this game there wouldn't have been any notable benefits to doing it).
When we started the project, our general understanding as a team was that Unreal doesn't provide any particular means of delivering scripted dialogue, besides basic user interfaces. As a story-based game with initially high ambitions, dialogue was considered a key component of the player experience. To fill this empty hole in the system, I wrote a C++ interpreter of 'Inky(tm)' style scripts. I then incorporated it Unreal as a new factory (to make .txt files loadable), asset type, and various additional classes for interpreting the script.
Early on in preproduction, we knew we had no audio person, and similarly no character art expertise. This gave me concerns about team inspiration, so during Christmas I promised to myself that I'd make a soundtrack to the game to boost morale and give the game an artistic style. I made the music in LMMS. It was a great experience to dip into an unfamiliar genre--electronic music--and I had fun tweaking sounds and synthesising my own. Amusingly, the tracks were all made before assets and level plans existed, except for the level music, which itself was a remixed version of the trailer music (also made before the trailer existed).
When it comes to my gameplay contributions, I have a natural focus on adding the more unique features, and making them interesting. We came up with the shield mechanics quite late in development. We knew we'd have a shield, but it became blurred with the other mechanics which were eventually downscoped. The shield survived. It was my favourite part of the combat mechanics, and fairly unique, and I maaay or may not have played a part in making sure it survived the cut. I implemented the shield deflection mechanics along with the weapon charge mechanic. (Mango also played a part--particularly in adding a toggle so shield wasn't always glued to the player's face.)
I did this, unaware that the ProjectileMovement component did in fact support deflection from the very beginning, along with axis locking. When I learned they exist, I refused to accept the first reality, and silently tickboxed the second to fix some bugs we were having. But of course this is all entirely hypothetical.
Along with the music, I made various miscellaneous tweaks to the gameplay to further improve the look and feel of the game. This included making the deflected bullets change colour when deflected, to indicate whose side they were on, and changing the size and sound pitch of bullets depending on their power level. This made the game a little more reactive to the actions of the player, hopefully guiding them to improve their combat skills. I also cleaned up minor bugs, like oversized hitboxes and collision glitches, to avoid distracting the player and maintain a quality appearance.
This was one of the hardest parts of the project, but also the most rewarding. Communication is one of my self-proclaimed weakness, but I was interested in being a scrum master to improve my leadership skills. Fortunately, the team were happy for me to be one. Less fortunately, no-one else wanted to be one. I always saw that as a red flag in the team dynamics.
I wonder how much responsibility I hold for that--I voice my opinions a lot, in a way that comes across like I know what I'm doing, perhaps making some people more dependent on me instead of autonomous. It would probably have been better to switch scrum masters throughout the project so that any recurring mistakes I made could be learnt from. This was the advice of the PO and myself, but again no one expressed interest in this during meetings, but again maybe I came across as though I were too organised for anyone else to compete. That definitely wasn't what I was trying to convey, but I'm starting to understand that my attitudes and body language might influence others more than I realise, despite believing myself open-minded.
I learned a lot. For example, I started off loose with the meeting times--trying to discuss with the team, using Slack and/or polls, to decide the meeting times. This didn't work well, and showed a more reactive than proactive approach. As the game progressed, we experimented with different formats: stand-ups at the end of the session instead of before (not particularly successful), delaying stand-ups due to low attendance (hard to tell--probably not successful), holding strict stand-up times (again hard to tell, is probably a better motivator), etc. It was a challenging learning experience, but on a personal level, was worth it.
I have also realised I don't make a good role model for motivation. As a person, I work too hard and am prone to stressing myself out. My goal is reduce this so that I don't leak stress, instead conveying positive motivation to my team. Make no mistake--overall, my team's productivity was high--but the lack of enjoyability in making the game likely hindered production in many ways. A motivator will have a positive attitude and work ethic that balances hard work with smart breaks, and most importantly enjoys the development process with the team. This is the type of person I will strive to become as we wrap-up this game.
Hello! I'm Tomas, playing a programming role in this team. Although I'm not as experienced programmer as other of my mates, but Unreal gives a good feature to make a lot of stuff with blueprints. And that's what I did the most. Nonetheless I had been working in Unreal before, so I had a brief knowledge of how to make most of the basic stuff, including blueprints.
First thing I did for the game was write a base class for all characters - player and enemies - which included health variable, damage and the way health is calculated when hit. This was written in the C++ code, which is the only one I did, unfortunately. I then made several blueprints for our player character and an enemy, which then became a base class for future enemies.
Nonetheless, I was working mainly on the AI of the game, making different types of enemies - melee, shooting and explosive ones. The explosive enemies like to kill themselves while taking the player with them. But let's not focus on this particular enemy, shall we? I was using behaviour trees together with AIControllers to all of the enemies, except for the shield ones, because they just need to stand still and deflect the players bullets. I was making tasks, decorators and services for these behaviour trees, which provided a more precise AI behaviour.
Besides AI I also wrote most of the player controls and player-related things, such as camera rotation, equipment and inventory systems. The last two, unfortunately, are not used in the game, as we didn't implement any items for the player to use and maybe keep in the inventory. The most problematic was camera rotation, as I had to change world's original rotation when rotating the camera itself, so that the player has more accurate movements.
Greetings! I'm Mango, the third and final programmer for this project. Overall, I was probably the least experienced member of the programming team, lacking knowledge of both C++ and Unreal. Being new to Unreal has probably been the largest challenge for me during development, as I have had to learn many new concepts and workflows related to Unreal.
Architecturally speaking, we wrote relatively few classes for the game. Most of the game is based around a handful of key classes, including HeroCharacter, Enemy, Projectile, Shield and Weapon. Each class therefore has to handle a lot of functionality and are quite heavily connected. Although I created some of initial classes, such as ShooterEnemy, early on in development, for a lot of the project I have worked quite heavily on bugfixes and small features. Things such as adjusting the player's gun spawn position so that it shoots more accurately, and making the shield activate and deactivate on keypress are some examples of the tasks I have worked on.
One of the slightly bigger features I worked on was the animation blueprints for the player and enemy characters. In this class, the update event reads data from the player character, (speed, direction, if they are shooting, etc.) which is then stored in local variables. These variables can then be accessed in the transition functions, where a set of conditions are defined to specify when the character is allowed to move between animations. One interesting thing I encountered during this was dealing with the death animation. Unlike other animations, I wanted the player to be able to enter the death animation from any other animation state at any time. To avoid large amounts of duplicated code (and a messy and complicated set of arrows in the state machine) I opted for a slight workaround. Instead of dealing with the death animations in the animation blueprint, I added a second mesh to the character blueprints, and gave that mesh the death animation. I could then hide the default mesh and show the death mesh whenever the player died. This worked well for our project as it kept the animation state machine simple and was a quick workaround that didn't take too much time to implement. However, it did mean that not all animations were handled by the animation blueprint, which could be an issue if the project was expanded.
As the enemy animations were implemented fairly late in development, I did not spend much time planning their animation blueprint. In retrospect, it could have been possible to create a base animation blueprint dealing with common animations such as walking and idling, that both the player and enemy animation blueprints could inherit from. Each derived blueprint could then deal with specific animations such as shooting or shielding. This would have simplified each animation state machine further, making it very user-friendly. However, the cost of developing a more complex series of classes would probably have been greater than the value of the changes, as my priority at the time was simply to implement the animations quickly, as we needed a finished build very soon.