next »

[thebarryman]

The Groov Cosmos is an action-adventure set in a parallel universe in which musical energy is the ultimate source of power.

I started thinking about The Groov Cosmos soon after I completed my first game, Groov. I was trying to think of how I could evolve the song/game mechanics I developed in my first game into a more robust experience, and landed on the idea that rather than "traversing" a single song by progressing through waves of enemies, the player would literally traverse a huge, non-linear composition comprised of smaller subsections, in the form of puzzles and combat.

I've put a lot of work into developing the engine and toolsets for creating the game, and probably not enough time into actually making the game itself. I've also been toying with the idea of porting my work to Unity rather than continuing to make the game while developing my very limited engine (no scripting support, etc.). Any advice on this front would be much appreciated!

[thebarryman]

Took a couple of screens:

[Franklin's Ghost]

Those colours look great, like the atmosphere it presents.

[thebarryman]

@Franklins Ghost -- Thanks! I spend way too much time on colors, glad to hear it's paying off!

OK, time for my first long post in this devlog since I've gotten a lot of work done over the past few days. To kick things off I'll post a tech demo that was made using the stuff I'll be talking about. So without further ado, I proudly present The Cosmos AV Orchestra Plays the Hits: Fruity Juice!





Over the past few days I've been investing more time into building my engine and tools. While I have functional tools for creating music, scenes, dialog and 3D models, I don't have a system for actually writing the game logic itself rather than plain old C#. Since I don't have scripting support, it makes iterating on levels take forever since the whole project has to build and load before I can see the results of a tiny change to my gameplay code. This basically led me to stop working on the game for a while.

So my first order of business was to add an "audio-visual" editor to my toolset. The idea with this editor is to design gameplay objects that can interact with both my scene and music engines. Rather than trying to figure out an entire scripting language, I decided to still use C# for my gameplay code, but with a couple of enhancements.

In figuring out how my editor would work, I took a page out of the built-in Visual Studio Winforms designer. My editor creates two files for each gameplay object: a mostly empty file that can be typed in and quickly recompiled while the editor's open, and an auto-generated code file that saves all of the parameter defaults and some other stuff I'll get to next. Another nice thing I finally figured out to use was the Winforms PropertyGrid control, which is automatically populated with public parameters, so I can instantly tweak variables as soon as I define them. Whenever they're tweaked, they get saved to the auto-generated code file so that when I change some code and reload the object, all of the parameters stay the same. Partial class are actually pretty cool!

The nice thing about this approach is that I can write code and tweak parameters and see the results instantly, but when I close my editor and build my project, I can debug and tweak the results like any other C# code, which avoids some unpleasant downfalls of scripting language.

The next big thing I've been working on is building an event system. I had a half-baked version of this implemented a while ago, but it was very single-purpose and was basically never used except for when enemies would explode. I completely overhauled the system and it is now really easy to work with and very flexible. Now any musical object in my engine can have inputs and outputs that can be plugged into one another. I still have to rewrite some older stuff in my engine that would benefit from the event system, and also need to integrate it with my audio-visual editor. But I can plug a piano into a couple of music patterns and it plays!