This user leads a boring life.

Joined on January 4, 2008, 1:47 AM Visited on June 24, 2019, 12:13 PM

Unaligned posted on April 16, 2017 at 4:55 PM

project:embraced 0.03

real name for a future update
how to play and stuff

Oh god collisions So after realizing I couldn't make jump-through blocks and reading this I decided to re-write the collisions in the game by getting rid of solid block-like objects and any use of move_contact_solid.

exhibit A of collision implementation woes

Now instead of the very occasional bug where the player is stuck in a corner because of the collision box doing weird stuff I get an occasional hang that I can't replicate. It seemed to happen when a lot of bullets hit someone at the same time, but then I discovered it could also happen at random, for no apparent reason.

not even late-night eureka moments I leave for the next day for myself can save me

Anyway, if you want to take a crack at this, here's how it currently works:
collision code (Show)

Warning: sub-par code ahead

tl;dr: if the amount of distance covered due to force until the next frame exceeds the distance to the obstacle, negate the application of force and just place the entity next to the obstacle

this goes in the step event
//Horizontal Collision
var hcollide;
hcollide = instance_place(x+hspeed,y,obj_block);
if (hcollide != noone)
        //only with normal blocks
        if ((hcollide).type == 0)
                if (place_meeting(x+hspeed,y,obj_block))
                        x = round(x-hspeed)
                        while (!place_meeting(x+sign(hspeed),y,obj_block) && hspeed!=0)
                        hspeed = 0
//Vertical Collision
var vcollide;
vcollide = instance_place(x,y+vspeed,obj_block);
if (vcollide != noone)
        //normal blocks
        if ((vcollide).type == 0)
                y = round(y-vspeed)
                while (!place_meeting(x,y+sign(vspeed),obj_block) && vspeed!=0)
        //jump-through blocks
        if ((vcollide).type == 1 && vspeed > 0)
                if (!place_meeting(x,y,obj_block))
                        while (!place_meeting(x,y+sign(vspeed),obj_block) && vspeed!=0)

this one is used for just about any application of force (knockback when shooting, impact from bullet, air double jump/boost, etc.)...and while writing this I realized I haven't extended it to player inputs like walking or jumping...
///add_force(direction, speed)
//essentially motion_add, but prevents lodging entities into blocks
//declare shit
var dir, spd, vspd, hspd, blk
dir = argument0
spd = argument1
//break down into hspeed & vspeed
dir = degtorad(dir)
hspd = spd * cos(dir)
vspd = - spd * sin(dir)
//apply speeds if there's nothing to stop us
blk = instance_place(x+hspeed+hspd,y,obj_block)
if (!place_meeting(x+hspeed+hspd,y,obj_block))
        hspeed = hspeed + hspd
else if (blk!=noone)
        if (blk.type!=0) {hspeed = hspeed + hspd}
                while (!place_meeting(x+sign(hspeed+hspd),y,obj_block) && hspd!=0) {x+=sign(hspeed+hspd)}
blk = instance_place(x,y+vspeed+vspd,obj_block)
if (!place_meeting(x,y+vspeed+vspd,obj_block))
        vspeed = vspeed + vspd
else if (blk!=noone)
        if (blk.type!=0 && vspd<0) {vspeed = vspeed + vspd}
                while (!place_meeting(x,y+sign(vspeed+vspd),obj_block) && vspd!=0) {y+=sign(vspeed+vspd)}

What about that draw_line_width_color? How is this function such a resource hog? I couldn't help but play around with weapon variables and essentially flood the map with bullets. My FPS tanked hard until I reduced the length of bullet trails (that use said function).

