Mise en place

In anticipation of putting all the different rooms into my building, I realized that my map size is way too small. Even more so if I want to make some pretty “background” art around the label building. So I naively just raised the room size and thought that was all I had to do. But when testing the game, it was suddenly extremely choppy. Performance just tanked by doubling room size. But it weirdly made sense to me at that point. The (entire) map gets drawn every frame, so if the map is bigger, there are much more calculations going on every frame. So I needed a solution to raise performance. I confirmed my suspicion, that the issue was less the drawing of the map, but rather the calculation behind the scenes, which transfers the tilemap into an isometric rendering. So I had to limit the number of tiles that get “isometrified”.

After fiddling around for a few hours, I managed to introduce “culling”. Now only the tiles that can actually be seen are checked for their value by the renderer and are consequently drawn. I’m pretty proud that I managed to come up with a solution for this by myself :) Now I can make the map much bigger without losses in performance. I sadly haven’t got the zoom-out-feature working yet, but this culling-approach might need further optimization for zoom-out to work out anyway.

Over the last week I created 1’532 individual (still placeholder) sprites to make up all the rooms and give me the flexibility to make them all look distinct later on. It’s quite mundane work, but I feel like I’m going through it in an efficient way, that let’s me focus on the programming of all the interdependencies soon. I’m very much looking forward to that now… Also, things are prepared now, so that I can create prettier sprites for the rooms in the future.

I made my life worse, but the game better, by having variety in the room shape and size:

Time & Space

I got one thing done and one big thing set out.

The thing I got done might seem little, but created a good theoretical basis for a lot of systems of the future: time controls. To be able to create those little buttons (and them actually working), I had to make a flexible system for time increments (on which the calendar is already based). I will be able to use those time increments as the foundation of all the things that “take time”. So recording an album for instance, takes a certain amount of time increments (instead of actual time) - meaning, that I am now differentiating between real and in-game time. And in-game time can be controlled by these little buttons.

The big “setup” I worked on, is in how I create the rooms for the game. Building and upgrading rooms is a big part of the game (and the management of your label), so I felt like it doesn’t make sense to just go “room by room” for every development (every time updating all the connected objects and scripts, when I’m on a new room). So I wrote up, which code I have to update to create a new room and will now try to go stage by stage, instead of room by room. At least I will have the setup for all rooms programmed then and won’t need to update my tileset (as an example) every few days. It also means, that creating the rooms and their interactions will be my next big project.

Origin Stories

The musician creator is getting more and more complete for the moment. I feel like that this was a good decision, as it forces me to work on all the different parameters of the musician-entity. In principle, these are at the bottom of the whole logic, as musicians are the ones who “progress” over the playing time.

Aside from creating for instance the “region of origin” (they are fake regions based on real-world countries and continents I’m creating flags and descriptions for - I hope r/vexillology, or at least r/vexillologycirclejerk, are proud of me) I also managed to bring the sprites into the map. I already dread the day, when I start animating, as I don’t see any other option than animating every piece of clothing (in every color) manually…

In the bottom you can see that I also implemented the time system. I basically just copy-pasted it from my earlier MVP prototype. So now there is a time source that I can build upon as well. It is one of the aspects that will need a lot of testing to see, how fast the time should go by. Time is an extremely important factor, for instance when it comes to your competition (charts), the running costs of your studio, changing trends in music, etc.

Bodybuilding

I continued by building the basis for my musician creator.

While doing it, I realized that the whole “everyone should be able to look differently”-system will be quite the big undertaking. So I think I’m gonna table that for a later point, when I actually have some sprites created. Otherwise I have to invest a bunch of time into creating a lot of placeholders, just to confirm my thesis, how this is gonna work. I do have the basic system built, but there is just some optimization that I have to look into, so that each musician isn’t built sprite-by-sprite in every rendering. I mean, in a sense, that isn’t circumventable in any case, but at least I should be able to not repeat a huge junk of code in a lot of places, and just be able to store the information on who gets what sprites for which animation somewhere central.

Maybe I make that “later point” come sooner*, and I’ll spend some time making actual sprites in the near future, so I can work on this system further. So far I kinda pushed back everything that included working on the actual sprites, as I felt like this is like the last - but probably longest - step of this development. Like, when everything works, I spend a year making it all look good… But it might be smart to do some in-between phases, where I don’t program as much and spend some time in photoshop creating assets. That will probably keep me from going crazy later on.

Oh, and as you can see, I made the first “real walls”. To get them to actually overlay my musicians, I had to rework my render-object a little bit and create a wall-object for these kinds of walls. The way it works, it creates instances of the wall every step and deletes them right after. That’s the only way I could put them into my priority queue together with the musicians, so that they get depth-layered the right way. Something deep inside me tells me that this will mess up performance later on, but it works for now…

