Devlog #05: Production Sprint 1 – Week 2
Hello everyone, we are already in week 2 of the first production sprint. Time is flying but we are making great progress. This week we’ve been spending a lot of time implementing feedback from our supervisors and adding the core features of our game.
We took a step backwards in order to contemplate about the major shapes in our level. We applied a neutral development grid on our blockouts to get a better grasp on the scales of our creations put in the engine. The lack of colours and the reign of neutral grey values allowed us to focus on the more fundamental aspects of our level's design. A lot of emphasize was placed on getting the scaling right between different meshes and between the level and the meshes.
Due to reorganizing our build, the level got scaled down, which caused a few hickups. For example, the standard movement speed of the player went way too fast and some of the hit boxes of our meshes were still really big. We have been able to fix these issues luckily.
The organization of the folders is improved. We started to implement proxy meshes and synchronized these with the improved folder structure. Quite a few assets are already set up with a proxy mesh holder. The only thing left to do is basically to connect the final model and material to the input of each placeholder and we’re good to go for most of the fundamental level components. The innermost structure is starting to get a solid shape that is efficient to use throughout the whole production process.
Art
Our focus is now on making the game look and feel coherent. We made sure to rig and skin our character and use animations from Mixamo for our character’s walking and running cycle. We try to focus on making sure that our models look good and readable in our game engine. We continue to model and texture our most important assets, like the crown, players weapons and traps.
Whenever a player uses an ability, this event should be made clear to all the players involved. This is important to maintain the balances in the game and to keep the readability of the visual aspect of the game of high quality. This can be done effectively by means of shaders and RFX. However, by taking into account the loss of details due to the distance of the camera to the actual particle effects, we were able to create interesting effects with relatively cheap solutions. The only scale that determines how we will solve our questions of graphic nature, is the scale that the player will perceive when playing the game.
While some particle effects are already solved, some still remain work in progress. We hope to have created most of our particle effects and special shader effects necessary for our game by the end of the next milestone.
Programming
On the programming side of things for this week, we started implementing traps and ghost abilities.
First up was our ground spike trap, which will serve as the base class for our other traps as well. This means it needed to have both function, and an implementation for the visuals.
The spike trap in particular has, as you would guess, spikes that pop up from the floor. Getting these in the right position proved to be a bit more difficult than expected however.
Luckily we managed to fix that soon after, so now we have functional spikes that pop up and stun whoever walks over them!
Next up was our main ghost ability, nicknamed the Ghost Cry.
This one currently has no visuals yet, but presented us with an interesting conundrum. We could implement these abilities as a separate class, a unique part of our game. Or, we could program them in as items! We considered this after noticing that much of the fundamentals of the ghost abilities would function the same way our items currently do, so it made a lot of sense.
We ended up choosing to implement the Ghost Cry as an item indeed, which would allow us to potentially integrate it in the item boxes scattered around the level, as well as let us toy around with using items as ghost abilities or vice versa.
Sound Design
Programming
After many hours of work, we came to the conclusion that there was a fatal flaw in the sound manger we made during prototyping, namely instancing. In short terms, this means that the moment more than one object in the game wants to start playing a sound it would get tangled up as it didn't know which item it was. This has now been fixed and has a better layout.
The new layout has the option for volume/pitch randomization and looping when applying the needed sound files (either a single file or multiple).These can be assigned with the sound type drop down menu. Now there is a single screen that has all the options we need for applying audio in one central window. Finally, we made the option to randomize the location the sound comes from (if there is more than 1 location given at the object).
Now, in the object we can get this window to add the locations and then play these when needed.
Design
We implemented the most important aspects of the game this week; namely the crown, attacks, item boxes and the speed/ oil flask item.
For easter we will be taking a short hiatus. We hope to see u all back in the upcoming weeks ahead.
See you in the next devlog!
Files
Get Crowned Control
Crowned Control
A game about teamwork, betrayal and knights
Status | Released |
Authors | gsteven, Aserbest, Mortepoule, Joren Dresselaers, dayellcolin |
Genre | Action |
Tags | Co-op, crown, knights, Low-poly, Multiplayer, party-game, Top-Down |
Languages | English |
More posts
- Devlog #11: Polish Sprint – Week 2May 30, 2023
- Devlog #10: Polish Sprint – Week 1May 23, 2023
- Devlog #09: Production Sprint 2 – Week 3May 16, 2023
- Devlog #08: Production Sprint 2 – Week 2May 09, 2023
- Devlog #07: Production Sprint 2 – Week 1May 02, 2023
- Devlog #06: Production Sprint 1 – Week 3Apr 25, 2023
- Devlog #04: Production Sprint 1 – Week 1Mar 28, 2023
- Devlog #03: Game DesignMar 21, 2023
- Devlog #02: Prototype BuildMar 14, 2023
Leave a comment
Log in with itch.io to leave a comment.