I think the new UI bits looks great! Good job!
Also thanks for the camera script!

Thanks The script isn't much, but hopefully it can help some folks that might be hitting the same problems with pixel perfect games as I have been.

Another method of snapping everything to the pixel grid that I might experiment with is detailed in this blog post https://ocias.com/blog/unity-pixel-art-camera/, Alex snaps all the geometry in a shader. A friend has been having some good results with this, so it sounds promising. I'm still not sure it can be 100% fixed though, just due to the nature of follow cams and loose lerping

This game... It tickles all my nerd senses   Keep it up.

Hehe, thanks!!

Loads of bug fixes done this week, and some more work on those UI tweaks

The best bug I've squashed this week was one that's been annoying me for a while. When the camera follows objects in cutscenes, they tend to jitter a bit



After checking over all my code I determined that this happens in cutscenes and not during gameplay for a couple of reasons. Firstly because the movement speed of the object is usually slower which causes the camera to catch up with the object quicker. And secondly because of a rounding error, this is the main culprit. What is happening is that the player moves a pixel and it apparently takes the camera a frame to catch up. Here you can see it in slowmo...



At higher speeds this isn't really noticeable as the amount that player moves between frames causes the camera to always move too. But at lower speeds the rounding issue comes in to play. We round both the position of the player and the camera to whole numbers so that we render all nice and pixel perfect-y. But sometimes the camera position does not get rounded in the same direction as the object it's following, so it can be a pixel behind.

Here's our simple code:

Code:

Vector3 virtualCameraPosition = Vector3.SmoothDamp(CameraTransform.position, targetTransform.position, ref Velocity, Speed, MaxSpeed, Time.smoothDeltaTime);
CameraTransform.position = new Vector3(
    Mathf.Round(virtualCameraPosition.x),
    Mathf.Round(virtualCameraPosition.y),
    Mathf.Round(virtualCameraPosition.z)
);

We can improve this by caching our previous camera position and then working out if we should round up or round down, depending on which direction we're going

Code:

Vector3 virtualCameraPosition = Vector3.SmoothDamp(CameraTransform.position, targetTransform.position, ref Velocity, Speed, MaxSpeed, Time.smoothDeltaTime);
CameraTransform.position = new Vector3(
    virtualCameraPosition.x > cachedCameraPosition.x ? Mathf.Ceil(virtualCameraPosition.x) : Mathf.Floor(virtualCameraPosition.x),
    virtualCameraPosition.y > cachedCameraPosition.y ? Mathf.Ceil(virtualCameraPosition.y) : Mathf.Floor(virtualCameraPosition.y),
    virtualCameraPosition.z > cachedCameraPosition.z ? Mathf.Ceil(virtualCameraPosition.z) : Mathf.Floor(virtualCameraPosition.z)
);
cachedCameraPosition = virtualCameraPosition;

This is much smoother, but still not perfect. So if you have any tips to improve it further I'd love to hear them!

To finish up, here's a couple of screenshots of new UI bits, not super exciting i'm afraid:







I've unified the header with the player info, and the footer with the button help across all screens. As well as updating all the sliders to look a bit fancier

These next few days are going to be all about testing the build and fixing bugs as I've introduced a bunch of stuff in the last few weeks that I've not tested all the way through (portraits, new ui, battle backdrop stuff etc).

Cheers!

Thanks orzlab! :D

Cool, glad that was encouraging. I worked on Jack Move for a few years (first post in this thread is 2013  ) before I had enough savings etc to quit my day job and be able to contract people to help.

I've not got any plans for a crowdfunding campaign just yet, I'm looking at some other sources of funding to finish the game at the moment though

Cool! Sounds like you found people from all over, just from being involved in things. That's awesome.

So are they working on a commission basis where you keep creative control, or is this a group effort type of thing where they'll benefit from the end product?

I guess I'm curious because I'm wondering how I want to proceed with my project. Programming and music are not my strong points, so I feel like I'll need help with those, but I don't have money to hire anyone and I don't know if it's realistic to expect anyone to work for revenue share without having a pretty big hand in the creative decision-making. I'm open to sharing control but it would have to be with the right partners, you know? Is Jack Move a personal passion project for you, or something you feel comfortable changing for the sake of your collaborators?