*UPDATE:
I did create some assets to actually test the system decently. So a few hours later, the musician creator now looks like this:

If you build it, they will come

To build a business, you need to build the room for it first. So now there’s a room builder! Like with some other things I developed so far, I have only the CR-component of the CRUD-model integrated, but it’s a good start :)

In a way, one of the greater building blocks is now done at its core: you can build rooms, assign artists to them (that are made up of musicians), they go to and interact with the room. I’d like to say: and this is where the magic happens - but there is no magic yet. Just people standing around in a room that you’ve built. But the possibilities now are endless!

So I feel like there are two ways to go from here:

I could start building a next building block, which I feel like logically would be creating musicians yourself. There are obviously some other building blocks I need to still build as well, like the program’s backbone (saving & loading, etc.), the general parameters (time, money, trends, etc.), the whole creative “business” (creating songs, albums, etc.), but if I go to a next block now, I feel like creating musicians makes the most sense with what I have so far.

The other option is to work on the first interactions between musicians and rooms. So musicians losing energy while in a room, but getting better at a certain skill, for instance. This would naturally lead into the creative “business”-block, mentioned earlier.

I will think about it over the weekend :)

We should start a Band!

I now have the main menu system and logic for artist creation worked out :)

You can choose up to six musicians to be part of an artist. Why call it artist and not band? Well, there is also the possibility to make a solo artist, a duo, etc. The only thing an artist needs is at least one musician and a name. I’m still thinking about if they also need a dedicated artist room. I don’t know if that’s necessary, but down the line, there might be some weirdness with the logic systems, if one just creates a 1000 artists, without them actually having space or something. Also, there is the question if a musician should be able to be part of multiple groups. At the moment, the lazy part of me says “No”. Stuff probably gets convoluted, when a musician has multiple artists they are attached too, who are tasked with doing different things (like record a new album) and they try to fulfill the actions of multiple bands at once. That’s probably how a musician, who is in multiple bands, feels like :D So that decision is tabled for another day as well.

This is how it looks like (of course in big “placeholder land”) to create an artist and give those musicians their room:

Creating our Artists

I didn’t work on the project for a few days, because I had other matters to attend to. Now back at it, I am now working on creating the first menus that support the actual game loop. Before I could though, I had to create the artist lounge with several spaces in it and fix some things about the greater menu structure. One big thing was to integrate a scroll function, so that when there are too many items, the screen size would still be no issue. But you knew why scrollable windows exist already, I guess.

Anyway, now I am able to click on this new room and the menu opens to assign or create a new artist. Doesn’t look like much, but it’s the foundation of creating artists, who then in turn drive the whole game.

I also started integrating the necessary variables for the musicians and artists, to make them differ from each other in more than just their name. It seems to me like a higher amount of parameters will make the game feel more difficult (more things to be concious of), but more lively and vice verca - so I will have to balance the extent of these variables in the future.

Going Places

Things are getting more complex with the interconnection between Menus, Rooms and Musicians, but I’m very happy with my progress on getting the peeps to go where I want them to be. There are definitely a lot of weird cases, where I have to tinker around to find solutions, but for now I am happy that I managed to program the game so that the main interaction is working.

• Spaces in rooms can only be occupied by one person

• The person has the assigned room remembered (and can accordingly do different actions with / in the room)

• The person can change rooms, walking to another room when being assigned differently

• The person occupying the room will be “shooed” away, if someone else comes around to occupy that space.

The “musician list” seen on the right (that I already made a little bit prettier) is already getting quite long for the menu, so I think I have to find a way to make it contain itself to a box and that box being scrollable. That might be next :)

What's on the Menu

A lot in the game will be controlled through the menus. Hell, playing the game is mostly going through menus. The map is a neat visualisation of what’s going on and gives the whole thing charm, but in the end, the big part of the gameplay is managing your label in the UI.

Because the menus need to handle a lot of complexity and dynamic content, I can’t just work with some button-sprites and call it a day (like I did in the first MVP). Everything that doesn’t need to be a sprite (like thumbnails), shouldn’t be a sprite. That’s the only way how the menus can stay flexible for all the different scenarios.

The first control I want to get working is to assign people to a room. Like described in the last post: it’s time to give our musicians a reason to go somewhere. That reason in the simplest form is “because I told you so”. This is the first iteration of the GUI (ain’t it beautiful):

There's always a Path

