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 Previous  1, 2, 3, 4, 5, 6  Next
View previous topic :: View next topic  
Author Message
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Mon Aug 28, 2017 2:12 pm    Post subject: Reply with quote

Looking pretty good now. Concept level.

View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Mon Aug 28, 2017 9:17 pm    Post subject: Reply with quote

New build going up. Haven't addressed too many critical issues, e.g. controls probably still work the same. Working on a script that will generate a random background for each level, still prototype. link
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Thu Aug 31, 2017 9:52 am    Post subject: Reply with quote

Messing around with adding some background tracks to the game lately. My working plan is not to include anything of much length, but rather to have a mix of short melodies that are played in a random order, with some downtime between each one. Will see how that works for me. I'm generating these via a nifty application tuxguitar, I enter the notes I want it to play and it does the rest. On a more technical side, I have to export as midi, then use another program to render the midi to a wav file, and then I am currently converting that into a final mp3 file. The path to each mp3 file is stored in a simple json list, and the MusicController object reads that list at runtime and starts cycling through them.

View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Fri Sep 01, 2017 5:29 pm    Post subject: Reply with quote

Added some sound effects today. Not so sure that I won't later on replace half of them or more, but I decided it'd be better to get some serviceable placeholders in there, wire them up, and then move on instead of twiddling around for hours wondering "is this the perfect grab item sound effect?"
probably not
I've highlighted a few items I want to focus on for now. One of them is a revisit of the colored block, I've got the tenth design ready of the graphic - it needs some more work, but I think I'm going in a direction I'm finally ok with. It's going to be a 4x4 grid within the block, and there will be tetris pieces that form the block. One of the pieces will be missing, and the others will animate around from time to time, like you're trying to solve one of those "rearrange the pieces" puzzles - except just for visual effect. It was pretty easy to rig up a quick test run of the concept, with the animation system I just created a behavior for the color block added a new behavior file with the frame indexes and then ran it to see. When I left the DOM approach behind I never ported the animation logic for "matched blocks disappear" which is j8ust as well, because I probably have something different in mind now that I'm doing the tetris effect. My expectation is that I'll have just 2 colors of block - I originally expected more, but that was when this was an "untitled match color game" and not a "untitled shoot glue gun, grab crates, fall in lava, grab gems, and whenever I get around to finishing the programming of it, match color game. I think I'm going to make that the title now, as much of that as can fit. Good day.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Sat Sep 02, 2017 7:37 am    Post subject: Reply with quote

Quick look at the tetris animation effect I described.



I threw together a quick script that lets me render the spritesheets for these based on a template file, which looks like this

Code:
009a
100b
248c
3567

109a
240b
308c
0567

...


The difference between each cell is like 3 or 4 barely-there pixels ("noise" within the tetris cell), but I'm ocd enough that I figure it should render them properly as the pieces move and rotate. Having the script makes it no hassle if I want to replace the graphics - I don't have to drag and drop shapes for 30 minutes by hand, I just have to update a single source graphic (30 seconds of work?) and the script does all the work to generate the spritesheet.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Sat Sep 02, 2017 6:01 pm    Post subject: Reply with quote

Fighting bugs, adding effects. I know I"m doing something right with the effects, because I keep reloading the level and watching the blocks all fall apart. It's cool!



Now, I might have to fix the bug where glue groups that fall in lava cause an infinite loop. Whoops. Hitting lava will probably dissolve any glue on the burning block, and I'll have to update the glue group in the process - which will involve picking a new leader, too, if the burning one was the owner of the group before. Should be tons of fun. There's also the scenario where two crates are glued to each side of a colored block, and then you drop another colored block on top of the first one to score a color match - the glue group must then be separated into 2 separate groups, because the chain has been broken. And, in that scenario the group concept is completely abandoned, so the crates will no longer be in a group at all - this is important because you aren't allowed to push glue groups around at all because they're too heavy, but if the dissolution of a glue group yields singletons, then any player would expect those singletons to again be moveable, grabbable. There's also the fire ball projectile that should do the same thing, but at least by then I should have reuseable logic in place.

