• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
  • Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Ideal location of 'dungeon creating' script?

L

ladlon

Guest
Hi. I'm creating a game in which the playfield is randomly generated, so I have a bunch of code placing random walls, building things, placing treasures, etc.

Currently, I have the code contained within a (persistant) object created for the sole task of holding the 'setup' script.

Is this the proper method? I'm not sure what else I would attach it to. The player controls would be kept in the player object... the enemy behavior in the enemy object... but, I'm not familiar with a 'root' area for general code (building the level, etc).

Of the info I've seen so far, it SEEMS I should be storing it in a persistant custom object made for that sole purpose... so that's what I am doing currently.

Technically, the script only needs to run at the start of the game (build the level), but after that (during the game) nothing there is needed (...at least until a new level is required). So, am I doing this the best way currently?
 
If it works perfectly and isn't lagging the game a significant amount due to glitches, it's ideal. You're thinking too much about optimization. At the point in development you seem to be at, coming up with more working code is much more important than thinking about rewriting already working code.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
The use of "controller" objects is very much considered the norm... There are just some things that can't be done in individual objects , like a HUD, or scoring, or - as you are doing - level generation. The only thing that I wouldn't do is make the object persistent, and instead simply have it created in the room and then destroy itself when it's finished, but if you think you're going to use it for other stuff, like stat tracking or the previously mentioned HUD and score then persistent is fine too.
 
L

ladlon

Guest
Hi, guys. Yes, certainly at this point, I'm no where even remotely near straining the system. Besides, it's a 'setup' procedure, not during the game... so optimization is not as critical. But, still, I figure why develop bad habits this early in my learning?

Interesting point you bring up, Nocturne. I'm not entirely sure why they suggested the controller object be persistent. I have to look into that. Good idea to destroy itself once done, as I was worried that it somehow might strain the main loop of the actual gameplay, just by existing.

I'm very early in my learning of GMS (...I used to do games in BASIC and ActionScript, so this is... more or less... my first true dive into GMS).... so, there's a healthy amount of optimization/proper procedure paranoia... simply due to me not knowing for sure about proper procedures.