So GameMaker has this nifty built-in pathfinding-function called “MP” (Motion Planning). This made building the pathfinding for my little dudes a breeze.

If you ever need someone to build a PacMan-clone - hit me up :P

Inadvertently I also created my first data leak… but I was quickly able to fix it. Always destroy your grids after using them, folks!

I think now it’s time to get deeper into the different states of the Musician state machine. The guys now know how to get to a place, but they need to stop chasing some - later non-existent - player character and start getting getting some actual reasons to go places!

The first version of this I got working. Rooms now “call” for a Musician and the nearest one answers it. As soon as they have reached the room, they change state (as seen by the sprite change to one with a yellow square):

A Game with Depth

So remember last post, when I celebrated my beautiful collision detection of different objects? Well, for now I disabled it, as it gets problematic with too many objects in a small space. Oh well, we look at it again at a later point. At least they don’t walk into walls (for the most part).

Anyway. Something in me always wants to see how we get further with the “final product” (meaning the game in isometric perspective), so I worked on the renderer. After struggling with depth-sorting for a while, I now managed to let the little guys walk around on the isometric map!

So far those cuties just wander around in a little space, but the game obviously relies a lot on them walking to a certain point and doing something (like going to the studio and recording there). So pathfinding is next!

Don't run into yourself

I am now on episode 24 of Shaun Spaldings Action RPG-series and for the first time deviated greatly from the code provided in the tutorial. What a glorious moment. And obviously, things stopped working for a while. But because I knew decently well how the code works, I was able to fix it myself! Look at these two little guys walking around and (generally) not bumping into each other!

The Beauty of Youtube

I’m now on Part 11 of Shaun Spaldings “Action RPG Tutorial” (Action RPG? You see why in the last blog post…). Shaun is a great expert at GameMaker and following their tutorial has been going great. Text boxes are working now. But as the video series is 3 years old, some of the code doesn’t work as expected when being copied over into newer versions of GameMaker. The only reason I am not ripping my hair out when running into problems is, that some people have done that (be)for(e) me. Thank God for Youtube Comments.

The internet can be the ugliest, meanest place on earth, but sometimes you’ll find places where people really are just happy to share and support each other. So while I won’t be able to thank each and everyone who helped me with this project, I am reminded to be grateful that there are so many people in this game development community (who have run into every imaginable issue before me).

Oh, and as the 2D-layer will be hidden in the final game, it can be as ugly as I want it to be.

Copy as a Base

When I was little, I saw the movie Incognito (1997). Or at least parts of it. I don’t remember the movie well (I don’t think the world of art dealership and forgery is that interesting to an 8-year-old in general), other than one scene. In this scene, the painter who forges a Rembrandt doesn’t start by looking at some old picture as a reference, but takes a photograph of his father as the basis of his painting. He basically takes a reference that has no direct relation to his project (other than it being the face of an old man and, well, some in-film-symbolism) to then paint over the bits that actually matter for it to look like a Rembrandt.

In the same vein I started programming along with the very detailed and well-explained GameMaker-51(!)-part-video series “Action RPG Tutorial” by Shaun Spalding. I don’t want this to be an Action RPG obviously, but it gives me an insight on different workings in the code. I then plan to “paint over” the bits of code that I don’t need and adapt them to my game. So there is now an animated player character, even though that won’t exist in the final game… but at least I feel like I’m getting more of a hang of GameMaker :)

So this is how some of it looks:

I disabled the isometric render-object for now, as I think it’s smarter to build the whole character-movement-logic of the game in top-down anyway and just render everything in isometric at the end of it. That seems much easier (or at least less maths-heavy) than trying to build functions (like collision) on the basis of the isometric map.

"We are each our own devil, and we make this world our hell." (Oscar Wilde)

I knew before, that designing the game with an isometric perspective would make everything a little bit harder, but I still hated that the solution to get it working needed to be something that I have difficulties with: geometry. One of the big reasons why I didn’t make the game 3D was the horrors of vectorgeometry.

I do like logic (otherwise I probably would not like programming), but I’m not a big fan of maths. That’s one of the big reasons why I studied philosophy and not some STEM-field. I had such bad grades in these kinds of areas (like geometry), that working on this part was kind of a bummer.

At least there was a video by Shaun Spalding on the topic that helped me greatly, and the code in it is in large parts the foundation of my code as well for now:

So in the end I was able to build a (still buggy) isometric map:

The introduction to isometric maps by Shaun Spaulding only shows how to produce the map, but they did some quick fixes for showing the right stuff actually in the window. For me the “viewport” didn’t work correctly (I couldn’t see all of the map) and so I did what he says in the video as the correct way to go about it, which is to program an actual camera.

