This user leads a boring life.

Joined on January 4, 2008, 1:47 AM Visited on February 21, 2019, 8:31 PM

Unaligned posted on January 19, 2019 at 6:47 PM

Nuclear Moss

[left]Yet another project with a temporary title. I'm seeing a pattern here.[/left]
[left]Man, site's slow as of late (I mean slower than usual slow). I guess everyone's funposting over at the discord server huh?[/left]
[left]So what's been up with me? Not much. I decided to get off my ass about a year ago and started exercising daily. Health benefits (great btw) aside, it gave me a lot of time to think. I came up with an idea for a world to set a game in. It slowly grew in my mind with each passing day; and although very little (if any of it) made it onto the project, I probably wouldn't have started it had I not started to dedicate 1-2 hours a day to introspection (I now mostly listen to podcasts when I'm out and about).[/left]
[left]So about six months of work later (admittedly, very on-and-off as far as keeping a consistent work schedule goes, motivation is extremely hard to come by it seems) I present to you the temporarily-named project Nuclear Moss.[/left]

  • I wanted to make something past-paced, where you pummel through a bunch of enemies in a split second. Who doesn't love some good power fantasy?
  • Good players are rewarded through the game's combo meter: the style counter. It both acts as a score and damage multiplier (at different rates though). You'll still have a decent damage output even after taking a hit (or three).
  • There's a handful of playable characters, each with their own stats, main attack, special attack and passive. I'm willing to bet that it's rather unbalanced at the moment, but I can always say that the game has an implicit difficulty selection system by which character you want to play as. Want to beat the extra challenge level that's filled with projectile-spamming enemies? Well then just pick the character that can reflect them!
  • For lack of a better term, I wanted to upload a vertical slice type demo, which is a representative fraction of the full game's experience. This means there are levels to beat, characters and game modes to unlock. And of course a final boss.
  • Speaking of which, I must admit I enjoyed testing of the boss far more than mowing down hordes of enemies. I'm considering shifting focus and giving bosses more attention than standard enemies.
[left]Any of this sound fun? I'm literally, figuratively starving for feedback, as I don't really have anyone around me that could provide any insight, (aside from myself) and having spent all this time on the project in a vacuum might've affected my perspective.[/left]

Keep it frosty

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.