I've heard of it. If I remember correctly, AHK was built off of AutoIt, and greatly expanded. So I could be wrong, but I feel like jumping to AutoIt now would be a step backwards. lol

Damn, that sounds like it was a fun bot to make.

I've been tempted to get into the image search functions for catching collectibles that show up from time to time in idle games, but... I dunno I just haven't taken the time to look into it yet. I keep assuming it's a lot more complex than it probably is. How did the pixel-reading go?

I've recently been entertaining tangents away from my main projects with AHK, and it always gives me such an interesting sense of delight. It's hard to explain.

The first serious tool I made with it was a controller-to-mouse script, which I ended up spending months expanding and tweaking... It can now copy and paste text, manage windows, play music, navigate web browsers... I'm considering adding xinput dll calls, just so it's more globally accessible. Plus, it's another fun thing I could add.

Recently, I added mouse aiming to Titan Souls with an AHK script, and without making it "point and click" aiming. It's pretty sensitive and weird, but it works as a great proof-of-concept, and I'll likely use it in my main project, once I decide to add Kb/M controls.

My current project is an autoclicker (Now that we have Adventure Capitalist and Clicker Heroes on Steam). With this, my goal has been to keep it as non-intrusive as possible. As such, you can leave it running, clicking away in a background window while you're in another. You could play another game and have it keep counting up clicks. In fact, you can still navigate the application it's clicking in, with minimal interruption.

So yeah. I've been busy on a bunch of tangents. And I know AHK really isn't a great scripting language (The lack of actual arrays alone is off-putting), but it feels like an "easier" form of programming. Something I can do when I'm exhausted from real work, without really leaving the realm of code.

I'm sure other people have made scripts with AHK. What are some thoughts on it? What have you done with it?

Yeah, I just noticed that myself. :D

So much prettier... lol

Hmm... I have an idea about the respawn. Resetting the health is the first thing you do, and then you wait for (respawnDelay) seconds, until repositioning the player. This could mean that, if you die by falling in spikes, then your health gets reset to 100, and then for the duration of the respawnDelay, you're taking spike damage every frame. So once the player position is reset, you've already been drained of health.

This is just a guess, but what if you move "healthSystem.resetHealth();" to after the yield?

Code:

public IEnumerator RespawnPlayerCo()
{
    player.GetComponent<Rigidbody2D>().velocity = Vector2.zero;
    other.GetComponent<AudioSource>().Play();
    yield return new WaitForSeconds(respawnDelay);
    player.transform.position = currentCheckpoint.transform.position;
    healthSystem.resetHealth(); // <-- Put it here
}

The "Scale = Mathf.Floor(health / 10) + 1" equation (The +1 is important) shouldn't be interfering with the health itself at all, cause it never sets health to anything. Are you getting health and taking damage at the same time, or do you die just from the health draining every second?

Also, it looks like you've essentially modified your Update() function to check every second? It's only after the second has passed that you even run CheckHealth(), or check to see if the player died. Maybe try pulling these checks outside of the timer, so that you check for updates every frame, but you can still keep the incremental loss of one health every second. That alone may fix some things:

Code:

void Update()
{
    timer += Time.deltaTime;
    CheckHealth();

    if (health <= 0)
    {
        levelManager.RespawnPlayer();
        respawn.deathRespawn();
        health = 100; // Also to note- This won't be necessary, cause you're already resetting the health in the respawn function.
    }

    if (timer > 1) // has 1 second passed?
    {
        text.text = health.ToString();

        health -= 1;
        timer = 0;
    }
}

Regarding the clamp, you would add it around that other equation, like so:

Code:

void CheckHealth()
{
    if (isPlayer)
    {
        Scale = Mathf.Clamp(Mathf.Floor(health / 10f) + 1f, 1f, 11f);
        transform.localScale = Vector3.one * Scale;
    }
}

Hmm... I'm a bit confused by a couple things.

In your Update loop, you check the health every second, and then decrease it by 1? So if that changes the scale, it won't update until the next second passes. Also, you call the respawn functions, but I think to tackle the issue of why respawning kills the player immediately, we'd need to see the LevelManager.RespawnPlayer() and RespawnManager.deathRespawn() function declarations.