I pay folks for their time as and when needed, but hopefully I'll be getting people onboard for longer stretches soon, I'm not sure what deal we'll work out in that case.

This means that I currently retain full creative control, however I'm always open to suggestions. A lot of the way that battles are animated etc is down to Joe suggesting ways of taking effective shortcuts to cut down on animation etc whilst still retaining a good feel etc. For example, rather than the player/enemies running towards their target they just have a single "scoot" frame. As the scoot is quite a dynamic pose it still gives a nice sense of movement whilst keeping the amount of work down.

I'm not sure what I would suggest in your situation. Is this a business venture you will be collaborating on, is this just for fun? are you expecting to make money? Each comes with different levels of expectation for both you and any potential partners, and require different commitments.

My personal opinion is that if it is a commercial project, and unless everything is split down the middle 50/50 (ie, you are both/all investing an equal amount of money), you should be paying people.

If it's not a commercial thing, then it's probably gonna be hard to get people to actually do any work, even if they do get on board etc. It sometimes works, but often life can just get in the way. Sorry if that sounds cynical.

Hope that's useful

Forgive me if this has been answered already, but I'm curious about your team. How many people do you have working on this, and how did you originally meet or approach them to work on Jack Move?

Currently it's just me working on Jack Move fulltime, but I've been working with freelancers etc...

...Gary Lucken and Joe Williamson on and off. They have done all the character design and animation. I was introduced to Gary by some friends, and Joe I found after seeing some of his work show up on my twitter timeline.

Music is by Fracture, I've known Charlie for years, back from when I used to make music myself!

Sound design will be covered by (bafta award winning ) Adam Hay, who I met through the local Brighton games scene.

I've also been working with Ed Fear on story stuff, who I used to work with at Mediatonic

Man, this is looking amazing! The battle animations are very impressive. Nice stuff!

Thanks!! :D

Took a little time yesterday to implement some of the UI that Joe had mocked up the other day...



We'll do another UI pass in the near future I hope

I love those portraits, they have a lot of personality!

Thanks! Gary and Joe are the best!

I also like your solution to handle a range of resolutions without compromising the pixel art or resorting to letter boxing. It's pretty cool!

Yeah, I really want to avoid letterboxing. There's no real need to do it, but it does mean that all the artwork has to support those resolutions. I've taken the resolutions from the Steam hardware survey to work out what the range is, then I can work out what those will be when scaled and end up with the smallest res i need to work to, and the biggest.

I just think the health and data values are very small and a bit hard to read. They should pop out a little more since they're pretty important.



Maybe something like this?

Thanks for the feedback. Eventually I'll get round to redoing some more of the UI, as mentioned. When it's zoomed up and at 720p or 1080p (3 or 4x) it's actually much more legible, especially after the last round of UI changes where I bumped the smallest font size up by 1px

This game look sliiiiiiiiiiiiiiiiiiick. Can't wait to try it.

Thanks! :D

Hey folks,

It's been another busy week on Jack Move. Some more optimisation stuff and some cool new bits to show. It's a big post! :D

On the optimisation side, I knocked up a script that builds meshes for items and then combines and saves them. Here's a bunch of code for that, you might have to edit a bunch of stuff to get it working and I've not had time to clean it up. Hopefully it's self evident what everything does though. https://gist.github.com/empika/f1ec6735b1959738e79c30c6d88088ae

After combining a ton of objects in my test scene I've managed to get the draw calls down from ~3000 to about 150 or 330 with ambient occlusion turned on, which is pretty awesome. I've had Jack Move running on my iphone 5s at a pretty solid 30fps :D

Gary has been doing a few days on and off over the past month, working on some dialog portraits. This past week Joe had some free time to finish those off with all the expressions needed. They've turned out suuuuuper good <3 <3 <3