Okay, as long as the concept didn't trigger repulsion from experienced users, I'll continue on with it (although I'll take your self-destruct suggestion). Just wanted to be sure I wasn't starting off on the wrong foot.

Thanks!
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Note that there is nothing intrinsically wrong with using a persistent object, and indeed for a few things it's required.... and having a single instance in your room doing nothing won't cause ANY major overhead in 99.99999999% of the cases. The only reason I suggest to create/destroy it as required is because it keeps things "clean" and I personally prefer to keep persistent objects to a minimum - ie: only for tracking statistics and achievements and/or gamepad controllers.
 
L

ladlon

Guest
Noted, thanks!

Followup question... I'm putting the 'room creation' code in that dedicated object... but I wasn't sure if it should be residing in the 'Creation Code' area, or attached by some other method.

Am I right to be clicking the Creation Code button and entering all my 'room creation' coding there?

Am I also okay/right in setting global variables there? I'm just using 'var x=100;' type of coding, and assuming that they will be accessible wherever I need it from.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Am I right to be clicking the Creation Code button and entering all my 'room creation' coding there?
Are you talking about the "Create Event" of the object? If so then yes, that's ideal. The Create event happens the exact moment an instance is created so anything like ou are doing is fine to go there (other events, like Room Start, for example, actually happen AFTER the create event).

Am I also okay/right in setting global variables there? I'm just using 'var x=100;' type of coding, and assuming that they will be accessible wherever I need it from.
My own advice is to create a script for global variables and call it once at the very start of the game. Normally you'll have a splash screen or an intro room or something like that, so you can call it in the Game Start event of an object in the very first room of the game. This way the global vars will be initialised once and once only. Having them in a script also means that they are easy to find and edit and add to, since you don't need top go searching through your objects and events to find them and it keeps them all in one place.
 
L

ladlon

Guest
Hi. Well, I'm not sure, exactly... as I'm still rusty on the various methodology.

Actually, I was wrong about the object holding the code. I do have an object solely for code, but it's not the one I have the level creation/variable initializing in. My mistake!

The level creation and variable initializing is actually in the main Room item. On the Room's control planel (Room Editor), there is a Creation Code button, which I press to then go to a code editor, which is where I have the var statements, array creation, and the entire level generation/drawing code.

I guess this is different than the script method you are suggesting. I have to familiarize myself with that. I've known of the concept for years, but never really used scripts (both in GMS nor ActionScript)... so, it's a little bit of unfamiliar territory that I have to get familiar with. I get it, though... Call the script, passing some values, and then return the values.

So, would that script method be better than the code in the Creation Code area? Would the call to the script be done in that Creation Code area, and the content of the script itself would be created/edited via the Script item in the asset list (Create New Script)?

BTW, thanks for your very helpful answers. Very much appreciated!
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Well, it all depends on what you want to do... The room creation code runs AFTER the create events of instances in the room, so if any instance relies on the code room creation then you could get errors. See: https://docs2.yoyogames.com/index.html?page=source/_build/2_interface/1_editors/events/index.html

If the room creation code is what is creating all the room instances, or no instances use the code in the room creation then you're fine. Note that, again personal opinion, I really don't like using the room creation code as it's easy to forget and harder to maintain as every time you need to edit something you have to open a room to do it. This is why I use scripts for things like that, as you can place the script anywhere and then edit it easily without having to go looking for where you placed it. :p BUT there is no "correct" way to use these things... the beauty of GMS is that it gives you lots of ways to achieve the same ends, so just go with what works for you.
 

Pfap

Member
Well, it all depends on what you want to do... The room creation code runs AFTER the create events of instances in the room, so if any instance relies on the code room creation then you could get errors. See: https://docs2.yoyogames.com/index.html?page=source/_build/2_interface/1_editors/events/index.html

If the room creation code is what is creating all the room instances, or no instances use the code in the room creation then you're fine. Note that, again personal opinion, I really don't like using the room creation code as it's easy to forget and harder to maintain as every time you need to edit something you have to open a room to do it. This is why I use scripts for things like that, as you can place the script anywhere and then edit it easily without having to go looking for where you placed it. :p BUT there is no "correct" way to use these things... the beauty of GMS is that it gives you lots of ways to achieve the same ends, so just go with what works for you.

Also, the uglity…


Edit:
As opposed to the beauty of GMS... there are also many ugly parts.
 
L

ladlon

Guest
Ya, I have to really look into that....as I really don't know if it'll be an issue or not. Still not fully clear on the whole 'after Create events', etc.

I've kind of restarted 2-3 times now, as I have re-invented my 'dungeon build' algorithms... but then ultimately discovered some minor aspect that presented a problem. Some quasi-heavy math/concepts that are making my head hurt. I keep doing this to myself!
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I've kind of restarted 2-3 times now, as I have re-invented my 'dungeon build' algorithms... but then ultimately discovered some minor aspect that presented a problem. Some quasi-heavy math/concepts that are making my head hurt. I keep doing this to myself!
Lol! Don't worry... we all do it! Refactoring code is a major part of game development. In most of my projects I go back and re-write whole chunks just about every time I open GMS2... It's 90% iteration and 10% innovation most of the time.
 
L

ladlon

Guest
For sure! I'm not mathematical, generally speaking, but I find I keep inventing game concepts that literally have me sitting with pen and paper, almost in physical pain trying to visualize/set to logical code them.... mostly random dungeon creation or storage of that dungeon. Countless sheets of graph paper covered in cryptic 'process visualizing' sketches! Granted, I always go 'ambitious' in any project I do (not just coding).

Hey, Nocturne... I posted a few other questions in this forum, but they haven't received any love from anyone yet. Any chance you could take a peek at them and give me a response? The 'subdivide' one is not as important now... kind of cryptic, so it's hard to understand, anyway!
 
Top