Have to point out that the particle effect obeys the current animation step of the tetris animation logic. It's finely crafted.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Sat Sep 02, 2017 9:46 pm    Post subject: Reply with quote

Late night run at the on-the-fly group recreation went better than I thought. If I remove a member from the group (regardless of position), it turns out it's logical and straightforward to simply disband the group entirely, then re-run all glue checks for every former member of the group (except the one that got color matched, lava, etc.). So, I can separate by color match and regain ability to push a singleton crate, which is great. The problem right now is when a group falls into the lava, the gravity is staying too high - blocks are supposed to very slowly sink into the lava, and really the plan is for them to ultimately float halfway in the lava, and you can use them as a bridge. But something in the logic isn't working right, the lava-burned crate disappears but the rest of the glue group doesn't follow into the lava, instead it acts like the lava burned block is still there and blocking tis descent. Peculiar indeed.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Sun Sep 03, 2017 7:22 am    Post subject: Reply with quote

That was surprisingly easy. I had added a helper function getGlueReadyState that not only checked isGlueable but also checked to see if object is currently in the lava - I just switched a couple if statements to use that method instead of a bare isglueable check, and there it is.



The hard part then, it'll be the "crate floats in lava halfway" logic, I believe. Though, that might be easier than I'd think too - once an object hits the lava, I set isDrowningInLava to true and significantly reduce gravity so that it "slinks" slowly. Here, I am thinking I'll add another property to object types, canFloatInLava probably. if flag is true, then after gravity application I'll do a quick this.y % cellHeight > (cellHeight / 2) check, and then shift it back "up" if it has passed the midpoint of the cell. Yeah, I bet that'll work nice. Other complicating factors: if you turn level sideways after dropping a block to float in lava, (1) probably will not allow rotation until block has fully settled into place, (2) when level is turned sideways, the floating-in-lava block should not obey gravity - it should essentially be "glued" to the lava, and (3) if level is turned fully upside down, perhaps allow the crate/object to "fall out" of the lava, turn off the lava drowning flag, and it resumes its original role as a grabbable, moveable object. I believe there might also be a task (4) allow the player jump parabola logic to account for variable heights, e.g. player is on a half-sunken crate in the lava, does not need to jump a full tile height ot get up on the next ledge, just half so. I think all of these are doable.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Sun Sep 03, 2017 10:01 am    Post subject: Reply with quote

Check out this new level. Let's call it a concept level, but it's really a level that could easily appear in the final game. it cleverly combines essential color matching with the new float-in-lava behavior, and requires you to run the tasks in the proper order to reach all of the gems and match all colors. It's very good. (You can also see in the video that I haven't finished working out the partial jump logic - it'll be a little bit harder than I expected.)

View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9441
Location: Not Finland
PostPosted: Sun Sep 03, 2017 6:51 pm    Post subject: Reply with quote

Damn. That's a lot of functionality for the short time you've been working on it :)
_________________
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: 324
Location: Tristram
PostPosted: Mon Sep 04, 2017 4:59 pm    Post subject: Reply with quote

Things are getting interesting. Looking to post a bit of summary on this new stuff latter, but for now there's just one word... laser beams

View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Tue Sep 05, 2017 6:49 am    Post subject: Reply with quote

When I was gearing up to add laser to the game, i started by looking for "free laser sprite" and such things. My results were really not very good - I did find a pretty good looking pack on the unity asset store, but it was not quite freeee. After I started looking for terms like "html game laser" though, I found a couple pretty helpful demos that led me in the right direction.