It's been really fun getting them in game and deciding which portrait to use for each line of dialog. I have a certain tone of voice in my head when I write stuff, but given a limited amount of emotes to accent the lines with has made me change the way I thought certain lines read. I'll be expanding the amount of portraits in the future, so can hopefully cover all eventualities

Here's an in game gif:



Lastly I've been working on setting stuff up ready for Joe to do some work on the battle backgrounds. Originally I was just going to remove the top section of the grid and replace it with a static image



A few months ago Joe had suggested doing something a little fancier involving adding some items around to give the battles a bit more depth. He brought this up again earlier this week and sent over a quick mockup. So I spent a bunch of time working out how to translate that mockup in to an actual workable system



Uh huh. That UI is awesome, but no time for that right now! Hopefully in the future

The main issue with something like this is that I have to deal with varying screen widths, from tiny 320x240 (smallest) to super wide 688x310 (biggest). The obvious answer is to anchor things in the UI to certain percentages across the screen. This is something I already do with the player and enemy positions, so that was what I tried for my first attempt.



It looks pretty good, but it was quite difficult to easily see how this would look at different resolutions, bar iterations of playing the game and adjusting things little by little. So I rolled up my sleeves and got to work on some tools that would allow me to do that.

Battle scenes are composed from a number of layers:

* The backdrop, which is a worldspace canvas. This allows me to place things on screen using RectTransforms, rather than just normal transforms, and still shakes everything with any screenshake.
* The world. Noa, our player character and the enemies.
* UI, a screenspace canvas.