You could also clean up your CheckHealth() function a bit. All of the ifs can be condensed to a single equation, and you wouldn't really need to check if the scale's the same as last check, either:

Code:

void CheckHealth()
{
    if (isPlayer)
    {
        Scale = Mathf.Floor(health / 10) + 1;
        transform.localScale = Vector3.one * Scale;
    }
}

If it's important to keep a max limit on the scale, you could clamp the whole thing:

Code:

Scale = Mathf.Clamp(Mathf.Floor(health / 10) + 1, 1f, 11f);

Edit response to your edit: Hahaha, no worries. Everyone's here to help everyone. It's pretty awesome.

It gets interesting. when the hinge joints are stretched tight, they start shaking pretty violently. I've noticed that if you keep the size scaled down, though, these fluctuations don't transfer to the line renderer as much, so with small enough hinges, you might get a slight vibration in the cord. From the research I've done, I haven't found any solutions for this vibration, as they seem to be rooted in Unity's physics engine. So to fine-tune the cord, this method may not work out. But for fast development (i.e. Ludum Dare), it's a surprisingly solid solution that can be thrown together in minutes.

The other interesting thing that happens is, if the cord is stretched tight around a corner, it will generally wrap around it properly. But at a point, once the tension is high enough, it'll snap and shoot through the wall. I don't really have a solution for that, but perhaps just measuring the total length of the line (via sum distance between each joint), and locking joint positions if the resulting change puts it above that length, would take care of both the wall-jumping and shaking, since I imagine that would prevent putting stress on the joints, as well.

I may try this out, cause that would be a pretty simple code addition.

I'll probably go more in-depth and post gifs at a later date, but I seriously just got home, and it's nearly 5am. I hope this post is at least as coherent as I perceive it to be. lol

Ohhh, that ISN'T supposed to be there? It does look neat, though. lol

But it's neat we were thinking the same thing. This sounds fun!

Which part is the mistake? Looks like a pretty solid mechanic to me.

I like the way you think.

Well, I'm genuinely confused. I'm assuming you're not supposed to be able to dash like that indefinitely, but given the little area showcased there, I'm not sure how you'd get through it without multiple dashes.

And I think that could be a solid mechanic. You could have some hellishly difficult spike mazes, requiring a LOT of dashes like that, with brief areas of flat ground to touch down on and take a breather.

For Ludum Dare #32, my group built a game around the idea of using a game controller as a weapon. With it, you could plug into patrolling guards and move them around- At least, as long as your cord reached. A big part of this was designing how the cord itself behaved, so I decided to detail how I made this work.

It's really, really simple, but I'm really happy with this solution- All it is is a string of massless hinge joints, without sprite renderers, feeding each of their positions into a linerenderer. The result-


See the full post here.

Regarding the respawning killing the player, do you reset the health before checking it again?

The code you posted looks like it's all just for the scoring (Hence the ScoringSystem class), so I don't see any health value, or anything calling any respawn-related functions.

This is absolutely fantastic. It isn't something I've ever really thought about- I usually just fumble around with the numbers until I get the effect I want.

But this is really coherent. I'll probably be coming back to this before too long.

[HARDWIRED - Controller Beats All]

HARDWIRED - Controller Beats All

First game I've made with a group of people, and considering it was the first time most of them made a game, I'm generally happy with how it turned out. The 72-hour time limit ended up being the most stressful on me, since, as the only programmer, I had to build an AI system from the ground up, with pathfinding.

I have never even touched pathfinding before, so as stressful as it was, it was a fantastic experience to develop.

The major issues were from the tile editor we used- Tiled. The program itself is definitely nice. No complaints there. But in porting the resulting .tmx file to Unity, it places all same tiles in the same mesh, meaning for a top-down game, I can't just use Z-layering. So I did the best I could to layer things properly, using a shoddy hit-detection system. The other issue was that the collision data of the map ended up skewed in-game, resulting in odd areas where NPCs could get stuck. The only way around this would have been if I personally went through and touched up every polygon...

But the massive setback was that it took TWO AND A HALF HOURS to import the .obj from the map, containing the meshes. So every time we updated it, that's nearly three hours of programming I miss out on.

BUT despite all of these hazards along the way, I'd say it's a decent product, nonetheless. More information about the game, and screenshots, are included on the LD page.

