Shifty turns indie - "Adventures" family-friendly cooperative dungeon crawler

Thanks for the suggestion! I've incorporated your changes. It definitely looks a bit cheerier. Is that what you meant by it looking 'dark'?
 
Congrats on getting your game into Steam Greenlight, Shifty.

Hopefully you'll be supporting touch on Windows devices. Have been disappointed by some games that would obviously be touch friendly (either mobile games that appear on iOS/Android or PC games that would obviously be touch friendly) but don't support touch well. For example, instead of a tap registering as a "click" in many games you have to touch and swipe for it to register as a "click." Or a case where the game is touch friendly in everything except they don't provide a button to access settings or to quit the game. Instead relying on you hitting the ESC key despite the game never requiring keyboard interaction other than that one instance.

I was going to suggest posting about your game on the Reddit Steam Greelight page (https://www.reddit.com/r/greenlightquality/ ) but I'm not sure it gets much traffic.

Desura is also an option for an indie developer. Steam, however, is the holy grail with regards to potential sales. Assuming you can get noticed.

http://www.leveluplabs.com/

And his blog

http://www.fortressofdoors.com/

Developer of one of my top 10 games ever (AAA inclusive and this is an indie developer) shares a lot of his experiences both before and after he was able to get onto Steam. And what he's done to keep his game relevant on Steam (besides his game just being extremely good) and otherwise for over 4 years now despite hundreds and hundreds of games competing for a gamer's attention. He provides a lot of stats and talks about various things related to indie development and succeeding on Steam in a sea of indie programs.

Interesting reads both for developers and non-developers.

Regards,
SB
 
Last edited:
Here's a fortutious mistake : I've been updating control to be a bit smarter - characters with ranged attacks stop when in range of their targets, and if you select a target too far away, characters will move and then attack. Originally I had it so you could only attack when stationary. In the process of making the changes, I managed to break something so you can turn and attack while moving. I put it down as something to fix, but actually it allows a higher-level gameplay element as now you can strafe. It does mean you can retreat from an enemy and shoot backwards, which probably is too powerful and needs be gimped. But shooting while moving sidways is actually pretty cool for those who take control to the next level.
 
Strafe jumping was exactly that type of bug and it made Quake the game it is today.


Sent from my iPhone using Tapatalk
 
It does mean you can retreat from an enemy and shoot backwards, which probably is too powerful and needs be gimped. But shooting while moving sidways is actually pretty cool for those who take control to the next level.

Yup, when a bug actually results in a good feature. :)

Just do like many games do. When walking while shooting, reduce the speed of the Character. Forwards being fastest, sideways strafing slightly slower, and backwards being the slowest. It gives some tactical advantages while allowing creatures the ability to close in on the player.

Regards,
SB
 
Yeah, I'll factor that in. Course, now I need to rework my movement to actually do this for real rather than a bug! Which isn't going to be straight-forward. Actually, it's a bit of a bugger. How can you tell if a player wants to change direction and walk towards the target they're clicking, or carry on their current path and fire backwards? In principle I can have it so you only walk towards an enemy target if clicked from stationary and not within range.

The problem with advanced play is the average Joe. The input is currently designed around watching users, who literally click what they want to do. You've one input mechanic - what did they press - and have to get the right response or else the game won't control well for them and they won't want to play.

I suppose what I've got now is a case of 'if the enemy is in range and you're presently moving, turn and attack. If stationary, move towards them. If enemy not in range, carry on your current path.'

Anyone see any problems with that?
 
Yeah, I'll factor that in. Course, now I need to rework my movement to actually do this for real rather than a bug! Which isn't going to be straight-forward. Actually, it's a bit of a bugger. How can you tell if a player wants to change direction and walk towards the target they're clicking, or carry on their current path and fire backwards? In principle I can have it so you only walk towards an enemy target if clicked from stationary and not within range.

The problem with advanced play is the average Joe. The input is currently designed around watching users, who literally click what they want to do. You've one input mechanic - what did they press - and have to get the right response or else the game won't control well for them and they won't want to play.

I suppose what I've got now is a case of 'if the enemy is in range and you're presently moving, turn and attack. If stationary, move towards them. If enemy not in range, carry on your current path.'

Anyone see any problems with that?
Maybe press and hold on an enemy starts a lock on said enemy. Pressing and holding is a common gesture so some people are used to it, and even if the average player can't manage, the default tap should get them through the game.
 
Yeah, I'll factor that in. Course, now I need to rework my movement to actually do this for real rather than a bug! Which isn't going to be straight-forward. Actually, it's a bit of a bugger. How can you tell if a player wants to change direction and walk towards the target they're clicking, or carry on their current path and fire backwards? In principle I can have it so you only walk towards an enemy target if clicked from stationary and not within range.

