Dev Log Entry 11: Not always a success

This is a dev log about creating a game called Newtius in GameMaker Studio 2 (Indie edition). Starting with entry one might make this easier to follow.

In entry 10, I really went through cameras and viewports with some actual code and implemented it (albeit on a practice project instead of Newtius itself).

In this post I’m going to explain a minor setback, speculate on a cause and go into a side thing I’ve started in the form of a Udemy course.

As always, the Official newtius project page on itch.io is up, featuring the last playable version.

Layer not layer

I actually worked on Newtius recently: I wanted to do something as simple as adding a static starfield background, the twist being I wanted do it entirely through code. There is a simple interface in GMS2 for adding a static background. Like a button that says “choose a background sprite” where I just choose a sprite. Slightly easier than trying to use the functions to accomplish the same thing.

The issue is no matter what I did via GML code the sprite specified never shows up as the background. The background only shows up as solid black. No matter what.

I’m conflicted on posting the code since I couldn’t get it to work although I think I have a theory on why it may not have worked.

Firstly, I put the various layer related functions in this “obj_spawner” object I have in my game room. I don’t know if that is right place to place it. There is a way to associate code specifically with a room. I should probably put it there.

Here is an example of the functions I tried in particular order, if someone wanted to look them up in the documentation:

// (this didn't work for me)
	instance_activate_all();
    //layer_depth(back_id, -300);

	var ycordbg = layer_get_y(lay_id);
	show_message("y coordinate of lay_id is " + string(ycordbg) );
	layer_x(lay_id , 0);
	layer_y(lay_id , 0);
    layer_background_sprite(lay_id , spr_background);
	layer_background_htiled(lay_id , true);
	layer_background_vtiled(lay_id , true);
	instance_activate_layer(lay_id );
    layer_set_visible(lay_id , true);

But again, none of this worked. Actually I got quite frustrated with this and ended up stopping GMS2 entirely and playing a game for several hours instead.

At the end of it I did simply select a sprite using the GMS2 UI and apply it and it worked without any problem.

Since that brief “progress” on Newtius, I decided to start following a Udemy course I apparently purchased and forgot about. It mentioned using a draw event would blank out the window until a draw sprite function was specifically used. I’m not sure if I knew that and already forgot it or if I am just learning this.

So it could be my draw event isn’t implemented correctly and that is what is blanking out the window. Or it could be I’m missing something entirely. If it was the draw event why would it not just do the same thing whether through the UI or through code?

As for the rest of what I’m doing I think I’m going to keep going on the Udemy course rather than the space mods playlist at least for a little while.

A little brainstorming

Every so often I like to do stream-of-consciousness sorts of exercises to try and help myself decide on a direction and come to a decision. And also pretend literally anyone any place will find it remotely interesting to read.

When I was working on Newtius and got the new enemy type to spawn, I felt like I was coming to something of a turning point in my progress. A hypothetical turning point in that I have no idea if I would capable of doing it.

I actually tried to figure how to turn on both kinds of enemies. The original ones that are just orange circles that spawn infinitely, have 3 hit points and fly towards the ship and the new ones I finally got to spawn the way I wanted so there’s only five and spaced the right amount apart.

Well I didn’t actually figure out how to put them both in the game at once and I don’t think that would have accomplished anything anyway since I would have re-implement how enemies spawn almost immediately. I’d have more of a milestone I could put up on itch.io perhaps, but mostly I wouldn’t really have anything.

So this leads to an interesting question: how am I going to implement triggering enemy spawns Well I don’t really know enough yet to even speculate on that. But for instance do I have one controller object that spawns enemies at key points? Or do I implement one controller object per enemy type? Which would make it easier to debug?

Theoretically I could drag-and-drop controller objects for individual enemy types, trying different combinations to find “edge cases”. I could also have the one controller object that spawns enemies and merely commenting out a line takes that enemy type out.

There would also be the question of timing.

Basically the way a horizontal shmup like Gradius works is that there a “room” of a specific length and height. I mean a normal room, like the “room” Asteroids, Space Invaders or Pac-Man takes place in. That room is just there and it’s the background that is scrolling by, giving the illusion that the player ship is moving through a world or map. So the ship stays where it is and the background moves.

So, do I have invisible barriers in the form of vertical lines that the player passes – or more accurately the camera passes – that spawn in the new enemy types and events? Maybe just the camera passing a specific location of the background would trigger in the enemies, get them queued and send them in at the right moment.

I assume whatever I implement I will have to re-re-re-implement anyway so I probably shouldn’t worry about it.

Okay, I think the random brainstorm is over.

By the way the Udemy course I started centers around building a shmup. I don’t know yet exactly what’s going to look like at the end but it’s still kind of interesting.

GML Approach to controls

I may as well expand out this post into one of the things I’m just getting started with.

It could be because I started out with those tutorials using the drag-and-drop interface of GMS2, but I think I really prefer just using the “Key Down” event for each individual key. So far I’ve only needed the four keys for movement anyway (the enter key to start a game and one time Escape to quit but mostly the directions) and the method of implementing key presses pictured here seems to work really well and to me at least is much, much easier to read.

And yet all the tutorials I’ve gone through that use GML instead of the drag-and-drop UI seem to implement these four control keys in one big script under the step event. This still seems odd to me. And like it would be harder to read.

I did try briefly to implement what the guy in the Udemy course was doing but with the above individual key down events instead but…I couldn’t do it. The Udemy instructor was using the values from the key presses to implement a direction and tie that into a momentum/physics implementation to make the ship go faster the longer it went in that direction and slow when releasing the key. Well there’s just the one direction anyway – to the right – but since I’m not even half way done with the course I’m just assuming this will make sense later.

I wasn’t going to put in this sort of faster-and-faster physics into Newtius anyway. And since I already wasted enough time on it I’m just going to do it the way this Udemy instruction is doing it so I can accurately follow along.

// player object/step event
// these loops run 60 times a second
// seems like a waste some how
if keyboard_check_direct(ord("W")) {
	// shipSpeed defined in create
	// up
	y -= shipSpeed;
}
if keyboard_check_direct(ord("S")) {
	// shipSpeed defined in create
	// down
	y += shipSpeed;
}
if keyboard_check_direct(ord("A")) {
	// shipSpeed defined in create
	// left
	x -= shipSpeed;
}
if keyboard_check_direct(ord("D")) {
	// shipSpeed defined in create
	// right
	x += shipSpeed;
}

I haven’t decided if I’ll go into the physics based extras yet. I might skip it. Have to save that for the next post.

Paths are good

I also looked into paths to see if they were what I thought they were. And they are: an implemented way of sending an object to a series of coordinates either through coding or through a visual editor.

I was thinking of that first enemy type in Gradius. How a series of enemies comes in from the right, follows a specific path and if left alone exits off screen back to the right.

As the documentation points out this can also be accomplished through an array of coordinates. But the paths are already thing a for that functionality so why not use it. Well I haven’t actually tried implementing it yet. This would be one of those things I did entirely through looking at the documentation, not by following someone else’s step-by-step guide.

Reference links:

• GML Manual: Paths
• GML Manual: generically all-about-layers
• GML Manual: About background layers specifically
• The Udemy course I kept mentioning

The latest version/progress of Newtius can always be found at my GitHub repo:
https://github.com/tildesarecool/newtius