itch.io

It's not much, but I do have some video from the last time I had a rather large bug.  
Otherwise, yes.  Progress is just slow.  When my day job gets busy this is the first thing to suffer.  Thanks for letting me know some people are still interested!  Progress is still on going.

Thanks for the idea.  Honestly, I hadn't even heard of the itch.io client until this post.  I'll take a look and see what it's about.  I've been meaning to revisit this game and add a few things to it anyway.

Cybergrid is a retro-themed pac-man clone with a hacker theme intended to keep it simple with a style and gameplay that works.  

Use the arrow keys to move your cursor through the system attempting to collect all the dots and moving on to the next round.  Avoid daemons to stay in play.  Cross a glitch to make yourself invulnerable and destroy the daemons instead.  Capture bonuses for higher scores.

https://freeman74.itch.io/cybergrid

No chance!  This sometimes takes back seat to the paying work and family, but it will always be chugging along as I can.

When ever I think about how to get fun into something, I think about the video I'm linking here.

For me, key rule is the player has to feel in control.  That's how you get them to respect the system and be willing to over invest in it. (see video)   They need to feel like they're making the decisions on what's happening, and that their decision is informed enough that their choice has results.  Even one decision Run or Fight?  will add fun if the rest of the game is compelling enough to warrant making the decision.    If they don't want to explore the dungeon, they won't care if they run or not.  If they do, they'll think very carefully about the best way to approach that decision.  Which as I'm rambling here, the most fun part of combat is not combat?

 

Right?  When coding for the day job there's always some deadline imposed that it needs to happen by.  Doing this on my own always has me going "But I can do better... " and not wanting to just wrap it up because I know tomorrow I'll have an even better plan.

It took every ounce of self control to keep from scrapping my entire input routine yesterday because I realized I could make the code tighter.  No one would see it, no one would notice, and most of this will get reworked again in a few weeks, but I was putting off progress for vanity.   It's a hard habit to break when it's just you.

Thanks I need to be reminded of that sometimes.  I am working on getting it out there. I do know I do much better on deadlines when I publicly announce them.  The pressure is on then, and I want feed back on how this whole thing goes.  I'm excited for what's in store for it.  

I also need to do more with Git.   Ugh...   I've been putting that beast off for far too long.

Thanks,

Posting stuff like this is super hard for me.  I wrote a full on RPG a while ago.  Combination strategy & Resources management game and LARP (don't judge!).   I was in the final stages of it, after about 6 years of work.   I was just going through final polish when... one of my "friends" took a copy, reworded some of it, then copyrighted it as his own.  I had known the guy for over 10 years, and basically since he was a kid, and it's been a struggle to want to put anything creative out anywhere for anyone to even look at because of that.

Slowly getting over it, so hopefully this will help me get past one really bad experience.

Hey there!

Twitter is hard to give a good in depth reply to just about anything. 

Current code is working in that concept.  That there is a key press they player can redefine if they want, but there's also something to be said for having a comfortable default key layout.  For example the age old ESDF vs WASD.  As a staunch ESDFer I want to make that default, I just know better.  :)

That said.  You're right on me over thinking it for now.  I tend to get lost on such things easily, and dwell on details that don't deliver for the amount of time I spend on them, often to the point of tanking the project just due to time.

For this the enemy will occupy a neighboring tile.... and indirectly in the middle of typing this I think you just gave me how I'm going to handle it.

So, here's what I'm thinking.  Combat commences and in open tiles around the player 1 to 4 enemies might appear.  1-8 if I decide to use diagonals.  Fleeing will require a direction because if you're surrounded you need to fight your way out.   Moving away will break all combat to start, but this also could give me that partial end state where you get XP for killing a monster, if not all of them, but gold for finishing the fight.

It also keeps me closer to the path I want which is to see the enemies before they appear.    I have ideas for spells like ESP and Clairvoiance that let you see things in dark spaces, or other parts of the map based on where enemies are.

Thanks!

Semi-Update.  I'm currently working on the input again, and I'm seeing that Unity does not return what keys are being pressed, but you have to check if the key you want is being pressed.

This means that anything "waiting" for response has to be actively polling keys  rather than feeding it the key that's been pressed.

It seems subtle, but that does make the code trickier.

Thanks!  I've been messing with it for a while now.  I'm not going to dig into it tonight, but should be doing some coding Friday (if not sooner) I'll throw actual code up when I open it up again.

Not sure what you're coding in, but I'm using Unity, which helps a bit.  

On each Tile gameobject I have a SpriteRenderer and a custom class called Tile.

What that lets me do is figure out "OK, I want the torch to have a range of 3.  So all the tiles in the next square have an alpha channel value of their illumination * (distance from source)/3.   When I get more than source +/- range away I stop updating illumination values.   Initially, I set Illumination to a base of 1, but have been putting it at 1.25 because it looks better.

Now before I would then do a second pass on "Is this tile blocked from a nearby tile?" if so set alpha on the sprite to zero, otherwise set it to the illumination value stored in the Tile.   Circling out from the player object, but I'm going to start doing that as part of the alpha value pass so that I can set illumination targets other than the player and still have line of sight blocking objects block their light.  

The map controller would also have a base illumination value added to any tile in view.  So if you're outside, I could set it high, and dial it down towards evening, or in a dungeon just turn it off (as I did in the demo).

The upshot of all this is I don't have to create multiple sprites, or anything for different light values and I can basically have as many different shades as a c# float from 0 to 1.0 will give me.  Which is a lot.  Right now it only happens on my movement, but if I get ambitious, I may add a torch flicker for some extra style.

I may go back later and add a shader to the sprites that lets me kind of pixelate them out as well as shade them.  I think that will give more of that old school feel.  Eventually anyway.  Right now I'm so eager to be done with lighting and move on to ANYTHING else.... 

Thanks!  I'll take all the advice I can get.

I have a grid that flags a tile if it's "Blocking" or not in a 2d array.  I'm not thrilled with the performance speed wise, but since it lowered my FPS from 2000 to 700, I'm going to say "I'll worry about it if everything drops bellow 200fps."

Right now I have it so that the line of sight works spirals a check outward from the player each step to 15 tiles.  That more than covers the long way on 16x9 screens.  The formula to see what square to check is GetTileAt(Mathf.Abs(X)-(Mathf.Sign(X), Mathf.Abs(Y)-(Mathf.Sign(Y)).    This will always check the diagnal block closest to the player, and (oddly enough) deal with straight lines appropriately too.

What I'm really trying to decide on how to handle is what happens if you have multiple light sources?  Like you're approaching a campfire with a torch.  The obvious answer is "Add them together", but then lets say I put out my torch... how do I figure out which part of that luminosity is the torch, and which is the campfire?  I'm debating between:

A)  Do a 'negative illumination' function that gets called when a light source is put out.  And is my leading contender right now.

B)  Add all light sources on a tile to a list of objects ( List<GameObject> LightSources ) and add remove them when a source is added removed.

I feel like B is way over engineered now that I'm looking at it.  

I sometimes wish I wasn't doing a shaded value, and just did it Ultima style where things are either visible, or not.  But I feel like this really makes the cave spooky.