Oh god there's so much math involved
Getting the hang of the program now and I've learned a few things in coding which is always good.
Also if anyone is doing pixel art and looking for a good free program check out
Graphics Gale
This is a great little pixel art program and art from it can be imported into Game Maker easy.
You can just try using the background as an instance instead of a background. Sure you'll have to do the tiling in a paint program instead of using game maker but it's the easiest way to get the desired function.
Seems like this thread would be the best place to go for some GameMaker help, of which I need some!
I'm currently trying to create a game that contains 37 instances of the same objects, and every three seconds, I'd like one to be destroyed at random. Essentially, that's all I'm trying to do right now.
However, GML is new to me so I'm having trouble getting any of the instances destroyed at all! Could anyone advise me?
with(list_item){
instance_destroy();
}
Seems like this thread would be the best place to go for some GameMaker help, of which I need some!
I'm currently trying to create a game that contains 37 instances of the same objects, and every three seconds, I'd like one to be destroyed at random. Essentially, that's all I'm trying to do right now.
However, GML is new to me so I'm having trouble getting any of the instances destroyed at all! Could anyone advise me?
SpawnThirtySevenObjects = false
DestroyCount = 37
// Spawn 37 objects and give them all a unique name that the game can 'find'.
if SpawnThirtySevenObjects = false
{
globalvar "First" = instance_create(x,y,object_name)
globalvar "Second" = instance_create(x,y,object_name)
[type all the rest...]
globalvar "ThirtySeventh" = instance_create(x,y,object_name)
SpawnThirtySevenObjects = true
}
// Create a three second timer. Every 3 seconds it randomly chooses one of the 37 objects, then destroys it.
SecondsBetweenDestroy = 3
SecondsSinceLastDestroy = SecondsSinceLastDestroy + 1/room_speed
if SecondsSinceLastDestroy >= SecondsBetweenDestroy
and DestroyCount < 37
with choose("First","Second",[type all the rest...],"ThirtySeventh")
{
instance_destroy()
DestroyCount = DestroyCount + 1
}
Seems like this thread would be the best place to go for some GameMaker help, of which I need some!
I'm currently trying to create a game that contains 37 instances of the same objects, and every three seconds, I'd like one to be destroyed at random. Essentially, that's all I'm trying to do right now.
However, GML is new to me so I'm having trouble getting any of the instances destroyed at all! Could anyone advise me?
/// Initialize the Variables
instance_cnt = 37; // How many do you want?
destroy = 0; // This is used to determine which object will be destroyed
instance_list = ds_list_create() // Creates the list
timer_length= 90; // at 30 fps this is 3 seconds
for(var i = 1; i < instance_cnt; i++){ // Start at 1 to end up with 37, loop through until we reach 37
ds_list_add(instance_list, instance_create(random(room_width), random(room_height), obj_instance)); // Adds an object to the room, and to the list at the same time.
}
alarm[0] = timer_length; // Sets the alarm to the time you set earlier
/// The Every 3 Second Code
destroy = irandom(ds_list_size(instance_list)-1) //generates a random integer 0 - however big the list is.
with(ds_list_find_value(instance_list, destroy)){ //In order to destroy an object that isn't the one you are coding for, you need to use "with()", this will tell gamemaker that we are coding for the instance at destroy's position on instance_list
instance_destroy();
}
ds_list_delete(instance_list, destroy); // Remove the position from the list so it won't come up again and cause errors.
alarm[0] = timer_length; // reset the timer.
snip
This would unfortunately not work because there is no way to remove instances from choose, and that would cause a crash.
I think this looks awesome! It has this adorable creepiness to it. But I would recommend, instead of blowing up all of your sprites, keep them 16x16 and use a view for your room in gamemaker. Make sure you turn off interpolate colors in the global settings for your game, and it'll look much better.Anyone care to recommend your own (or a more newbie-friendly) workflow for getting sprites up and running?
I typed up a bunch of base system code today, but it was giving me a headache at times - math overdose, etc. So in between that I was fiddling in various paint programs (MSPaint, Paint.net and GIMP) dicking around with a single zombie sprite and trying to figure out a walking animation. It was fun but I just couldn't find any smooth, sane process for drawing the sprites, testing them in motion or on top of one another and then importing them. I ended up just drawing them next to each other in Paint.net and then laboriously select-box, copy-pasting them one by one into GM and having to manually add transparency. Ballache. I was playing with GraphicsGale also, but I'm definitely missing something simple and important with that program -- I found it maddeningly unintuitive, especially flicking around frames without them overlapping.
Anyway, for progress purposes, here's what I ended up with. For what is pretty plainly awful, awful animating, this little zombie's strut ended up having a certain Vince McMahon-esque charm. I was trying to get it to fit the isometric direction he'll be walking, so like from north-east toward south-west, hence why the legs are flailing about all over the place. Drew it in 16x16 and then scaled it up to 96x96.
Oh god there's so much math involved
First mock-up. I wanna do sort of a horror "walking simulator" with sort of a Lone Survivor vibe.
I cannot say enough pleasant things about Tom Francis's tutorial. I think it's a case of his teaching style (and he's obviously a capable teacher) clicking with my learning style. The stuff he was saying and doing really cemented quickly, it was great. It was very liberating to suddenly realise that I was taking the stuff he'd been specifically working on and then reappropriating it on a fundamental level into my own very different test project, especially as someone with only a tiny, teeny amount of coding experience under my belt prior.After watching the first 8 of Tom Francis' videos this last week I started putting together a basic concept, he does a great job explaining exactly why he's doing what he's doing in the early videos.
So far I want to do some sort of adventure-ish game set in a subway with a lot of interactable objects.
First mock-up. I wanna do sort of a horror "walking simulator" with sort of a Lone Survivor vibe.
I have an idea how I want it to look and feel, but I don't know if it's gonna be scary or interesting, so we'll see.
If that fails, I'm gonna do the most boring Candy Clicker in the universe.
Best of luck to everyone!
I'm trying to use draw_sprite() functions to handle shadows.
The way it is working currently uses two draw functions in a regular Draw event:
line 1 -- draw_sprite(shadow)
line 2 -- draw_self()
Drawing in this order ensures that the shadow is always behind the actor.
I'm a little worried though that I'm going to eventually run into problems with the shadow sprite's 'depth' later on when I have walls and suchlike. I'm not aware of any way to adjust a sprite's depth value through code in the Draw event.
I was hoping that I could avoid such issues if I put the shadow's sprite in the DrawBegin event and have the actor's sprite in the normal Draw event. My understanding is that DrawBegin stuff happens before all the objects, ensuring that shadows would always be drawn 'underneath' walls or whatever.
I can't seem to get this to work though, and I can't for the life of me figure out why. If I put my draw_sprite(shadow) code in a DrawBegin event, and the draw-self() in regular Draw event, the shadow's sprite doesn't show up in game. I assume DrawBegin sprites should still be visible on top of the background.
Any ideas why? I must be misunderstanding something basic about this Draw process.
===========================================================================
EDIT: rather than doublepost --
Put up a short, shitty-quality Youtube of my progress so far.
- Movement along the axes is mostly working.
- Got the 2 projectile types working.
- Player health decreases visually on the screen (the cats), with player death after ten hits.
- Altitude is nearly implemented; shots and collision are somewhat functional. But, as above, I still haven't figured out a solution to neatly handling depth. You can see my high-flying witch being drawn behind zombies on the ground.
- Figured out a promising way for flying enemies to oscillate as they scroll with the background and keep their shadows in place. This drove me bonkers.
CLICKY
The DrawBegin event unfortunately doesn't work that way, If you you put stuff in the DrawBegin event, everything, background, sprites, tiles included will be drawn over it.
Insolitus said:If you want the shadow to appear under the characters and have the player's depth be separate you're most likely going to have to have them be separate objects with shadow following the player XY coordinates but not their altitude.
Insolitus said:The only other thing you could do is put all the characters and shadows into one object's draw event and execute them in a certain order, but that would probably be more effort than what it's worth for a small project.
I realized I can probably use this time working on my regular GM project than the halloween competition so I'll just provide GML help.
In regards to the shadow stuff, dunno if this will work, just off the top of my head.
line 1 - draw_sprite(shadow)
with (shadow)
{
depth = whatever number you want
}
line 2 - draw_self
Kinda don't have the means to test this atm so no clue if it's actually valid lol.
Try putting the depth in the create events
I don't think that would work as code in Create only fires once, when the object is created, or at least I thought. Any working solution to this depth situation has to be able to adjust the object's (or just sprite's) depth value based on position within the room comparitive to other objects.
Like for a regular isometric game, one where objects are always walking around on the floor, you can just specify 'depth = -y' and any object drawn closer to the top of the screen will be behind any object lower down, as you'd expect in an iso perspective. Having iso + altitude however makes it a bit trickier.
I could have two objects, actor and shadow, and have the actor's depth be controlled in the shadow object's code, something with the form of 'depth.actor = self.y * -1', meaning the actor would take a depth value based on the shadow's y-position, but that comes back to a solution whereby I'm using two separate objects for actor and shadow, which I'm trying to avoid because it causes the laggy x-position update between the two at high changes in hspeed.
The somewhat 'fix' I'm using as of this afternoon is to draw the shadow sprites on the screen in a Draw Event, and the actor sprites in a Draw End event. This keeps the shadows always locked on top of the background and the actors always above.
Tomorrow I'm going to code up some walls though (objects that the Witch and flying enemies can go 'over') and place them into the game and find out if there's anyway to make the shadows draw above them, or crowbar some extra 'fake' shadow sprite to pop on screen when the default shadow is drawn below the wall.