GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Glue Gun Glen Page 1, 2, 3, 4, 5, 6  Next
View previous topic :: View next topic  
Author Message
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Sun Jul 30, 2017 2:32 pm    Post subject: Development Log - Glue Gun Glen Reply with quote

early access link

So far this is closer to a programming exercise than any kind of game. I'm going to periodically update the early access site as I continue development, assuming I do so of course. I have a couple of core mechanics working in simple fashion, but not all rules are in place so it's easy to break. The current plan is for the player to be able to push blocks, but I'm undecided if that should mean "push one block at a time" or "push a whole stack of blocks as long as there is room." There is also to be a color matching element, most likely in the form of "when same color blocks collide, they disappear" and then clear the entire level to win. I have also considered coins/gems that the player must collect, among other potential additions.

Feedback on visibility and color friendliness is welcome, obviously nothing here is remotely final. Background color sucks? Grid cells too closer together, whatever? Let me know, even better if you might suggest some hex codes or other values to experiment with.


Edited by Diablo on Wed Sep 06, 2017 11:40 am; edited 2 times
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9442
Location: Not Finland
PostPosted: Mon Jul 31, 2017 5:07 am    Post subject: Reply with quote

Looks clean, and runs well in Firefox (Win 64).

Will you have an option to scale the grid display, or is the display a fixed size in pixels?
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Mon Jul 31, 2017 5:54 am    Post subject: Reply with quote

Sirocco wrote:
Will you have an option to scale the grid display, or is the display a fixed size in pixels?


So far it's a fixed size, because I have the png files for the tiles at 36x36 and hard-coded cell margins. I'd like to assume that the default browser zoom behaviors could handle scaling needs, although... now I'm nervous that browser zoom could destroy my rendering and collision assumptions of fixed size cells? (Checking) Works ok so far in chrome, though there's a practical limit to how far in you can zoom, the level will stop fitting on the screen, particularly if it rotates.

Fitting on screen is part of the reason I'm currently planning to omit screen wrap for once, maybe everything I program doesn't actually need it. It'd also be annoying to program -- I'd have to spawn a second div, add some cropping css to both ends, remove the second div after completion of wrap, etc. -- but that has absolutely no role in my decision, none at all.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Mon Jul 31, 2017 4:49 pm    Post subject: Reply with quote

Early access users, you have received another free update. We know many bugs remain, and the game is not quite finished, but together we will build this game and also please consider upgrading to the Supreme Master edition today for [price redacted].

