Alpha OCTAVIA [Musical-RPG-School-Murder]

Fern

Member


OCTAVIA
Uhm, hi guys! Octavia will be a story-focused game, with some composition puzzles, exploration, and - I hope - some really cool characters. You'll be a new student, a peasant, who received a scholarship to study composition in the renowned music university, Octavia. You'll need to follow rules of composition to make a good song and have a satisfactory grade to stay on Octavia. The point of this game is make the player ponder about creativity and mediocrity, which I guess is a pretty common feeling on content creators. There will be randomized characters, side quests, a somewhat random generated map, gossip system and more.

The game is in an very early development, and I'm really sorry for starting this post without that much content, but I hoped doing this devlog would help us keep our determination. Oh, and we're using Game Maker on this one. This post will be edited along the way for more significant gifs and description. Follow us on twitter (@i_am_thirteen, @seabass_n, @tophtacular) for more constant updates!





 

Fern

Member
The programming behind Octavia!

When we began discussing Octavia all I could hear Thirteen saying was, "None of this is going to be easy with Game Maker because it's single-threaded."
The lack of asynchronous/threaded capabilities definitely is hindering to most GM users but that alongside my dismal amounts of confidence in completing a project of this scale has caused me to prepare like never before.

How to bypass our lack of threading

From the beginning I realized having a school full of students that can walk, talk, follow routines, and interact in lots of different ways could cause some major performance issues. On top of this we needed to generate our world with tons of random variations that would take loads of time to process. Now you see when GM gets caught up processing code in a single frame the window simply stops responding. Dropping a few frames isn't a major issue but the game appearing to have crashed is an issue.

At first I attempted to write the world generation to work itself out across multiple frames with some code that looked something like this...

How not to do multi-step processing

Code:
// Create Event
step = 0;

// World Generation
switch ( step ) {

    case 0:

        // Generate rooms
        ++ step;

    break;

    case 1:

        // Generate corridors
        ++ step;

    break;

}
Now here's why that approach is horrible under-cooked lasagna. Say that generate rooms takes 15 frames to process on my computer but it takes 350 frames on a some other slower computer. This would make porting to consoles (one day in the future) a massive pain in the butt. The Nintendo Switch might take 2x longer to do CPU-based work than the Xbox One and generally writing code in a one size fits all style is ill advised.

My second attempt was far better and made a lot more sense. It takes this idea of breaking up code into multiple steps a bit further by providing a framework for deferred processing. I am now able to give the game tasks to complete. These tasks contain sets of scripts and a desired framerate. The framework handles everything else.

The way this system handles code is also much cleaner and more readable than my previous approach. Here's a sample...

The right way to do multi-step processing

Code:
gml_task_create(

    // Task name
    "world_generate",

    // Target framerate
    60,

    // Scripts
    chunk_ini,
    chunk_generate_rooms,
    chunk_generate_corridors,
    chunk_generate_corridors_cleanup

);
You can grab it for yourself right here for free.

I hope this post was informative and useful. I'll continue to post more GML tech stuff such as this as we move forward!
 

JackTurbo

Member
Really like your environmental chunks they look great.

And your multi-step processing sounds really interesting!

Top notch work as always Seabass :)
 

Fern

Member
Really like your environmental chunks they look great.

And your multi-step processing sounds really interesting!

Top notch work as always Seabass :)
Thanks so much! I'll be posting more tech-related stuff as I go and the artist will continue to share concept art for the coming months and hopefully final assets soon after!

Love the colours too, man! Good luck with your project. Hope it goes well for you!
It's always good to hear from you. It's a good sign that nobody hates the art. :D

You need this in your signature asap
I want to but we don't have our website done yet and we don't have official marketing artwork yet. :p I know I need to keep my signature up-to-date. haha
 
F

Felipe Rybakovas

Guest
The programming behind Octavia!

When we began discussing Octavia all I could hear Thirteen saying was, "None of this is going to be easy with Game Maker because it's single-threaded."
The lack of asynchronous/threaded capabilities definitely is hindering to most GM users but that alongside my dismal amounts of confidence in completing a project of this scale has caused me to prepare like never before.

How to bypass our lack of threading

From the beginning I realized having a school full of students that can walk, talk, follow routines, and interact in lots of different ways could cause some major performance issues. On top of this we needed to generate our world with tons of random variations that would take loads of time to process. Now you see when GM gets caught up processing code in a single frame the window simply stops responding. Dropping a few frames isn't a major issue but the game appearing to have crashed is an issue.

At first I attempted to write the world generation to work itself out across multiple frames with some code that looked something like this...

How not to do multi-step processing

Code:
// Create Event
step = 0;

// World Generation
switch ( step ) {

    case 0:

        // Generate rooms
        ++ step;

    break;

    case 1:

        // Generate corridors
        ++ step;

    break;

}
Now here's why that approach is horrible under-cooked lasagna. Say that generate rooms takes 15 frames to process on my computer but it takes 350 frames on a some other slower computer. This would make porting to consoles (one day in the future) a massive pain in the butt. The Nintendo Switch might take 2x longer to do CPU-based work than the Xbox One and generally writing code in a one size fits all style is ill advised.

My second attempt was far better and made a lot more sense. It takes this idea of breaking up code into multiple steps a bit further by providing a framework for deferred processing. I am now able to give the game tasks to complete. These tasks contain sets of scripts and a desired framerate. The framework handles everything else.

The way this system handles code is also much cleaner and more readable than my previous approach. Here's a sample...

The right way to do multi-step processing

Code:
gml_task_create(

    // Task name
    "world_generate",

    // Target framerate
    60,

    // Scripts
    chunk_ini,
    chunk_generate_rooms,
    chunk_generate_corridors,
    chunk_generate_corridors_cleanup

);
You can grab it for yourself right here for free.

I hope this post was informative and useful. I'll continue to post more GML tech stuff such as this as we move forward!
Hey man, great art there and great code...

I did not open the file to read yet, but I'm asking myself how much effort would be necessary to do it on 1.4 ?
 

Fern

Member
Not much. I just didn't write it for GMS 1.4 so there might be some stuff that GMS 1.4 doesn't like about it.
 
Top