First I just had a straight line with a glow effect. It looked alright, but I figured separating that line into a bunch of little segments and giving them random offsets could make it look a lot sparklier, and I was right. It looked pretty cool - but just calling the drawLine canvas method, the performance wasn't going to work. Sure, for one laser it was fine, but I took serious hits when I threw in 10 lasers. (Will I have 10 lasers in a level? I don't know, but I should be able to.) So, I followed the other suggestions and threw it onto an offscreen surface. I think right now I have "only" 8 frames of laser animation, but it does a good job. I figured while I was at it, I'd throw a second squiggly line into the mix - I"m prerendering anyway, so I can be gratuitous.

The other consideration with the offscreen cache? Variable length lasers. Should I create a separate prerender for each possible length within the level, or just scale? Barring an unexpected change of mind, I'm scaling a 200px laser to whatever the length of a laser might be. Still looks good in my various experiments, I think it will stand.

For all intents, that was the easy part and it was time to make the lasers do things - movement behaviors, I called them. Didn't know for sure where to start, so I just mocked in what I thought I might like in the level file data and used it as a base:

Code:
    "lasers": [{
        "x1": 506, "y1": 0,
        "x2": 506, "y2": 155,
        "behaviors": [{
            "behavior": "translateEnd",
            "dx": -198,
            "duration": 180
        }, {
            "behavior": "idle",
            "duration": 30
        }, {
            "behavior": "translateStart",
            "dx": -396,
            "duration": 180
        }


Each behavior maps to a small helper class that enforces the requested movement / rotation / etc. Each laser loads in its list of behaviors (if it has any - not all lasers have to move), and starts at step 0. The solution here worked quite a bit like my animation implementation. Upon beginning a new behavior (whether at start of level, or after completion previous behavior command), I take a snapshot - or an "instance" - of the current start/end positions of the laser. With that info at my disposal, I can thereafter use percentage calculations, comparing the current age of the behavior command against the expected duration of the behavior to say "laser should be 25% moved, 50%, and done." To make it look smoother, the actual percentage is weighted by a simple sine equation, such that the weighted percentage increases slowly, ramps up in the middle and then slows to a gradual halt. I don't have any flags to control this easing logic, but from where I sit I don't expect to want them. Having control over movement, rotation, pivots, etc. seems like it gives me plenty of freedom - would I really gain much from micro-controlling the acceleration rates of the movements?

The next step which is already underway is occlusion checks. if the laser sweeps from a to b and there's a wall in the way, if should not go through the wal and the player should be safe behind/under it. It's back to the maths again then, which has been a bit of a stumbling point from time to time, but I don't think I'm dealing with anything trickier than "line equation" on this one so I might be alright.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Tue Sep 05, 2017 12:04 pm    Post subject: Reply with quote

jumped off onto another tangent, but this time not necessarily just to distract myself from something tedious. No, I've got some great lasers in the game and I started thinking about how they obviously gotta kill people. I added a temperature property to objects - getting hit by a laser increases temperature, and if you overheat then you're dead. This approach will allow a little bit of a grace period, so if the laser taps you on the shoulder you're okay, but any more than that and it's player.die()( time! ha ha ha! Eternal damnation for the wicked! ha ha ha!

What will player.die look like though? I could do this, right?

Code:
function die() {
    this.visible = false;
}


wow, wouldn't that just suck? So, I previously created a textured particle object that I use when you match colors on objects, and it'll be a great thing to use it here, too, but then I thought it might be neat that instead of just a bunch of square particles (as the player is vaporized by glorious laser), what if all of the particles were randomly sized subrectangles, such that they fit likea jigsaw puzzle to create the entire player, but tumbled off the screen upon laser contact?

This led me to a rect dividing helper function, which you can see my crude test results via this link https://jsfiddle.net/jxxdn8n9/
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9441
Location: Not Finland
PostPosted: Tue Sep 05, 2017 12:54 pm    Post subject: Reply with quote

Quote:

This led me to a rect dividing helper function


You know... that's something I've never messed with. Interesting :D
_________________
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: 324
Location: Tristram
PostPosted: Tue Sep 05, 2017 5:16 pm    Post subject: Reply with quote

99% chance this is the coolest thing I've ever coded. More systems in play - this is going to get wild.

View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Wed Sep 06, 2017 11:39 am    Post subject: Reply with quote

Last week I created 3 short background melodies, and I like them all. Yesterday I finished work on another one, and I've gone back and forth on whether I will add it to the rotation. It's not that I don't like it, but more so a matter of fit - does it jive with the other themes? But even then, although I'm looking for a generally cheerful theme for the melodies, it's always good to have some contrast of starker, darker melodies, and this one fits that.



Also, I'm going to start calling this game Glue Gun Glen. And if I think of something better later, I'll just change it then.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Thu Sep 07, 2017 2:09 pm    Post subject: Reply with quote

Off and on, I have considered adding the "arrow" blocks into the game. This isn't quite the same thing, but it's pretty close - and it might be a lot cooler. (If you look closely, you might notice that my rail track is "heavily influenced" by the one in Terraria. I burned a lot of time trying to find a good rail tile that made sense in the game, an dI never found it. This one will let me move my gears for a while coding instead of googling for rail tracks. It'll be hard enough work if I"m actually doing it...)

View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Fri Sep 08, 2017 5:59 pm    Post subject: Reply with quote

Haven't even gotten the jump in cart animation done yet. Get ready to jump dive in, fall in, disappear, sit up and get ready to drive. These are pretty close to ready, but the easing equation is a bit jacked up for the dive in, and there's some minor rendering issues. I added a master/slave rendering logic for objects - when player jumps into cart, the cart itself assumes ownership of the drawing of the player, so that the cart can draw (1) back of cart (2) player (3) front of cart, thus ensuring proper z indexing. There is also new clipping logic, so I can start disappear the player as he falls into a cart / stands up. Once I get the animation sorted out, I move on to making the cart actually move. Not overly difficult, except now the keyboard input will need to be directed to / shared with the cart, and I'll have to disable collision detection wtih ... well, that's tricky because I want the laser to kill player when riding in cart, so I shouldn't disable collision for player, but I also want the cart to be safety on the left/bottom/right if laser hits it, so I shouldn't disable collision for the cart either, but if I leave it on for both then they're going to freak out when I start moving them, and one's gonna get warped a full tile and screw everything up. I'll also have to take another look at my laser max distance finding logic, I will need to check against the cart first and then player second, but I need to retrieve both objects - or at least, retrieve the cart and secondly check for passenger and process it if appropriate. Then, when all of that is sorted I also have to animate jump out of cart, though I think that may be primarily a standard jump with some clipping logic added, perhaps. I knew this would be fun.
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Sat Sep 09, 2017 12:01 pm    Post subject: Reply with quote

This is a good start - the core functionality of entering a cart, riding the cart up or down rail, and then successfully exiting the cart and resuming normal movement is now in working order. There's a velocity bug with the cart, if you keep holding down the arrow and going back and forth you start going faster and faster - I have yet to figure it out, but it's not pressing. The next order shall be allowing player to fall directly into the cart from above, rather than boarding from the side. This means defining another animation so that I can define clipping regions and such as the player falls in. That should be enough to cover the core player/cart logic, but still on deck is placing other objects in a cart, then pushing the cart (with the crate, etc.) to the other end of the rail. This is a pretty good bunch of work.

View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Sat Sep 09, 2017 1:47 pm    Post subject: Reply with quote

Side note - the chrome debugger has been pretty darned helpful while working on this game. I had a bug with the "fall into cart" where - after player fell in (this worked), the arrow keys did nothing. Unsure why, so I stepped through the "is ok to move" logic and in pretty short order discovered I wasn't setting "isGrounded" when falling into a cart - I override the default landing logic to begin the animation, rather than to just "land on ground" and I wasn't toggling that flag. Not quite done yet,as gravity stops and then starts again when "hitting" the cart. Haven't decided exactly how I'm going to math my way around this one, but I'll think of something.

View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Sun Sep 10, 2017 8:52 pm    Post subject: Reply with quote

A new build goes up, now featuring lasers and mining carts, accompanied by a new demo level. This is another excellent level that should appear in the final game - but do keep in mind that this is early access, and I am casually throwing you to the wolves: ultimately the various concepts in this level will be introduced one at a time, rather than all at once. But, such is a cocnept level!

The mining cart was a lot of work - and that work is hardly finished, but all of the core functionality I am aiming for, it is now ready to rock. The key revelation, it was adding an option to push empty mine carts along the rail, which really helps a lot when designing puzzles. It means one player can go "over there" to retrieve a block, send it back in the crate, and not be stranded on an island.

I put in a couple of small tweaks ot the input code: (1) leaving the window (or changing tabs) clears the "held keys" data, e.g. you hit ctrl+tab to change tabs, when you return game no longer falsely believes you are still holding ctrl; and (2) disabled default key behavior and event propagation on most keyboard input. Unsure of how much (if any) effect this will have on the sometimes-bugged input behavior, but shouldn't cause any harm.

And, here's the new level in action. Obviously spoilers here - if you watch this video before trying to figure it out yourself, you won't have anything left to figure out.

View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Mon Sep 11, 2017 8:29 pm    Post subject: Reply with quote

Although I could hardly be more satisfied with the outcome of the latest level, it's probably time to move back into the realm of grunt work for a while. Today that meant porting the prerender code away from pygame and into javascript, using an offscreen canvas to store the data. You can probably guess how excited I was to take a couple thousand lines of code - although some half of it was already in javascript, as I did use a node script to generate the outline shape data - and move it all into a couple of helper classes within the proper game project. It wasn't exactly lightning fast work, but I did make shorter order of it than I might have guessed. I know I'll have to hack away at it a little more to get full parity on the pygame version (e.g. multiple sections within a same level, hollow segments within a level), but at the moment I'm satisfied with a basic working version.

Naturally this means that I spent [x] amount of time today, and in the end the game ... looks and plays exactly the same. Flawless victory, right?

It's still possible I'll use the in-game prerendering logic to save renders to disk, i.e. players would still be loading pngs of the level that I'm now generating within the game. I suppose it's a bit kooky to be considering this, the only cause would presumably be to lower the odds of error (no chance of catching an error on the prerender if the prerender is a PNG). Notably though, this switch brings the level editor back into play - no dependency on external build scripts to get a level off the ground.

There's a few places to go from here, staying in the grunt lane. (They're everywhere!) I need to add a mask layer for tiles, because now I'll potentially have railroad support beams descending into the lava, and such. That's basic stuff, I'll just add another tilemap and then make sure to bake it into the prerender. The level editor export has been a little screwy of late - it doesn't export the lasers, and some of the objects aren't exporting properly/at all (carts, and sometimes(?) the colored blocks). In the "more intimidating" category, it'd be awfully helpful to have a little gui for editing lasers - I've been coding them all directly into the level files so far, and that's more than fine for getting ideas off the ground, but long term it's a tedious solution at best, and having a ui for it will make reviewing the sequence of behaviors easier.

And... if I get all of that taken care of, I'm continuing to subconsciously mull over approaches to implementing move undo into the game. There's ... a lot going on, a lot to track, but I've been forming a plan that might make it easier than I'd think.
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9441
Location: Not Finland
PostPosted: Tue Sep 12, 2017 7:22 am    Post subject: Reply with quote

This has to be one of the crazier puzzle games I've ever seen. I love how the little guys leap head-first into the carts.
_________________
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: 324
Location: Tristram
PostPosted: Tue Sep 12, 2017 2:44 pm    Post subject: Reply with quote

Quote:
I'm continuing to subconsciously mull over approaches to implementing move undo into the game. There's ... a lot going on, a lot to track, but I've been forming a plan that might make it easier than I'd think.


So... good news, bad news. First the good news: I have written code that will fully support saving state of game! I press S to save the state, and then I press Z to restore that state. More good news: the restore of the state happens pretty fast! And... now the bad news - there's gonna have to be some optimizations... takes at least 1 full second to save the state... ha ha ha.... ha... ha...

Want to read an interesting take on coding this stuff? This was an excellent reference for me: http://nullprogram.com/blog/2013/03/11/ He has earned a spot in the credits, whenever I update that overlay. My solution is fundamentally much the same as his suggestions, but I do have scenarios that I have to cover that look like this:

Code:
object1 {
  name:  player,
  renderMaster:  mineCart1
}

object2 {
  name:  mineCart1
  renderPupil:  player // no, it is not really called pupil
}


So, I can't just say object1.serialize(), because then I get infinite serialization loop - object1 points to 2, which points to 1, back to 2... never ends. My solution (for the moment, anyhow) is to build a master list of all distinct objects, and add in reference ids - it looks more like this:

Code:
// level data
{
  objects:  [
    {referenceId: 0}, // will point to player
    {referenceId: 1} // will point to cart
  ],

  // here is the distinct list of objects
  references:  [
    {name: player, renderLeader:  #ref1},
    {name: mineCart1, renderPupil: #ref0}
  ]
}


That's the gist of it, any way. When I deserialize, I start by taking the distinct references list and building new objects for each entry - but there must be a second pass to replace the references. And this is actually the part that works pretty quickly, which is a shame - I wouldn't give a handful of brimstone if the commit undo logic took a second or so, because that's only gonna happen when player jump sin lava, pushes block wrong way, etc. The save state more or less has to happen anytime the player moves (I can fudge a little and only save state on keydown, regardless of how far you walk - maybe), so it needs to be very fast.

The main problem right now is that the distinct references list tracks everything - even anonymous json objects that could never be referenced by anything else, because they're just inline declarations. I can refactor the code to place a hard copy of the object on first encounter, and then reference on the others. I'm still a little leery of the inArray lookups as I build this master list - if I'm feeling a little brave, I could consider only subsitting my base "Block" object, from which more or less everything inherits (notwithstanding say, lasers). A little risky inso much as I could miss a ref somewhere, but if that were to happen it'd probably be pretty obvious during continued dev. If I'm feeling a little less brave, I could still partition the inArray trackers to store by object type - you know, another option is that I could sit here for another hour spitting out stupid ideas, instead of actually trying a solution an dmeasuring it. Screw that. I'm going to turn on the xbox.

edit - never underestimate the time cost of that console.log statement you forgot to remove, honestly that cut it down to 100ms. still lousy there - now i'm only doing reference logic for the Block objects, and it's down to <= 6ms on average, which although it'd be great to be still faster than that - i can probably skate by as it is, and consider further optimization as i go
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 324
Location: Tristram
PostPosted: Tue Sep 12, 2017 9:10 pm    Post subject: Reply with quote

I hit upon a very interesting idea while mentioned the undo move work to another. "If you fall in the lava, you can just undo that? That's cheating." Well, it'd be a real hassle to fail a level after [x] amount of time invested because you took a wrong turn at the end, so there wants to be an undo - but what about tying the undo move to the collection o gems? This solves a problem in a very creative and fairly logical manner - I don't have to worry about performance nearly as much (mind you, at the 6-12ms range it probably would work okay anyway?), because collecting gems is a very isolated event, and it also adds a value to the gems. You're no longer simply collecting them to complete the level, but you also see every gem as your next checkpoint. It's very intriguing. (For the record, I've been experimenting with further optimizations to the serialization, but I haven't hit any kind of gold as of yet.) Because I have a systems fetish of some sort, Ive also given some thought to allowing manual checkpoints on a limited basis - for every [5] gems you collect, you earn a checkpoint to use at your discretion. It adds another rule to remember, but then again the people who find it "too much" can just ignore it and use the gem checkpoints, which in general will probably be quite sufficient.
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 Previous  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.