The problem with advanced play is the average Joe. The input is currently designed around watching users, who literally click what they want to do. You've one input mechanic - what did they press - and have to get the right response or else the game won't control well for them and they won't want to play.

I suppose what I've got now is a case of 'if the enemy is in range and you're presently moving, turn and attack. If stationary, move towards them. If enemy not in range, carry on your current path.'

Anyone see any problems with that?

That's probably why most games don't do movement with attacking. It's more complex to implement as well as requiring more balance considerations (when not using dual analog or analog + digital controls). So common in "twin stick shooters" but less common (almost unheard of) in point and click ARPGs.

Maybe press and hold on an enemy starts a lock on said enemy. Pressing and holding is a common gesture so some people are used to it, and even if the average player can't manage, the default tap should get them through the game.

That'd probably work out quite well. And then speed of player would be relative to where they are moving compared to what they are locked onto.

Press and hold can take a while (most people will press longer than they need to), however. So maybe a tap -> slide. It's quick and deliberate.

Of course, then you need a way to unlock target in case you want to just run away.

Maybe it's best to just fix the "bug" and put it back to the original way. :D

Regards,
SB
 
Rather than tap and hold or tap and slide. How about multiple tap?

Like those attacks in the world ends with you.
 
Steam Greenlight page:
http://steamcommunity.com/sharedfiles/filedetails/?id=681013324

Reveal trailer!

Sooo much time going towards promotion! Looking at Indiegogo, they recommend 60 days of preparation before the campaign even goes live. You need to accumulate email addresses well ahead of the curve, so need a landing page just for that purpose - http://adventures-game.launchrock.com/
Most of these cost money so limited options on a shoe-string.

Then there's creating and editing the video and updating pages and blogging and tweeting... And plans for more promo art and attention-seeking. Trying to get the game made is getting in the way of making the game. :runaway:

Anyway, what do you think of the vid? Any questions? If you're on Steam, probably best to ask there.
Great job on the trailer! My only complaint: The characters move too slowly. I supposed it's intended because of the genre of your game?
 
Yeah, it works okay in play. It's pretty hectic managing the party. I actually need some AI on the characters for less-able players.

Also I've recently learnt that isn't the Greenlight page. It's a concept page and doesn't really count towards anything. I need to create an actual Greenlight page, which I'll do when I have the new demo and trailer done. Which I'll have done when I can sort out my IT issues and network issues and many other things that stop any progress happening!
 
For those not following my Twitter :)nope:), demo is near completion, although there's a never ending amount of work that crops up. eg. For a the tutorial I felt it essential people could play together, which meant a means to have them together but learning the interface on their own. So I have a multiplayer level and had to implement locked doors to prevent local tutorial trigger events being called by the wrong player. Of course locked doors were going to be a feature anyway, but I'm wanting as minimal a demo as a possible. Had to add locked door, a mood responding door, a notification system, and a bunch of refinements. Then in testing today I find I still have to change the tutorial flow, and TBH I'm thinking the whole tute needs to be a bit reworked to be a bit more dynamic. But unless you have a listener system that responds to events dynamically, (you are low on health. Eat a cake), you can't really cover all the interactions in a way that teaches.

But today I'm deviating slightly to look at the aesthetic. On Twitter there's a Screenshot Saturday hashtag and it's very obvious that the pretty ones get all the attention. That's so Life! Hence I need another intended feature that bit early, I feel. Here's what Adventures looks like and what it needs to look like...

lightingUpgrade.png

There's no denying the changes are massively impactful and also add a gameplay element - you can change brightness for levels and have dynamic lights. Getting this working at speed on mobile might be the problem. If the default Unity lighting system can't cope, I should be able to just draw lights onto a rendertexture and blend over the top, possibly combine it with an intended glow post effect.
 

45 minutes from wanting this to getting a working prototype, which was mostly looking up stuff and thinking. Really easy solution! Create a camera that draws only light glow sprites, and attach a light glow sprite to every 'light source'. Render to a texture and draw that over the top with multiply blending. Job done! Just need to make it 'proper' and parametrise the light glows so they can shrink/grow based on stuff. Might add a life force influence
 
With lighting this soft, you could draw the light texture at 1/4 resolution for performance with no perceptible quality loss.
 
And this is where the tricksy nature of game development comes in! Creating that was a doddle. Perfecting it isn't so straightforward. Aligning a square quad and texture with a rectangular screen/viewport results in drift of the texture, and the fix is non-trivial to find.

So that's why it's taken me so bloody long to even get a demo together!
 
Back
Top