This video series by Aaron Craig (Let’s Learn This Together) helped me doing this:

And sometimes ChatGPT helps as well with bug-fixing:

Learning Pixel Art

I’m not an artist, but I have worked with Photoshop and other graphical design programs for a long time. So it was more about getting the concept of pixel art and starting to try out different stuff.

These two creators really helped me starting my journey into pixel art (Brandon James Greer and Adam C. Younis):

Just for fun, here are some of my first drawings:

Starting with the Abstract

To circle back to the first post: these kinds of games are a little bit like dynamic Excel-files with a cute GUI. So I started building the excel file (the logic and data structure).

I think this is the part that I looked most forward to, as it is kind of the secret spice mix of the simulation game meal. It’s what happens under the hood. The thing that people try to reverse-engineer while playing to get better results.

I know that I kinda went overboard with this already and it will only go more extreme and complex from here. But I do think that this complexity is what makes the game special and replayable. The fun names for different bands, some cute animations and stuff like that - they’re not an endless source of fun. This logic can be. It’s the reason why you can play some management simulation games over and over again: because doing even just a few things differently in your next run, gives you a different game experience. The consequence of doing little things differently are big through this interconnection of the various data points.

Thinking about the Concept of Music Tycoon

I spent some time away in which I didn’t really built on the game, but I used it to think more in depth about the concept and the style.

When it came to the artstyle I first looked at my inspirations for the game and what I liked about them.

That’s when I decided to go for pixel art and the isometric perspective. I knew instinctively, that the isometric perspective would make things a bit harder, but I really liked the look. I also didn’t want my game to be a kinda Stardew Valley-clone, as there are too many like it in our time. Stardew Valley is still very much popular today and attracts copycats, while the other simulation games I adore - like SimCity 4 (2003) , Rollercoaster Tycoon (1999) or the Kairosoft Games -, aren’t part of the mainstream collective consciousness anymore. The first two of my examples have gotten (literal and spiritual) successors in 3D. I do like those games as well, like Frontier’s Planet Zoo (2019) & Planet Coaster (2016) or Colossal Order’s Cities: Skylines (2015), but 3D seemed daunting to me and often a lot of charm goes missing when making games like these in 3D.

For the gameplay concept I analysed some of the simulation games I liked (Rollercoaster Tycoon, The Movies, SimCity 4, Stardew Valley and Rimworld) and what connected them. I came up with the following things:

• Personalisation of a space: in all games you control some of the gameplay by building out the map / layout of a space that’s yours in the way that you want (your studio, your park, your city, your farm, etc.).

• Milestone goals: something I didn’t think alot about in my unstructured musings about my game, was the need for milestone goals. In Rollercoaster Tycoon it’s scenario goals, in The Movies it’s awards at the end of the year, in Stardew Valley you have the Community Center and in Rimworld you got the goal of leaving the planet. I feel like this is all about measurable progression. It’s not enough that your financial standing just goes up or the quality of your work becomes better: you get a hit of dopamin when you reach a specific goal. This motivates people to go from one step to the next and keep on playing.

• Potential endlessness: while there are goals (see last point), all these games can be played beyond the set goals. You can set your own goals and just keep playing.

• Juggling different tasks: I really don’t like Clicker / Idle games. They are barely games. The thing that makes simulation games engaging and let you go into Flow while playing them is, that as the game (and its difficulty) progresses, you start juggling more and more tasks and complexity. That’s the fun challenge of it. So the game can’t just be about getting more money. You need to keep different kinds of needs in balance. For SimCity it’s zones, the budget, pollution, traffic, etc. For Rimworld it’s characters moods, oncoming enemies, the expiration dates of foods, electricity, etc. There are different values that you have an influence on through your actions that you try to keep high or low, or in balance in some way. As long as you start with not that many, they can (and should) rise to a bigger number over time (-> learning curve).

• The possibility of planning: sure, you could play these games without planning your next steps, but if you do, you probably fail. Whenever I played chess, I always only focused on the next steps and didn’t really have a plan. That’s why I suck at chess. But in simulation games I have constantly a list of tasks in my head, that I want to do next. These games all have different kind of actions that you can do at any time, so that you have to make up the plan yourself as you go along. You act, and not just react (as in a lot of other games). This development and planning over time is motivated generally by some sort of progression (unlocking of new rollercoaster types, genres, building types, the next season coming up, a tech tree, or whatever)