I don't think I've added new core mechanics yet, though I have been working on a todo file that has some interesting ideas. The graphics look a little different, just slightly larger tile sizes, but also scrapped the pixel "art" and used some stripes and gradients and stuff. (Except the player object, so far that didn't change.) When I first switched it up I was doing the stripes via pure css, but apparently the performance of repeating linear gradients combined with rotation transformations on the game container had a negative impact on performance. So, I just threw them into pngs and had done with it, it's all the same to me.

Objects now twirl a bit as they fall, and I added proper "motion" to the player -- instead of teleporting from cell to cell, he takes his time, and he also does a little jump on the way, for style only. I found this a mildly interesting problem, whereby I used this site (https://www.desmos.com/calculator/htfdxbgqdt) to help me generate an appropriate jump arc equation. You can also now push the blocks, just one at a time (so you can't push side-by-side stacks), I'm thinking at this point that's the route I'll stay on for push block rules.

Most annoying current bug for me is the inconsistent / glitchy rendering of the red colored blocks. They do rotate, but if you push them, their rotation switches back to a different value when it lands on the next side. It's because I've just kind of hacked in some "rotate here" values basically according to gravity, so once the pushing process ends gravity steals control back. Similar case applies to rotating the map, because then gravity is on another axis, so the "divide by some hard-coded value" result changes and thus there's a startling "now I"m rotated like this" effect.

I'm more intrigued by the prospects of working on this today than yesterday. This is good news, it means the money early access members have already paid, it might just amount to something one day!

Edit - If page looks the same as before, try hard reload
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Tue Aug 01, 2017 5:17 pm    Post subject: Reply with quote

The latest update to early access introduces new core mechanics of climbing up single-tile ledges and an early version of the jump pad .

The climbing works like this, if you walk into a wall (or a colored block you can't move), then you automatically climb on top of it. This was simple enough in theory, but when I decided to add in a climbing animation so that the square would do something like a cartwheel to get up there, it got harder. Not just because of the rotation logic, but because the level itself can rotate, then you have 8 different rendering scenarios, like "climb left while gravity is this way" and "climb right when gravity is upside down" which is actually clmibing left and under a tile, etc. In the end my solution devolved into picking random 90-degree increments and adding them into the calculation, a very unscientific matter of trial and error, but now it all renders properly!

The jump pad is a new idea I had. You step on the jump pad, and it launches you up to another location. Animating this required a few more visits to that parabola building website, as I conferred and debugged with it, trying to figure everything out. There's a lot more work left to do on the jump pads, such as a visible indicator of the destination -- and this is an interesting problem, because I don't think I can render a parabola with raw css, and I think I'm going to try to prerender all possible parabolae via a python script I've already prototyped, which will save them as pngs for on level load. Collision detection is another thing to consider, for what if there are a couple of colored blocks in the path of the jump parabola? So, my current (cheating, but at the same time surely perfectly valid) solution is to ignore collision altogether on the way, like you're in a 3rd dimension where you don't have to worry about it. However, even with that generous logic, I have to consider what to do if an object is already occupying the final destination. Early belief is that I'll not allow jump pad to be used if landing zone is not clear, maybe put a circle with a line through it over the jump pad until the landing zone is cleared.

When I had the jump pad idea, I tried to draw a picture of a rocket. I googled for "rocket icon" and tried to base my drawing off of it, in my paint program. Well, what I drew looked more like a sword than a rocket, and it did not look like a very good sword either. At that point I had a revelation: the rocket icons I am looking at, they are free icons and I can just use them! Thus, there is some minor changes to the visuals again.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Tue Aug 01, 2017 8:17 pm    Post subject: Reply with quote

I got the prerender concept working. It's a good start, here's the images I render via a dirty pygame script:



I just store the vector in the filename itself, then when a jumppad is created with a given jump vector, I load in the image and create an overlay widget on the game. In this end, you get this on the screen:



The pygame script also runs an imagemagick child process to make the black background transparent, but I disabled that for demonstration purposes here.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Wed Aug 02, 2017 7:39 am    Post subject: Reply with quote

The next step is to add a recharge timer property to the jump pads, when you activate it you then must wait [x seconds] before you can use it again. This is actually a welcome addition in some scenarios, and it can make for additional puzzle elements -- perhaps a jump pad that leads into a pit of spikes?, but you use another block to activate it first, then safely walk across during the recharge period.

I obviously wanted to visually indicate the recharge / cooldown status, and I wanted a "clock" thing, like I've seen in Diablo 3 and probably many other games, where the icon is dimmed / greyed out completely, then slowly is brought back to full brightness in a 360 degree circle. I wasted a little bit of time exploring a pure css solution, which I do think would be technically possible (even if it would require 8 separate divs to do so, as best as I can tell -- can't create triangle with > 45 degree angle? not positive though), and then figured a spritesheet was the best way to go, so I have something like this now



When jumppad is recharging, it just calculates the current angle (recharge percent / 360) and uses that index value to find the appropriate column,row in the spritesheet to render on top of the jumppad, with a 50% opacity so it just dims it. I think it looks pretty good. Not live right now.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Wed Aug 02, 2017 5:27 pm    Post subject: Reply with quote

I hope the jump pads take off, because programming them has been a bit of work! At last though, I have settled both the preview path rendering as well as the actual game logic (so the jump pads actually work) for all map rotations. I started with the simple "no rotation" jump pad, and it worked nicely. Then instead of rewriting all of that logic for every rotation, instead I pushed the code into a helper function. If the map is rotated, I un-rotate the various coordinates and pretend that everything is back on the origin non-rotated axis. Then I do the calculations, and I take the output and re-rotate it so that it properly translates to the current rotation position of the level. It's crazy.

Rendering the previews took longer than I had guessed, partly just because I had to think about the basic math. I reuse parabola whenever possible, so if there's a parabola in no-rotation that goes up and to the right, and then one that goes up and to the right after a 90 degree turn -- well even though the second one initially renders sideways on the screen, it'd be too much of a waste to create a second prerender just to rotate the same parabola. This is all square now, and I added a couple early helping features like "move the mouse over jump pad to see all possible paths." It's of course possible that all 4 parabolas will have different paths, even though current testing level does not do this.

Not certain where I am going next, but I think fairly soon I should start on the color matching aspect, adding separate colors and removing them upon match.

Current testing level is just a jump pad that works for every direction. early access link
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Fri Aug 04, 2017 9:12 am    Post subject: Reply with quote

I've been thinking about the concept of gravity in what is, to some extent at least, a push push game. Most of these games are non-gravity based, which gives you pretty good freedom for moving pieces around for whatever the goal of the game is. But with gravity of course you can only push them sideways. At the same time, this game has the map rotating, so you can change that gravity and move the blocks to new places in that way. But still, despite this, I wondered about trying to have both options.

I thought about how I might allow player to enable or disable gravity. I don't think it would be very logical to allow it to happen at any time, because then there's no point to any platforming challenges -- you can just turn off gravity, move wherever, and turn it back on. I thought about collecable gravity tokens, or limited time zero gravity, etc. etc., it didn't really sound right. Then I had this idea: I'll experiment with zero gravity subregions, so parts of the level will have gravity, and others won't! This is still in exploratory stages, as I haven't coded any game logic at all, but it's an interesting idea.

If I'm going to mix up gravity regions within a level, I need a really good way to visually mark where you can or can not expect gravity to exist. I figured a nice outline around each zero-gravity region would be a great start, however that has required another detour into prerendering scripts. First I put a script together that searches through all of the levels, generates a vertex sequence for each zero-gravity region within each level and saves them to a csv file. Then I run a pygame script that reads each shape and attempts to render the appropriate shape for the outline. I wrote my own line-drawing functions for this, AFAIK I can't do dashed arcs within pygame's basic drawing functions, so it took a while to sort that out. Here you can see a near-final (I hope?) version of the essential logic, smple color coding while I debugged various issues:



The next step should be to take these prerenders and place them over the level graphics, then disable acceleration of gravity for objects when fully within a zero-gravity zone. It might be as simple as that... hopefully! (p.s. please don't ask about zero-gravity regions that have hollow sections, I've had enough math for a bit and want to leave that for another time...)
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Fri Aug 04, 2017 4:45 pm    Post subject: Reply with quote

It works!


red block is falling by gravity, but player object is safely in zero gravity and does not fall

There's still a little bit more to do before I call version alpha of zero gravity areas ready to go. The main thing is what happens if you're already falling from gravity and then you enter a zero gravity area. At first I thought I would just "continue existing gravity" so you would float through the area, then perhaps resume gravity on the other side. I think I've changed my mind on that though; I think I want to have any object that enter a zero gravity area stop on the first "floor tile" it hits. But right now the objects just pass right through.

I also switched the tile graphic placement, as I was originally planning to have "black nothingness" be zero gravity, but now I think I like using the floor tiles in those regions better, and the dark regions will be "outer space" where you cannot help but float to some final destination. The dashed outline still isn't quite right, but it's more than close enough for me to shift focus elsewhere for a bit.

I might add in common crates next, I think there's a website that lists all the videogames that have crates, and if I can get myself listed on there too it's good advertising. I"m also considering adding in the option to pull crates (or all objects?), so if you push one into the wall within zero gravity, you have the ability to get it unstuck. Maybe holding control or something while moving away from the crate.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Sat Aug 05, 2017 4:33 pm    Post subject: Reply with quote

Today I finished implementing the "once you enter zero gravity, your previous gravity stops and you can move freely" logic, and I also added ability to pull objects if you hold control while moving away from them. Besides these things, I've been trying to clean up some of the graphics, with rather mixed results. Can't get a block that looks good so far, and I keep choosing bad color shades. On the plus side, I did add a randomly generated star field to the background of the game, which I think looks neat, with a little gradient flare. Oh, and I did add the crates -- I just convert any "uncolored" block to a crate.

I've got a couple ideas on deck to potentially work on, one is a block that always has gravity (so you can't make it stop in zero gravity, it always goes), or possibly some sort of path-following platform that could transport you from A to B through a zero gravity zone. If all else fails I'll just add more stars to my background, that would probably make me happy for a couple of minutes at a time. :) early access link
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Sun Aug 06, 2017 8:19 am    Post subject: Reply with quote

I'm stalling. I know this for two reasons, first is because I'm writing text-wrapping logic for a --help argument on an in-house level handling script (i.e. this is something no one else will ever use), and second because I'm typing about it. You want to see a snippet, the text wrapping code? It's really nasty, it's great. See, I knew you would be impressed. Here's what it looks like in the end, it even supports begin on one line and end on the next line, if necessary!



Ok, great, now that I've wasted enough time on this cockamamie detour, I guess I'll revise the script actually support the --invert flag and stuff.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Sun Aug 06, 2017 9:51 pm    Post subject: Reply with quote

Irregularly shaped levels turned into a time sink, but after a lot of number guessing I think I have the core (pre)rendering logic done. I still have to smooth out some bad corners on 3-way turns, like the edges of the plus sign. I went all the way and implemented support for hollow sections within an outline, which I decided to call windows. Adding in the background behind the outline was one of the hard parts, because I had to fill the center and also crop corners to fit within the border radius. Lots of number guessing when doing those parts.




Well, I'm glad it's ~done. I also added the ice cube, which is the always-gravity object i talked about earlier. Most objects come to a halt when touching a zero gravity surface, but the ice cube keeps on going, unless it lands on your head. (There's unfortunately a bug where the ice cube teleports you if you have it on your head, then move down into non-zero-gravity only to land in yet another zero gravity section. Kind of lucky that I made a test level that met those specifications.)
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Mon Aug 07, 2017 8:49 am    Post subject: Reply with quote

After spending the much better part of a day toiling on the irregular shape outline rendering logic, and finally getting it in working order, I had a great idea! I'll take the outline and expand it in size, so that there's a little bit of padding between it and the region it's surrounding. Thus, I set about writing a nice little method called expand(amount) that (as far as I can tell) does a fine job of adjusting each point's location to allow for the padding.

After that, I ran my rendering script on the expanded points list. As you can see, it worked on the first try!



edit - i lied, the new expand(amount) function wasn't working right. this is because i was brilliant enough to actually use dx as the parameter name, which i'm so ashamed of doing for a non-directional value that i lied when posting about it and pretended i just called it amount. inevitably when i was adjusting point.x and point.y along the way, some of the y values started being adjusted by dy, because i subconsciously figure x is dx and y is dy, but in this case dy doesn't even exist. to prove that i have learned from this mistake, i am going to... leave the parameter name unchanged for now.
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9442
Location: Not Finland
PostPosted: Mon Aug 07, 2017 10:33 am    Post subject: Reply with quote

Quote:

to prove that i have learned from this mistake, i am going to... leave the parameter name unchanged for now.


I have been guilty of such folly, in days long past.
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Mon Aug 07, 2017 3:24 pm    Post subject: Reply with quote

New look for the game, inspired by colored sprinkles and graph paper. Either that, or I'm in the midst of a complete refactor of what was some pretty rough code, although it sure worked fine before I started this latest idea. (I think some of the original code didn't work right, but the mistakes got covered up as rendering continued.)



I'm back to square one on the lines themselves, at least in this case. I have to test it with some 3way turns to make sure it doesn't complain, both concave and convex, but so far so good. The next part is refactoring the background filling, which I original did by some means of tedious trig calculations, rendering litle slices into the corners one pixel wide column at a time. I realized earlier that maybe I should have just ... done it another way, mask it with color I guess, so maybe I'll just hack together a drawInverseCircle function, blit a full square tile's worth of background, then mask it with color that will be used as transparent. Wonder if I can get this done today.......
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Mon Aug 07, 2017 6:17 pm    Post subject: Reply with quote

Here we go. I am pretty close to being back to where I was last night, before I rewrote all of the rendering. Sure, I could be adding new objects, or making levels, or just playtesting in general, but this is much more fun than any of that.



There's still a little work to do. My region finder script crashes if I jut out from the top row, runs into an out of bounds array check error. Also a dirty secret: to achieve this result I make 2 rendering passes. This is because the background fill is always performed from left to right, but sometimes the left edge is not ready until area to the right has already been rendered, and then the background fill clobbers it. Since this is just a prerender utility, I have no problem taking the 100% performance hit of drawing the thing twice, second time outline only. (And!, since it's the outline only the second pass, it's probably more like a 90% performance hit, which is negligible.)

I also have to adjust the handling of windowed regions, need to render them on separate surfaces so I don't spill transparency data onto the main surface while filling in the background. I think the tough part is done, though.
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9442
Location: Not Finland
PostPosted: Tue Aug 08, 2017 6:14 am    Post subject: Reply with quote

Yeah, outlining stuff by tiles is a huge pain in the ass. You just have to keep tweaking things until it looks good and all the edge cases (in this case, literally) are sewn up.

The only real design decision is whether your outlines fall inside or outside of the selected area. In your case, outside.
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Tue Aug 08, 2017 5:29 pm    Post subject: Reply with quote

By end of yesterday, I had the prerendering script working just about right, and nothing has changed there, luckily. It was today though when I noticed my node script that loops through each level to generate a list of vertexes defining each outline? Well, turns out that was also not working quite right. Worked well enough to look like it worked, but was secretly busted enough that it required a substantial rewrite. This challenged my feeble mind, put with the eventual aid of pencil and paper and a methodical coding session, I got it just about right. (See, apparently the logic that searches for hollow sections within the outlines is overly optimistic and returns some false positives, but all of these are 2 point sequences -- obviously not a full circuit -- and thus I just ignore them. So, when I am posting here sometime saying Oh man! My vertex code isn't working after all, for a new level! then we'll remember this sweeping of code under the rug and laugh.)

There's still a little bit of inaccuracy in the rendering, but I'm gonna call it 95% good, and also currently you can't tell unless you look because the background of the page is black now too. (This is probably a good indicator that the stripey background of the gravity areas has absolutely no contrast and should be aggressively refactored, but then I'd have to do something graphical and I"m not quite there yet.)



So, even a 2-section prerender works okay now. Also I'm currently planning on having multiple player objects, probably will hit tab or something to cycle through the active one, it's for down the line. But in this case you have a player/token in both regions, in theory there could be a switch in one room, or something like that.

Quote:
Yeah, outlining stuff by tiles is a huge pain in the ass


Makes me feel a little less as if I am a bumbling clod and thus required 17 days to code the logic for a "feature" that shall be taken for granted by most anyone who loads it up. Probably still mostly true.
View user's profile Send private message Visit poster's website
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4989
Location: Silicon Valley!
PostPosted: Tue Aug 08, 2017 9:09 pm    Post subject: Reply with quote

This is cool. I played a bit and I feel like it renders well, could be a neat game once all is said and done. I had fun breaking things by rotating the gravity very quickly in rapid succession.

What I love is the pace with which you're going at it. Regular updates like this get me kind of pumped up. Love to see folks making progress on projects. :]
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Wed Aug 09, 2017 9:27 pm    Post subject: Reply with quote

I think maybe, possibly, (probably not) I am done working on the border prerenders. After the last milestone, I decided the generic blue color kind of sucked a little bit on its own, and maybe the borders should be graphical, like rocks or something. It was a good idea, so all I did was place rocks.png in the script directory, and then I ran it and it generated exactly what I wanted. Hmm, I am forgetting a period of hours where I had to do even more refactoring on the script to support this functionality. Then I had to spend even more time restoring dashed border support, because I do want color-only borders for the gravity areas, or is it the zero gravity areas, which is which? I have flip flopped more than once.

I also spent some time searching free tileset sites. Because I'm not making a medieval rpg a lot of them do not really match up, but I found one that gave me something to start with. I've used its rocky tile look for the borders, and also one of its cave backgrounds for the non-gravity area of the game. This means that now, we're back to "black space has gravity, and you fall through," which I think was the truth at one point already. I think it's the logical choice, everyone expects blank space to be a pit of some sort that you might fall through. I'll probably do something stupid like try to add in border radius on these outlines, maybe make a feeble attempt at preserving proper dash intervals if I'm feeling really masochistic, but here's where we're at today.



I had an idea for a "glue" block today. So if you had a glue block, you could push a block against it and it'd stick to it. You could make a bridge, and extend it over a no-gravity zone and it would allow you to cross safely, maybe there are spikes on the bottom. We'll see.

I also had an idea for the selection of multiple player tokens. I'm now thinking something like, if you hit the tab key, it brings up a number next to each token, with an arrow pointing to the token in question, and you could press that number to select that token. Clicking with the mouse is an option, and I'll probably add it for full coverage, but it's also unlikely to be a good option because you have to toggle between keyboard and mouse -- especially if there's levels that expect you to regularly switch between tokens. Bad news, really. Got to give it some more thought. I still think it's a valuable puzzle element, even if it's not ideal from a controls standpoint.

Oh, and also the flip flop from "black is no gravity" to "black is gravity" broke all the other test levels, sorry to all of the early access members. I need to stick a big div in the corner that says "early access" to cover all my bases. Just have to toggle the tiles on those test levels.

Quote:
I had fun breaking things by rotating the gravity very quickly in rapid succession.


Need to fix this too. My current plan is to disable rotation until all objects are in place. There's some existing code support for checking this, e.g. colored blocks don't perform a match elimination check until all blocks have fallen into place, so if a third one is still on the way he doesn't get left behind. Unfortunate risk of "but I'm pressing the move / rotate key, why isn't it working?? if I take this route though, I'll need a prominent HUD type area that says "sorry, can't move now" or something.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Thu Aug 10, 2017 9:42 pm    Post subject: Reply with quote

A ltitle more work was done on prerenders, to properly support regions within regions. Still doesn't support infinite recursion, but it does the job well enough now. I've had enough fun with it to last a while.



I fixed a couple of collision bugs, namely the one where ice cube would fall through the player object and teleport the player a bit. Floating point stuff, where the ice cube was at 300.21, and wanted to move by 0.91. The final position will be 301.xx, but the collision is calculated by integer based rectangles, so basically it was like "oh, 300 + 0.91, that's still 300, so you're totally ok to move down by 0.91." Then next frame, the ice cube is like "you're in my way now, other object" and repositioning ensued.

I modified the application of rotation and other transofrmations just a bit. Instead of having the moveSideways() function make a hard-code-ish call to "transform: translate(-30px, whatever)" I have a helper function that gets a set of default transforms -- this includes angle, scale, and such -- and then it accepts an overwrites parameter, so if I want the player token to "jump" a few pixels off the ground, I layer it on top of those defaults to preserve them too. This became necessary when I added active/inactive status to the player tokens, and I set them up to scale to 150% or something like that, when active. But without these changes, the "animate move" function was clobbering those transforms.

In this process, somewhere along the line, I messed up the animation for climbing up the ledges. I am looking forward to debugging that one.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Fri Aug 11, 2017 12:10 pm    Post subject: Reply with quote

Currently in the process of implementing "quick select" for player objects. The idea is to have an ID for each one in a little circle (this part works*), and then a line pointing from the circle to the token (this part, not so much). Still working on the maths to get that line rendering properly.



*exception - currently will die paintful death if level is rotated

After I get the line properly positioned and rotated, I'll set to work on a little bit of animation. The idea is to add some bob and weave, or bounce, to draw attention to the number and make it look more lively. I'm guessing I'll just set a local timer for each one to handle this effect, rather than trying to shoehorn it into the level object itself. Oh, and I also probably need to make pressing the numbers actually do something eventually.

edit 1 - lines point properly now
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Fri Aug 11, 2017 2:46 pm    Post subject: Reply with quote

Oh man! What could the problem be?! The lines track perfectly if on the right half of the level in a couple quadrants, but on the other side they're completely busted! The code is perfect*!

Code:

// helper function adjust arc to the desired quadrant
// assume y axis up is positive
function adjustArc(arc, dx, dy) {
    if (dx < 0 && dy > 0) return ((Math.PI / 2) - arc) + (Math.PI / 2);
    else if (dx < 0 && dy < 0) return arc = Math.PI;
    else if (dx > 0 && dy < 0) return ((Math.PI / 2) - arc) + (1.5 * Math.PI);
    else return arc;
}
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 326
Location: Tristram
PostPosted: Fri Aug 11, 2017 5:15 pm    Post subject: Reply with quote

I've got it. I wasn't sure at first when I started adding "lively" animation to it, but I screwed around with the numbers and it turned out pretty great. Still shot:



I even managed to get it to work with rotation, this was a much simpler process than I expected (a nice change).

Right now you can push around the inactive player tokens by default, but I'm much considering making it the other way around, so that by default you can't push them (but you can, in turn, climb on top of them... interesting, right?) Then I think I'd make it so if you hold down control, you can push them -- because there's not a lot of reason to disallow such a thing, given that you can switch between any of them whenever you want, so you could just switch to that one and move it on its own anyway. The main downside is that it means the controls become more complicated, but hell, it's a puzzle game, it's supposed to be hard!

Oh, I found the cause of the bad climbing animation bug. I was applying the transforms in the wrong order, have to wait until rotate transform is applied before adding scale transform. Another mercifully easy bug fix, that one. early access link
View user's profile Send private message Visit poster's website
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Glue Gun Glen Page 1, 2, 3, 4, 5, 6  Next
Game Developer's Refuge
is proudly hosted by,

HostGator

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.