(There's actually a bunch of other stuff for rendering the background grid floating in the scene too. This is just a ton of animated line renderers and some cameras that render to render textures.)



(Ignore the "no cameras rendering", I just turned off the main fullscreen rendering UI (which takes the 1x size output and displays it at the full display resolution) so it didn't get in the way).

The main problem with testing within this set up is that the worldspace canvas just has an arbitrary size. In order for it to layout correctly we need to set the same size as the UI screenspace canvas that gets automatically updated when you change the size of the game window. Surprisingly the way to do this is not call Screen.width/height from your editor script (because that obviously returns the width/height of your inspector window!!), but to call Camera.pixelWidth and Camera.pixelHeight on our main camera. Once this was figured out, setting the canvas size was pretty trivial and I could set the anchors of background elements and preview them pretty easily.

The next "problem" I hit was that I wanted to be able to see the player and enemies in position also, this lead me down a long and wacky path of being able to do this in game too. Here the issue was that whilst it was pretty easy to be able to reset positions of the actors when they are stationary, it's not so easy when they are halfway through an attack or are in the process of moving in or out of an action. The answer was to put everyone inside an anchoring container. The anchor container would be the one that would get repositioned, and the actor would rest at a local position of 0,0,0. As I never anticipated this kind of thing, a lot of my movement code uses world position to work out where to move to. This now needed to be translated up and down from local to world and back to local positions. Not too bad once I figured where the issue lie.

The only bug I have left is that I use DoTween for movement, it's a fantastic library but once you set and play a sequence you cant change it's values, which results in actors ending up in weird places if the resolution is changed mid move. This isn't so bad when moving towards the target as they'll end up somewhere in the right direction, but moving back means they'll be in completely the wrong place when they come to rest. My quick fix here was just to check if the local position is 0,0,0 when they're done, and if not then just force them to that location. In reality I don't think you'd really notice too much.

Here you can see the elements as they would look at 320x240



...and at 688x310



Notice how they are anchored to a certain percentage of the screen width. So the wider the screen, the more of the element gets shown

The last piece of the puzzle was just hooking up some data objects to hold references to the images for a "backdrop set", which then gets set on a random encounter area and then passed into the battle scene to be set up :D

I can't wait to properly set the proportions of all the elements and get some proper art work in there, as it give the battles so much more depth.

I hope that was interesting and that I'm not teaching people how to suck eggs!

Till next week

Hey everyone, time for another update!

This week was a bit of a funny one. Last Sunday I sat down with a friend to work out why I was getting a little frame hitching and she helped walk me through the unity profiler and frame debugger, which was super useful. I kinda knew how to use them, but didn't exactly know what I was looking at and what the numbers should be doing. Another reason for wanting to do this was because I'd like to know how easy it would be to port the game to consoles.

Soooo, I've been a long optimisation journey, trying to get the damn thing running on my phone at a decent framerate. I'll go over the issues I had and the steps that I've taken to get that kinda working, specifically with regard to drawcalls and garbage collection. Apologies for the wall of text!

Firstly garbage collection. Here are some things you shouldn't be doing every frame:

Concatenating strings in any way! In Jack Move I store calculate the direction the player is facing and store that in an enum that I then convert into a string/trigger for use with the animation system. For whatever dumb reason this was happening every frame, so I fixed that code to only fire if the animation state should change. I also pre-cached all the animation triggers in a big list that I could then use to lookup via the enum and get the actual trigger string, no more concatenation.

StartCoroutine also creates garbage, so don't do that a whole bunch. I had some really old code for flickering lights that does this, where the code should really just be in the coroutine itself.

Drawcalls were my main concern, initially I was somewhere around 3000 calls in a well lit area. The main things I've done to combat this are turning off SSAO , baking the lighting,  converting all my tiles to meshes rather than SpriteRenderers, and then batching them myself. I think I'll be able to turn SSAO back on at some point with a few more tweaks. Each of these things is not the greatest on it's own, but when combined has given me a huge boost. I'm down to 380 calls in a well lit place (without SSAO), and that's without having lightmapped and batched all the scenery objects yet

Lightmapping should be a pretty easy one, you turn it on, mark some stuff to be lightmapped and set your lights to be baked, then press the button and unity generates a bunch of textures that get overlaid over everything, instead of having to calculate the effect of lights in realtime. For example, a single tile with 2 lights would generate 3 drawcalls for realtime lights. 1 for the tile and then 1 for each light. Using lightmapping would result in just a single drawcall! So I have a million lights and a million tiles which results in a lot of drawcalls, lightmapping is going to save me a ton of work here.
However, we have a problem, the sprite renderer I use for my tiles does not support lightmaps. Well, kinda, the stuff for lightmaps is there, it's just not exposed for easy use. Some kinda soul has figured this out though, and posted it up on github (https://github.com/lassade/Sprite2DBakedLighting). This worked super great, although I had one issue where the textures would disappear in the editor, but this was quickly fixed (https://github.com/lassade/Sprite2DBakedLighting/issues/2).

So next up is batching all the tiles. Unity can be good at batching drawcalls dynamically, but it can also be pretty bad. So for every tile I had displayed unity was not batching them, resulting in many more calls than necessary. I wrote a little thing that took the meshes lassade's Sprite2DBakedLighting generates and combined them in to chunks of up to 16 (4x4) for each layer of floors or walls. The only problem I had here is that I'm still using materials in the same way as sprite renderers do, using a MaterialPropertyBlock to set the texture on a material used in multiple places. This would result in textures disappearing in play mode. So I just added a bit of code to my tilemap importer to reset the texture on the MaterialPropertyBlock at Start.

Oh, the other main gotcha I had with combining meshes for use with lightmaps is that you need to call Unwrapping.GenerateSecondaryUVSet(mesh) on the new mesh after you create it, otherwise the lightmap looks bonkers.

Turning off SSAO should be pretty obvious, fullscreen effects can be pretty intensive. If I turn it on now it brings my calls in that lit scene up to about 740, around double than without it. Which leads me to the last thing I need to do... optimise all the scenery items in the scene. All my objects are just made of multiple 32px tiles, eg a lampost is 3 tiles stacked on top of each other. These can all be way more optimised if I split the sprites into 1 big 32x96px sprite for example, but that's just a pain, I like to work with a grid of 32px as it's easy to slice them and work with (even if the tools in unity are there to slice them a bit nicer). So instead I'm going to take the mesh batching approach and to the same thing I did with tiles. Once an object is created and finalised, I'll just bake it into a single mesh, then it too can be nicely lightmapped and use fewer draw calls

I'm by no means an expert in this stuff, but feel I've got a pretty good handle now on doing wacky stuff with unity 2d it wasn't really designed for, so happy to answer any questions.

This coming week Joe is back on the project to finish the character portraits that Gary has started. Hopefully I'll be able to share those next week :D

Cheers

Hey folks!

Been a couple of weeks since I last updated. I had a week off in sunny (rainy) Cornwall, spent some time with my family and got some well needed fresh sea air!

Since the last update I've been working more on that art pass, trying to get things a bit more consistent. I won't show a ton of things, but the thing I'm most happy with is the cars in the scrapyard.



And here they are in game...



You can see the silver car still looks crappy there. The sprites are too noisy, that dither doesn't look great and doesn't match the rest of the game.

The other big thing I've worked on is adding distortion maps to the rain drops on the ground. It's a simple effect but looks really cool.

Here is my first attempt. It looks ok but the rain pools are super dark and the animation isn't great:



Here's the revised version. I added a brightness control to the shader and reworked the animation to make the pools a bit smaller.



There's not much to distort in the city, so heres a gif of the town where you can see it better on the tiled roof and around the yellow lines on the road...



I used the same shader I used for the heat distortion on the burning barrels. It was created by the excellent Minions Art (https://www.patreon.com/posts/quick-game-art-8172058).

Other bit's I've been working on include a screenshot button (much easier to grab a proper shot from within the unity editor window now), some dialog, reworking the battle tutorial text and refactoring my rain particles just to use unity's default particle system stuff now that I figured out how to do pixel perfect particles (still fun to say!).. see this post for more details on that.

I also did a little play testing at the local indie dev meetup I help run on Wednesday. I got some super useful feedback and found some good bugs so will be trying to implement/fix those bits over the next week.

Have a good weekend everyone!

Oh, I should probably say what I'm gonna do this week. (Writing it down helps me actually do stuff, rather than just do whatever is the most fun hehe).

So this week I'm concentrating on rewriting a bunch of dialog, getting it up to speed with the revised version of the story. Once that's done I'll go in an reimport all the strings and rework the cutscenes to add or remove dialog and actions as needed.

I've had some fantastic help with the story from an old colleague, Ed Fear, which has been great. Ed has really helped shape the plot and characters, their motivations , why stuff happens etc, and asking some really hard questions making me actually think about things properly rather than just blindly writing junk.

We've got the basic outline down, I think it's now a case of going in and filling in the gaps and fleshing it out. Once it's in a bit better shape I'll share a synopsis

Fantastic progress! Battles especially look incredible compared to what I remember of the original screens/gifs. Good job and keep it up 

Thanks dude! Progress feels a bit slow at the moment, but looking back at these devlogs is a good reminder that things are getting done

Hey folks,

This week I finished of that UI stuff which is good, then I went and saw Blade Runner 2049, two days in a row. I am absolutely in love with that film. The look, the feel, the story *chefs kiss*! It's not without it's issues though. How women are treated and it's lack of racial diversity to name a couple... but then again maybe that's commentary on the current climate (although that theory is a bit of a stretch). Despite those flaws it is a mesmerising piece of film, go and see it!! The best thing is that it has really invigorated and inspired me.

Sooo, I spent a lot of the week doing an art pass on a lot of my tiles. Firstly simplifying them, there were too many colours, they were too busy and in a bunch of places this was really inconsistent (eg, I've stripped all that ceramic tiling down to just two colours). So I went through, redrew a lot of them and also create a bunch more in order to make things a bit more sci-fi.

I wish I had before and after shots. (Also they're a bit dark :s)







I've also been working with Gary to get some dialog portraits. He's been feeling out the style but we're not quite there yet, so I'm not ready to show those bits yet, hopefully soon though

all of the interfaces shown here look incredibly tight and polished. the atmosphere of this entire project is set very well. keep at it.

Thanks!

Yo, I don't know how I haven't seen this earlier. But I def agree with flex that the atmosphere shown here is top-notch.

Cyberpunk is my favorite genre. And while I'm mostly meh on JRPGs, any potentially good cyberpunk story will get me intrigued. So that's where you've grabbed my attention and interest in this game. Please make it as gritty as possible, and don't pull any punches. This looks super fun. Not sure if there ever has been a cyberpunk JRPG before, and now that those two things have been said I can't get them out of my head.

I will for sure follow this project closely. Good luck!

Thanks a lot!! Some people would say that Final Fantasy 7 is cyberpunk, not sure I wholeheartedly agree though

Last (I hope) revision of this software install screen. Another friend suggested that I use a dotted line for the active preset. I think it works quite well. I wasn't sure if Unity would do a tiled + sliced image, but it does it handles the slicing just fine when you set the image type to tiled

Here's yet another revision!



A friend suggested moving the "active preset" text inline with the buttons. I'd tried this yesterday but didn't like the result, it looked a bit weird with the joining line out on it's own (I didn't manage to get a screengrab of that unfortunately).

My friend also suggested that I could remove the "preset" text from the buttons themselves, I then I realised I could then just shrink them right down and move them up next to the RAM. It's a little more cramped but I think it's actually a little cleaner and give more room for the main thing, the list of software.

Hey folks!

Been trying to work out a better way of how to show which "preset" is currently active. Presets are different loadouts of software your have loaded in your cyberspace deck, they are useful for switching "jobs" quickly during battle.

Here's my first attempt at something better:



And here's another revision:



Previously I had a little star next to the currently active preset (you can see in the previous post), but this wasn't particularly indicative of being the current preset. I also tried changing the active preset button to white, but this wasn't great either, I think it was too much of a colour change from the rest. I think the new version is a lot better and removes any ambiguity, whilst retaining the ability to see which preset is active at a glance.

You might notice that I also updated the RAM icons. This was to show how much RAM it is possible to have, and also helps fill up that area as it was feeling a bit empty

I'm not a UI/UX expert but try to approach these problems with a sense of what problems the user might have with an interface and what information is important. If anyone has any thoughts for improvement, I'd love to hear them

Cheers!

Hey folks,

First of all here is a great guide on how to set up a pixel perfect camera in basically the same way I described (badly) in my last post:

http://www.returnofthebrain.co.uk/pixel-perfect-virtual-camera-unity3d/

I've been up to lot's this week. I had some great feedback from a couple of people so am slowly working my way through that.

The first big thing I worked on was getting dialog portraits working. Here's a little test:



Even just using stick men placeholders it adds a whole bunch of depth to conversations. I've shied away from wanting to implement this previously as it add a whole load more assets to the pile. But having looked at how other games have done it in the past, I've come to the compromise of ignoring portraits for npc's unless they are important. The upside, way fewer portraits to get done. The downside is that it might give away which characters are important later on, although I can tweak this as I go I think, only revealing portraits when necessary.

My initial implementation uses a bunch of scriptable objects with lists of sprites & expressions. However, I'm going to rewrite this and use a single image with a Unity mecanim animator on it, then I can just reference animation trigger names in my dialog. This will be much cleaner code and also give me the added benefit of being able to do a lot more with the portraits such as animating them (of course!) and adding effects or overlays for different situations.

The next big chunk of work has been another big UI overhaul. I've been trying to block out the feedback that the UI is way too green and hard to understand. I'm kinda sad that I was unable to stick to my guns on this one, purely because old green computer interfaces look rad, but those are all 30 years old and a lot weren't great then. I think the result is better for it though







You'll notice a few more colours to break things up a bit, and a bit of texture in the background.

New fonts! I needed to replace the main font I was using anyway (from an old website, and I was unable to find the author to ask permission to use it) so created a new one. I also replace the teeny tiny 4px font, increasing it to the much more legible 5px!

I've also tightened up a lot of the spacing and making everything much more consistent across the board. Let me know if there's any other improvements you think might be good

I've been reworking a bunch of the script too, giving our heroine a bit more motivation etc. My previous dialog was pretty goofy and didn't set the tone very well.

Lot's more to crack on with, a few more bits of UI work, more script stuff, and the overhaul of the dialog portraits

Cheers!