• Automation: even in games like Stardew Valley, that are all about the zen of playing the game at your own pace, there is automation. The reason for it is, that some tasks become cumbersome after a certain point. For Stardew Valley it’s watering your crops. You start doing them manually and after a certain point in your progression you get sprinklers. In Rollercoaster Tycoon, Rimworld or SimCity, most things are automated by default: you don’t build the buildings yourself in SimCity, you just do the zoning; in Rimworld you give your people a schedule, but they walk to the tasks themselves, etc. As a manager (or tycoon), as your venture gets bigger, you want to be able to give away the smaller tasks to the program (even if that costs you some efficiency).

Then there were some aspects that were specifically charming about certain games. For The Movies it was its commentary and connection to the real world (timeline), for SimCity its great easy listening music, for Stardew Valley its fun characters and cute object sprites and for Rimworld a good pinch of randomness.

So these aspects informed me on what my game needs to include for it to “feel” the way I want it to feel (like the games that I love).

My first MVP of the Game Loop

I decided on developing the game with GameMaker, after watching some comparison videos of different engines (like Unity, Godot, etc.) like this one from Emeral:

The engine seems fit for a 2D-game and has a nice GUI. Also, the publishing for different platforms seems to be not as complicated as with other engines.

As a first protoype or MVP (minimal viable product), I wrote down the most basic form of the gameplay loop and designed the UI to control this gameplay loop in Miro. By definition, the MVP is as crude and small as possible, and you can see this in the image below.

For me this was less about testing if the concept works and more about testing GameMaker and my ability to program in it.

On the first day I managed for my game to look like this:

This must look shockingly bad or like not a lot to most people, but I was really proud about it. Not only did I manage to set up a game that actually runs (which in programming I feel like is one of the hardest parts), the money meter was able to be controlled by some buttons and the timer in the top-right corner counted up through the weeks, months and years in a logical way. Not bad for a first day’s work!

After about a week of developing this prototype on the side I was able to build my main gameplay loop in its entirety:

I even created my first data structure and was able to sort produced albums into charts:

Now again, this doesn’t seem like a lot, but it proved to me, that I was able to build a game in GameMaker. It wasn’t really fun yet, but there was logic behind it based on the quality of production, the trends of the genre that changed over time and some (I think) clever pseudo-randomization of certain values. Again: it wasn’t a fun game yet, but it was a game. And for me, that was good enough for this first MVP.

A bit of a Prologue

For many years, I was frustrated that there has never been a real stab at a music industry simulation game. The only attempts maybe were “Rock Manager” in 2002 and “Rock Star Manager” in 2022, which both aren’t deep/engaging management simulations or made an effort to show the beautiful variety of the music industry and its history in any way.

On the other hand, one of my favorite games of all time is Lionhead’s The Movies (2005) - at the current time of writing basically “abandonware” because of Lionhead Studio’s closing in 2016 -, which managed to execute on this concept for the film industry in a fantastic way. So I asked myself through the years: why is there no “The Movies” for the music industry?

But it was “Game Dev Story” by Kairosoft (1997 on PC in Japan, released on iOS in 2010) that I played again in the Summer of 2022, when I felt like there might be a way that I could be able to program something like that myself.

When looking at games like ConcernedApe’s Stardew Valley (2016) or Chris Sawyer’s Rollercoaster Tycoon (1999) - both also some favorites of mine -, you can’t but think, that these are kinda big animated excel sheets to play in (at least that’s how my friend Otto succinctly phrased it). This fact is also probably the reason why most management simulation games aren’t played by many people. You need to be wired in a certain way to enjoy Excel, I guess. But these two examples were successful with the masses AND they were developed by one person alone!

I felt like their success was based on a few factors

• The “plot” or concept of these games is one that is connected to some positively regarded daydreamesque scenario, like building your own amusement park or living on a quaint, little-bit-magical farm - this is in contrast to some other simulation games, where you automate industry lines or drive tractors (not the daydream of so many people)

• The artstyle and sound design/music is very inviting, cute and simple enough to fill in some gaps with your imagination - this is in contrast to some other simulation games that look complicated and hard to control (3D controls are still difficult to handle for a lot of casual gamers and most people don’t like a slew of numbers to understand & manage in convoluted menues)

• The learning curve is not steep - this is in contrast to something like Football Manager, where you have to understand a lot about the industry beforehand to make the game be fun

With some time on my hands in 2023, I felt like I could try to make a game in the scope of the ones described above and maybe also make more people play a management simulation game at the end of it (as a music career is dreamt about by many, the art style can be cute and the music fun and the learning curve doesn’t need to be steep to produce music in a video game). But most of all, I just want to play this (kind of) game myself :)

Before I can though, I have to conceptualize, design, write and program it (and learn how this is done on the way). This blog shows this journey!