^{http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=53099}

It's on Android now! I updated the OP with the details.

[Now available on Android!]

Now available on Android!

I ended up putting in a good deal of work to turn this into a comfy mobile game, complete with color customization! I also changed up solo mode, made a couple graphical tweaks, and spent a good while getting the touch controls to feel smooth and simple to learn. That being said, there is a bit of a learning curve, but I believe it feels pretty great once you catch on.

You can watch the promo video

(Disclaimer: I make games, not videos), and you can buy it for $0.99 on the Play Store here.

Any and all support would be greatly appreciated!

Circular - Pong in 360 degrees

In preparation for Ludum Dare #32, I decided to participate in the current Mini, but giving myself the same time restrictions that the main event will have. As such, here's a Pong game made in 48 hours, using Unity. I consider the game done, but I've had a handful of people requesting a mobile version, and I think it'd be a fun test for myself, so I'm working on getting it to Android as well.

I know it isn't the most original idea regarding the Pong theme, but I'm pretty happy with the overall presentation of it, mix of gamemodes, and art style.

_{(Link to the game is in the image.)}

Huh... Well, nevermind this, then. After a bit of testing, everything seems to work just fine. So I'm not sure if something really weird happened, or if I just got some bad information from the guy, or what.

But yeah. Xbox One works fine with XInput. lol

Seems like you're just as confused about this as I am. lol

Correct, Unity does not support XInput by default. Maybe that's different in Unity 5 now, but I haven't updated yet. I was also thinking that XBox One controllers worked with XInput, but from the bit of research I did, it seems that (At least interfacing with Windows) it uses Windows.Xbox.Input, rather than XInput. I could be misinterpreting something there, but the fact remains that when my friend presses his 'Y' button, Controller.Buttons.LeftShoulder returns true. So something's amiss.

I've been working with a group on a simple 2D fighting game in Unity, and for controller support, rather than use Unity's own detection (Which doesn't seem to be able to differentiate between triggers), I opted for xinput. So with a bit of searching I found this c# wrapper (XInputDotNet), which has worked pretty nicely for me so far.

One of my friends in this group, though, only has an Xbox One controller with which to test the game out, and his Y button is registering as LB, and his right analog has no input at all. I sent him the sample script that came with XInputDotNet, which shows the input values for all buttons and axis of the connected controller, and I'm just waiting for him to get back from work so that we can start figuring out some solution.

Now, there's no way this issue hasn't come up before. With both Unity and the Xbox One rising in use, I'm sure someone must have a solution to this. Anyone have any advice?

Back when I was in 8th grade, I actually made a flash game for a math assignment, teaching the player various algebraic stuff through an RPG structure. I distributed that via the packaged Flash Player .exe, as you mentioned. Aside from that, I've used Flash pretty exclusively for web browser games, since it isn't stable enough for larger scale (standalone) games, and with the headaches I've had to deal with, I don't trust it enough to develop for mobile.

I've wanted to switch over to Unity/C# for some time, now, and a couple months ago, I finally did. The environment takes a good deal of getting used to (from Flash), but you can do so much more with it. It's amazing. Plus, you can build directly for mobile devices, so while I may be somewhat biased on the topic, I feel like it's probably the best entry point to mobile distribution.

Hopefully you'll get a reply regarding Flash development on mobile, though, cause that just sounds like a nightmare, personally. I'm curious if that's actually not the case at all. lol

Hopefully, I'll start getting more active on the forums (again... I come and go), so I'll start here, since the "Happy Programmer Room" is the exact place I belong right now- I've got a group!

For the first time since I started my gamedev career 5ish years ago, I no longer need to worry about designing sprites, or music, or dialog choices. As the sole programmer in a group consisting of three artists, I now have completely free reign over the turn-based battle system in our RPG, the spellcrafting system we'll be implementing (and absolutely everything else), without ever needing to worry about the non-code sides of things. It feels great.

The game we're making will have a pretty strong 'Chrono Trigger' feel to it, with some 'Dragon's Dogma' elements in the story, combined with art inspired by 'Sword Art Online.' I'll probably start a devlog once there's actually something to show, so it's a bit early for that, but... I had to say something...