digitalsoapbox's Forum Posts

  • Some playtest footage of Sombrero from a session yesterday:

    [TUBE]http://www.youtube.com/watch?v=7TLRYuJ0Xso&feature=youtu.be[/TUBE]

  • CandyFace

    Thanks!

    Music is by Nathaniel Chambers of Bubble Pipe Media, who I've worked with on a number of game projects & prototypes and who I couldn't possibly recommend more. He also put a great soundtrack together for an old-school adventure game called Primordia that anyone who likes that kind of game should check out: wadjeteyegames.com/games/primordia

    Check out his stuff other at: bubblepipemedia.com

  • Ethan

    Thank you, kind sir!

  • UPDATE: Sombrero is now LIVE on Steam, with a 33% off launch special!

    Trailer:

    Steam Page: http://store.steampowered.com/app/472690/

    ------------------------------------------------------Old Message------------------------------------------------------

    Hey there! After a first successful playtest last night at the NYC Games Forum, I'm officially announcing Sombrero, a local multiplayer game for (as of now) up to 4 players.

    Press mentions:

    IndieStatik

    GameZone

    Here's about 9 minutes of playtest footage from the event. Sound wasn't recorded, so what you're hearing is the stage's theme music in the background.

    [TUBE]7TLRYuJ0Xso[/TUBE]

    And a few screenshots:

    There's still some bugs to squash, and a LOT more art to do, but thanks to C2 things are moving along at a pretty quick pace - the work above represents about 2 months of part-time work, though some of the art and the original idea date to about 2 years ago and a stack of Post-It notes with sketches and scribbles on them.

    digitalsoapbox2014-01-21 17:21:26

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I was just wondering if anyone else with Windows 8.1 and a gamepad is able to use the gamepad successfully with Node-Webkit or not.

    Works here fine under Node-Webkit on two machines running Windows 8.1, one a fresh install, the other an upgrade from Win7. Both are 64bit.

    I suggest trying something like XB360CE to see if your gamepad works with that enabled, which might help narrow down the problem. If it works with that, then something is either wonky with the gamepad, or wonky with Node-Webkit.

    If it works with XB360CE but doesn't work without it, that points to an issue w/ Node-Webkit or your drivers. Maybe try totally wiping your C2 install and reinstalling in that case.

  • If you're looking to use gamepads that aren't natively supported by the HTML5 gamepad implementation, and you're working on distributions for Mac/PC/Linux desktop, there are support programs that can enable the usage of all types of gamepads.

    For example, use Bluetooth (PS3, Ouya, Gamestick, Logitech gamepads, etc.) gamepads by dropping XB360CE into the executable folder on Windows: code.google.com/p/x360ce

    Other platforms have similar support programs, though XB360CE is the only one I can confirm to be 100% working w/ C2 for Node-Webkit export both during testing/development and final executables.

  • The OR block seems fine to me.

    Instead of Every X Seconds try giving the Player a new variable (Player.CanFire boolean start true) and check/set that when they fire.

    for each Player

    check gamepad OR block

          if Player.CanFire == true then

            Set Player.CanFire = false -- so they can't fire again yet

            Do your normal firing stuff

            Wait Player.projectileFireRate seconds -- adds delay between firing

            Set Player.CanFire = true -- lets player fire again

    That does it, but if there's any kind of drop in framerate the weapon doesn't fire. Why Every X works different than Wait X is a bit confusing. Still though, a step in the right direction.

    Thanks!

  • Why would the or block have to be checked every tick, when it can only affect anything every player.fireratio seconds?

    Or are you planning to add more code to the block?

    Yep, the second one. Also, since the player can begin firing at any time, having the gamepad input checked in the OR block under the timer could mean a delay in the projectile firing.

    I tried mapping this player input control to a button, and it works fine with the timer (without setting the projectile direction, obviously) - but not the analog stick. I'm almost wondering if it's a bug in the gamepad controller behavior now.

  • Also putting the every x seconds condition above the or-block could make a difference, but I'm not completely sure about that.

    The OR block is for player input that should be checked continuously, so I don't think it'd make sense to reverse that. Tried that originally, but I'll try the local timers suggestion - thought about it, wanted to avoid it, but it's better than it not working. The issue seems to be linked to the every x seconds, since it works fine without any delay in place.

    Thanks!

  • Bumping this in case anyone else has any ideas on what the issue may be.

  • Still the same issue, plus I've just ended up with duplicated code. I think I just need to find another way to do the delay, hopefully without recreating the events for every potential gamepad.

    Oddly, doing player movement in the exact same way works perfectly, as does creating projectiles without any delay between them - it's just anything with a timer on it that breaks.

    Tip: Make a function for all the stuff that the current block you have is executing. Then you can just call the function instead of having all that code repeated for each player.

    The way it's working now doesn't have it duplicated for each player, and I'm pretty sure calling a function every tick for each player to check for continuous input wouldn't be any more efficient than the way it's set up in the OP.

  • Thanks — That's exactly what I was trying to avoid having to do, but if that's what it takes, so be it. Also, it does work properly when there isn't a delay between spawning the projectiles, so...that's weird.

    I was hoping the For Each block would handle each player separately, as that's how I thought it was supposed to function...maybe that's not the case?

  • If you want to disable all collisions for a specific object type, you should be able to set collision to disabled without specifying which objects to stop colliding with. This doesn't work w/ asm.js-based collisions yet, but hopefully will soon.

  • Yes: scirra.com/manual/28/layer

    Also, check out the "is on layer" event.

  • I have a local multiplayer game I've been working on, but have hit a wall on a bug for players firing projectiles using gamepad analog sticks.

    Basically, I have a variable on each player that contains a playerID that corresponds to a gamepad. If the right analog stick is about a value, the player should fire at a set firing rate.

    The problem I've run into is that it only seems to work for the lowest-numbered player/gamepad. That is, if player 1 is firing, players 2-4 can't fire. If player 2 is firing, players 3 & 4 can't fire.

    Here's the event sheet below:

    <img src="https://dl.dropboxusercontent.com/u/14245368/firedelay_01.jpg" border="0" />

    Note that the playerShooting events are for testing purposes to see if an individual player is firing. It shows that they are, yet the issue with firing remains so long as there is a delay. If I remove the delay, however, all players can fire individually, so it's something to do with the "every x seconds" event, though I can't think of a better way to do the delay.

    Any hints or suggestions would be greatly appreciated. Thanks!