So what's new? pussycat --The big--
No more aggressive wrist-flicking, player character moves whole arm when aiming up/down.
Gravity wells and... anti-wells I guess, check them out at dm_wells (& dm_test).
Jump-through blocks (cyan, translucent, for now). Jump downwards by aiming down and pressing jump when standing on one.
Completely re-worked the collision system, allowing for different kinds of blocks and introducing all sorts of new bugs!
Made bullets: have way better hitboxes (adjusted to size and angle), do more damage, appear bigger on screen, move faster (more knockback and less player momentum transferral as an indirect consequence, we'll see about that)
New weapon: the totally original, pink-bulleted, enemy-chasing needl-chaser!

--The small--
Explosions now not-to-intensely flash the screen - too much/little?
Weapon pickups now hover because it looks cool
"Blood" effect is now darker, so it's less distracting.
Players now have a small label on top indicating what player number they are, will allow setting custom player names/profiles in the future
Map edges draw an arrow if a player is out of the level
Default armor is 100 again, with more damaging bullets and all
Armor recharges at a higher rate
Bullet lighting is now oval-shaped, and brighter
Made quick edits on gun sprites so they're slightly more identifiable
Improved respawn choice algorithm to reduce chance of overlap, not perfect yet though
Camera only tracks dead players for a short time after dying

Download links pls Take your pick:

Unaligned posted on March 01, 2017 at 1:26 AM

Embraced 0.01

Well it's been a while, so much for this project, let's move on to the current one. Which will most likely get abandoned half-way through, more on that later, so read on!

The Abstract I made a plagiarized sprite for the hell of it and I figured that it should be accompanied by a game. I mean, taking a sprite and setting it as a custom hat on Duck Game after 5 minutes of editing so it fits the game's dimensions a sprite artist makes you, right?. That's like writing your name on a scrap of paper and decide you should become a book author. After re-purposing another abandoned project, a few days went by and I meekly posted this on the watcha doin' blog/thread/thing.

Before I continue, and as a heads up for whoever has ran into a similar issue: if eagerly trying out surfaces on GM for the first time and you're getting some "surface doesn't exist" error, throw a check in the step event and re-create it if it doesn't exist. No tutorial I'd looked up mentioned it. Ever. Pair it up with me and my gpu fiddling tendencies that stretch every possible game window to the screen size on boot and turns out that GM deletes surfaces on window re-sizing/fullscreening, causing the surface to disappear and the game to crash. It's caused my lack of will to give up on very early projects more than once.

Following are my thoughts on this whole ordeal in no particularly insightful order.

I see the light Wow, what a new world of possibilities 2D lighting brings. It's like an extra dimension of complexity I probably didn't need when designing levels. At least special effects look really pretty. I last-minute decided to use them as HP indicators on player characters. The dimmer your light is, the closer you are to death. We'll see where it takes me, since you can use any sprite as a damn light source. Spotlights, torches, lasers, lamps, explosions, flashlights... What do I even do with all these potential applications?

Oh right, what's all this about? embraced.gmx aims to be a momentum-focused 2D platform shooter. Most people can imagine what the concepts 2D, platform and shooter mean. By momentum-focused I mean fine-tuning that elusive easy-to-pick-up-yet-hard-to-master quality that all great reflex+skill-based games have by, in this case, having your bullets' speed and direction affected by your character's own speed and direction. It makes the transition from bland to brilliant if pulled off right. Think this blast from the past, but with character gravity. And you can effectively perform an air-jump by shooting at the floor with your shotgun. Or jetpack with a machinegun. Or drag someone accross the ground with your bullets by running in their direction, since your shots inherit your speed (and extra pushback force).

At its best it means being able to pull off stupid fun stunts like shooting the unexpecting foe from a very surprising angle (after all, the character can only aim up/down/left/right). I did code a currently broken style score for each player for this very purpose, someday it'll take into account things like airshots, angle, speed, fall-to-death from bullet impact, and other fun, hard to code, trigonometry-influenced, performance-killing, completely pointless variables.

At its worst it's a janky mess where no bullet goes where the player wants it to unless he/she sits perfectly still, making everyone frustrated and unhappy.

I can't say I'm very sure on how far on whichever side of the spectrum the game's currently lying.

Walk up the hill before you scale the mountain Nonsense, pseudo-deep headings aside, I thought going through getting a playable prototype out the door focused on multiplayer deathmatch would be the most sensible path. Once that's done, gather feedback, add features, refine stuff, get a really solid base on which to base an actual start-to-finish game. I want the underlying tech to feel good, I want the player to feel like they know what they're doing when shooting in apparently pointless directions, just to get a jump on the enemy, or get the health pickup, or to deny a critical path to an enemy.

Once I feel there's a reliable foundation to build upon, I'll get going with the nitty gritty story and NPCs and whathaveyou. I believe that with a game of these characteristics, engine/game feel first, everything else later, is a good strategy. (I do have *some* idea of where to push this towards in terms of setting, but let's not get ahead of ourselves) As if I'd ever typed those words before.
Besides, if it gets scrapped or abandoned, there's something to show for it, even if it's seen through "what it could've been" lens.

Camera scaling, pixels, mixels and their ilk So I set up a rather simple camera system, that scales the view depending on players' positions, makes it all scroll around nice and smoothly, but I've encountered an issue with this on a low pixel density project (and everything is scaled 2x already!)

How do I avoid annihilate weird, ugly, pixel scaling nonsense?
What magical settings in GM's view variables do I need to play with? Is that a hopeless approach and should I just upscale every sprite at 4x, or 8x? Here's what I mean. See how, despite being a really low-res sprite game, it just scales back and forth really, really smoothly with the camera zooming in and out. Yeah Duck Game again.

Gee golly! This sounds mildly enticing! How may I test this out? Right, so here's the rather rough, basic, yet completely playable prototype. If you download it and try it out (warning: ONLY potentially fun with IRL companions, each of which requiring their own input device, due to the nature of the game, be it an xbox or ps3 controller, though I've only tested with xbox controllers, so your mileage may vary, check out x360ce though) I very humbly beg of you to provide some kind of feedback regarding anything that has to due with the game. I was severely dissapointed with my impromptu QA team (some dudes I must've spent over thousands of hours playing videogames with) to not provide any input asides from "yeah it's ok".

I'd rather be severely negatively criticized into oblivion than hearing unbaked unchallenging thoughts on any subject.

The eventual, inevitable, insurmountable, project-destroying, mental roadblock This has less to do with the project and more with any kind of (creative) endeavour. I'm pretty sure I'm not the first to come to terms with or ponder the statistical inevitability of being surpassed by someone else at whatever the hell it is you're doing with your life.

I mean, even if Mr. Legit Better than Thou doesn't quite match their project's vision with yours, it'll be: (choose all that apply)
Technically superior
More fun
Sound better
Feel better to use/play/<insert verb here>
Easier to install
Appeal to target demographics better
other stuff, mostly buzzwords
Thus filling the gap you were trying to embark on yourself. Why bother at that point? I was going to initially answer it with some post-modern "taking the autheur" bs route, but I don't think it cuts it. It'll get to anyone eventually, and once it's there, how you deal with it determines the future of your project.

Just wanted to drop it there, because I believe it bears mention.

Unaligned posted on February 07, 2016 at 5:21 PM

Spear 0.04

Another week of work. I'm thinking of posting weekly updates if there's any interesting new features.

Changelog (Show)

-Added placeholder audio (bfxr-generated)
-Added placeholder 8-directional sprites for NPCs and player
-Enemies' blocking/moving away from projectiles is smarter, will only raise shields if projectile is closer than on previous frame
-Dodge timer added, default is 90 frames (1.5 seconds)
-Started fiddling with placeholder tiles to decorate rooms
-Enemy movement priority re-worked, they now sort-of follow a flowchart system (needs refinining, especially regarding walls)
-Entities will transfer momentum based on weight when colliding (e.g: currently player and NPC weight is 1, practice targets are 0.75)
-Parallax scrolling backgrounds functionality added (placeholder BGs)
-Added text outlines on hud and damage numbers (thanks LAR)
-The signposts at the tutorial area now explain things a little better

Graphics There's more colors than black/white/red! Though it's all placeholder, I can try out 8-directional sprites and parallax background scrolling, which look quite better than a black void backdrop.

Smarter dodging Instead of attempting to code this thing I realized that simply ignoring projectiles that are moving away from you was an easier approach. I should still make npcs sidestep perpendicular to the trajectory instead of moving in the opposite direction, otherwise we end up with cartoon-logic NPCs. I suppose an NPC should check both 90º movement options and see which has an obstacle the furthest.

Movement flowchart I've improved the original design. Instead of a series of if statements... now they're a series of NESTED if statements. It still needs refining but it's far more manageable than what I had earlier. Take a look at the structure if you want:
flowchart (Show)
//Does a threat exist?
        //Are there any mates in the room?
                //Are we too close to them?
                        //move away from closest mate
        //Can we see the player?
                //Are we out of stamina?
                        //move away from player
                        //move to player if too far
                        //move away from player if too close
                //Are we too close to a wall?
                        //move away from wall
                        //Are we far from the last seen player position?
                                //move to the last seen player position
As you can see it prioritizes dodging attacks above all. Now all I need is some nifty A* implementation and we're set.

Webbums I've upgraded from gif to webm since tiles make the gif files take up more space than they're worth.
webms (Show)

Enemies only move away if attacks are getting closer

Semi pseudo momentum transferal when colliding with stuff, based on weight

Naked men play with their spears

What's next -I've yet to move all of the enemies' actions onto scripts to make other enemies based on them.
-Tiling a level is slow, tedious work, I need an auto tiling algorithm.
-There's no dynamic drawing depth based on the Y position yet.
-A* implementation.
-Figuring out whether or not to move the game to a 4:3 configuration and keep the extra space for the HUD, since it's not that great that you have a higher horizontal view than vertical.
-Probably more, but let's not get ahead of ourselves.

The download Right here.
If you've made it here, thanks for your time.

question for mods (Show)

Is it okay if I post weekly updates and hide the previous post from the frontpage and activity feed? I don't mean to get up on the frontpage but I'd prefer if the comments were for each build version. I can just list it on the activity feed if it seems spammy.