Spiludvikling.dk

I have been working for some years developing an online action RPG - Treacherous Journeys.
For long periods this project has been on the backburner, but now I have chosen to concentrate on the creation of a good demo, to form the basis for funding, possibly a Kickstarter project. I still need to put in a lot of hours though, and also a bit of money for art. So far I've only been spending money on assets and splash and logo art, but I really do want some unique main characters too. the last one is going to cost me I think
Right now I have an early tech-demo, and would appreciate feedback, if anyone wants to try it out. Just click "Demo" in the menu: https://treacherousjourneys.com

Gave it play!
Cute! Very classical ARPG on the generic fantasy side. Cool and all! The formula still just works!
Obviously it's very early days on the project. There is much much more to add. I guess building a team and proper funding should be high on your bucket list. If you >really< want to do the project.

I see the project can very easily balloon into a gigantic project for a solo developer with a bit of external art purchases. And you will just choke on it. So having the proper foundation with a super dedicated team will very likely be required.
Also not quite ready for the Kickstarter just yet.

On the small implementations side of things. Your mobs are clumping very heavily together. Standing inside each other while attacking. Should be a pretty quick fix.

Never found the spiders the guy at the campfire is talking about. I might assume they are not implemented.

Also good luck with the project!

Oh yeah.. also on Kickstarter. It's not thaaaaat great for digital games any more. Hasn't been for a while.
It might be 'okish' as part of a PR/Community building push. That will cost a whole lot of effort and focus. And should be very carefully considered.
And probably shouldn't be seen a large or main part of development funding.

On Kickstarter you should probably do a board game! Or some fancy hardware gadget.
This says it all!
https://www.kicktraq.com/hotlist/

Thanks for trying it out and giving feedback. You even made it to lvl 4
Indeed there is a lot to be done. I'm a little apprehensive about working with a team unless I have funds to hire them. Obviously that won't happen any time soon I don't think I would be able to manage working with another coder remotely, but a dedicated level designer / UI / art direction person with at least some Unity experience might work and could really lift the project a lot. I must admit that I'm more of a coder than an artist.
Community management would also be a big help - dealing too much with that would stretch me too thin. Like butter that has been scraped over too much bread - Bilbo Baggins.
3D modelling, concept art, website design etc. is easier to outsource.

You're right this project can grow pretty big if you let it - I try to stay away from the word "MMORPG" because I don't want anything that massive, although I do want to create a game where at least hundreds of players are sharing the same world (with hopefully only tens of people nearby at any time)
Limiting the scope is important - for that reason I decided early on to make a game that's actually 2D for all game-logic. All the server knows is that some objects with 2D coordinates and some attributes and behaviors are moving around on a plane. I also decided to not have local object avoidance / monster blocking. Unfortunately I saw immediately the same behavior emerge that you described - clumping. I'm afraid I'm going to have to reverse that decision and implement some local object avoidance after all - that's going to be pretty costly in terms of performance but I don't think there's any way around it (no pun intended).

You're right Kickstarter might not be what it used to be - I still see some games on different levels succeeding though:)

And yes, the spiders aren't in the game yet - this is just some stand-in text to test the dialogue system.
Oh and the guy is named Rosalind, just haven't found a good model for her yet:)

I have received some feedback from a couple of people - thanks jonaz.dk - and have implemented some of the points.

The cursor is now dynamic, changing appearance based on the object you hover on - sword for attack, bubble for talk, hand for grab etc.

Also I have implemented hover UI elements for mobs and items on the ground, showing the name, and also healthbar for mobs.

A minimap is being worked on - it needs a good shader to better visualize walkable area, and entities nearby must also be visualized.

With a little luck something might be happening with the audio before long - someone reached out to me who would like to compose some music for the game

The new build is live, and a client can be downloaded at https://treacherousjourneys.com/downloads/journeys.zip. Feedback is greatly appreciated as always:) It really motivates me and keeps me on track.

For the last month I've mostly been working on a single "small" feature: Local object avoidance.
I knew I really wanted to combine it with the pathfinding algorithm I was using, but I had no clear idea about how to do it. Finally I've got what I think is a pretty promising hybrid between pathfinding and steering. I'm a little irritated that it took so long to implement but at the same time I'm feeling pretty accomplished, even though there are still some small quirks to work out, and the steering code needs a bit of refactoring to meet my usual standards.
Performance has taken a hit as I knew it would, but there are many places where it can be improved so I'm actually still pretty optimistic that it will be possible to handle a good amount of players on a single server.
A small illustration of the difference between the old clumping behaviour and steering. Notice that the player on the new picture is actually overlapping a goblin - this is because I've only enabled steering for enemies - the player has walked into the goblin.


I haven't the game on my webpage yet, since I want to include some other changes too.

I am very impressed with your project.
It is very interesting reading your updates.
Please keep it coming!

Thanks:) Lately I've mostly been working on leveling up my level-building skills, and changing to Universal Render Pipeline (formerly LWRP) in Unity 2019.3 beta.
I haven't put this in the game yet but I have a feeling we'll be seeing more spiders soon, as Rosalind's dialogue seems to suggest.
With 2019.3 beta the old screen resolution dialog seems to be removed, so now I'm finally forced to implement a graphics settings window myself. I'll be upgrading my ingame UI from programmer art to a modular UI I bought at the Black Friday sale.

A quick pic of the visual style I'm working with now. The spider as well as the spruces are a bit too cartoonish for what I want to achieve but they'll do for now.

Didn't get much done in 2020 but finally picked up the game again.
One of the last things I did before taking a break was porting to URP. This year I've been working on implementing skills - basic attack is now also a skill and the first real skill - fireball - is now in the game.
After I wrap up the preliminary skill work I'll be working on the starter map, and I also want to make a cave.

Nice! Good to see development is back on track!

Also @Jesper Nielsen In your case I would not recommend switching to URP (universal rendering pipeline).
It's really under developed in my experience. HDRP has gotten all their attention at Unity.
Working on a project in URP currently at work.

Typical Unity style of delivering half baked solutions and then years later they (might) be ok.
If they don't forget about it.

Your screenshot already looks like a slight visual downgrade in rendering.

Perhaps in cases where realtime shadows are not important and using shader graph/vfx graph is. And mobile performance is critical you can make a case for it.
But otherwise either stick with the standard renderer and use Amplify Shader Editor if you need visual shader programming in the project.
Otherwise it's not that beneficial. And you will find a lot of shadow related artifacts.

Or go full HDRP if DX11 and above is fine. To get all the bells and whistles if you have time to use it to an extent.

Or maybe I'm just too picky.
And now that it is there you should just focus on getting more gameplay in instead of reverting commits.

Thank you for the comments Jonaz.
I chose URP because I want the game to be playable on PCs and laptops with integrated graphics.

When you say it's a downgrade I think you mean compared to the previous image? Both are actually URP (unless the first is LWRP - not 100% sure) The difference is that the second screenshot is more zoomed out, the directional light is weaker, I'm playing around with different shaders and the scale is a bit off on the terrain textures - in particular on the rocks.
Your comment about the shadows has me a bit worried though - I do need to have dungeons with torches etc.
I think I need to make that cave a priority to test it out before I invest too much time doing work that will take even more time to convert if URP doesn't suit my needs.

Yeah for low performance targets it could certainly be relevant.

haha yeah it's probably just the directional light playing tricks and making stuff look extra flat in the shade.

Yeah most certainly do some shadow tests in various conditions to see if it creates visual artifacts in your project. Perhaps it's fine for your use? Only you can know and judge.

Some issues related to the lights can only cast 1 sided shadows creating really nasty holes in the shadows. Or whatever it is. And some issues where there will be this very hard line between the the cascaded shadows because proper shadow masking is not supported.
And weird issues with shadows where there should be shadows and weird cut off issues.
Perhaps some things has changed in Unity 2021?! Don't know. The overall impression of shadow quality in URP Unity 2020 is just weak in my opinion.

I'm still on 2019 LTS.
It turned out I didn't have shadows at all... Or rather the terrain didn't receive shadows but meshes did. Also grass doesn't like casting shadows with the shader set to transparent - I use grass objects instead of terrain details or even worse terrain grass.

I also forgot to activate ambient light...
Lights on and a little love and it looks like this - still needs tinkering of course but good enough for a prototype so I'll leave it at that and go work on that cave.

Got started playing with the first cave and I'm happy I did.
You're right Jonaz point light shadows are not supported in URP yet - it's supposedly implemented in 2021.1b so I guess I'll have to update when they put out a stable release or drop URP because they're pretty much a must-have. Bummer.

Så kom den første 2021 version ud og jeg prøvede at opgradere fra 2019 LTS.
Point Lights er nu endeligt implementeret - det ville have været en absolut dealbreaker for mit spil hvis de ikke havde været der med alle de dungeons jeg skal have!



URP er stadig rimelig WIP - nogle af de shaders giver nu kompileringsfejl. Jeg kunne heldigvis erstatte dem med Simplelit uden de store problemer.
Jeg har også arbejdet lidt med at prøve at gøre mine klipper lidt pænere efter en kommentar fra min datter

Cool!
Lyder som om det hjælper på det.
En anden ting du kunne teste er hvor meget performance det koster at køre mange lyskilder på skærmen og om der er yderligere issues. Ved ikke om du kører forward eller deferred rendering?
Læste deres deferred implementation i URP skulle være lidt dyr da det er skrevet til at supporte en ældre hardware uden compute shaders.

Og forward har jo sine begrænsninger på max 8 antal aktive lyskilder i frustrum (tror jeg). Ellers bliver de slukket lidt random.

På nuværende projekt kører vi forward (indtil videre) og har lavet light groups der fade tænder+slukker ikke relevante lyskilder når man er i en trigger box. Håber vi kan skifte til deferred på et tidspunkt.

Det er i hvert fald være lige at overveje hvilken tilgang du skal tage hvis du skal lave store dungeons med mange lyskilder på skærmen.

Jeg kører forward rendering (går jeg stærkt ud fra - har aldrig taget stilling til det)
Point light koster kassen i framerate på en integreret GPU Ét eller andet siger mig at jeg ikke skal gå efter bløde skygger i lyset fra mine fireballs...
Jeg vil prøve lidt af hvert men jeg bruger min arbejds PC uden grafikkort.

Jonaz, jeg bliver nødt til at rette dig lidt. Jeg tror du blander forward rendering med fixed pipelines.

Bare for at gøre det helt klart, fixed pipelines var hvad vi havde før vi fik shaders. Dette system havde en grænse på op til maksimum 8 lyskilder (per frame), men hvis man var lidt smart kunne man slippe afsted med at flytte lyskilder og dermed genbruge dem, så 8 lyskilder var faktisk mange. Men denne grænse har ikke noget med forward rendering at gøre.

Forward rendering er blot en simpel men utrolig brugbar måde at renderer. Du kan i princippet havde så mange lyskilder som du ønsker med forward rendering men der hvor deffered rendering og forward rendering adskiller sig fra hinanden er at forward rendering binder en shader per objekt der bliver sendt til dit grafikkort for at blive vist på din skærm, hvor deffered rendering binder en shader til sidst når alle overflader som kan ses på skærmen er blevet renderet.

Forestil dig en simpel scene hvor en stor objekt dækker over en mindre objekt. Grafikkortet ved ikke på forhånd at den mindre objekt ikke vil kunne ses før begge objekter er blevet renderet.

Når grafikkortet har tegnet den mindre objekt vil shaderen og dermed belysningen blive beregnet, hvorefter den vil begynde at renderer den store objekt.

I det vi kun kan se den store objekt kan vi dermed antage at lysberegning for den lille objekt er spildt. På grund af at shadingen af en overflade først finder sted når alle objekter er blevet sendt til grafikkortet for deferred rendering, vil vi dermed aldrig komme til at bruge tid på at beregne belysning for overflader vi ikke kan se.

Men som sagt begge måder har ingen restriktioner af lyskilder. Deffered er på mange måder mere effiktiv men den kommer dog ikke uden problemer, så det kommer meget an på den enkelte situation, hvad der er bedst at bruge.

@ZeroHero
Tak for supplerende info! Jeg oplever bare issues specifikt i Unity med begrænsninger på hvor mange aktive lyskilder der kan vises på skærmen i forward.
Meget muligt jeg ikke har det helt kodetekniske overblik over hvad der sker i implementationen og på grafikkortet.

Jeg ved ikke hvordan Unity har implementeret deres forward (og for dens sags skyld deres deferred ) rendering. De har meget muligt bundet fysiske lyskilder med deres shaders, men der er mange måder at sende den slags informationer til en shader.

Man kan selvfølgeligt altid hardcode lyskilder i shaderen eller evt. bruge en texture til at indeholde lyskilde informationer eller en blot en matrix for mindre antal af lyskilder?

Jeg ved faktisk slet ikke om man kan ændre på Unity's default shaders eller om man skal skrive sin egne shaders?

Med hensyn til shadere i Unity så kan man sagtens skrive sine egne. Fx. Baseret på en variation af de eksisterende standard shadere eller helt fra bunden.

Nu om dage, lidt mere high level, findes der nu indbyggede graf baserede shader editors når man bruger URP eller HDRP setups.
Uden ultra detaljeret kontrol så vidt jeg er orienteret. Men en som mig kan godt sidde og pille lidt rundt og lave noget der ser rimeligt fornuftigt ud uden at være hardcore shader programmør.
Eller man kan bruge shader editors fra asset storen. Til den gamle render pipeline.

@ZeroHero
Nå ja skal lævne at nuværende projekt jeg sidder på benytter sig af store interior meshes med en masse lyskilder. Derfor den rammer lofter ret hurtigt på max antal aktive lyskilder per objekt som du korrekt nævner. Har lige været væk fra projektet nogle måneder.
Har kigget på light baking naturligvis men syntes resultat bliver sådan lidt klammo med Unitys light baking muligheder. Så er pt. gået realtime lyskilde vejen. Som ikke ødelægger det overall look med en masse custom shaders med store interior meshes. Det er en meget specifik case.
Nå tilbage til Jespers tråd.

Ja jeg må sige det bliver lidt underligt når man rammer loftet Og det sker hurtigt ved de lavere quality settings hvor jeg har sat det lavt...
Jeg har endnu ikke fået leget med deferred lighting, da jeg hellere vil bruge min tid på at bygge Er der meget arbejde i at sætte det op?
Her et eksempel på hvordan det ser ud når der er for mange lyskilder - jeg havde sat grænsen ved 3 ydeligere lyskilder på laveste settings, og da jeg ikke har noget main light indendørs er det 3 ialt.
Øverst til højre er der en fakkel der ikke får lov til at skinne hvor en anden lyskilde længere væk skinner, og det giver en grim linie mellem lys og mørk. Der er ikke skygger på denne setting. (svampene og fireballen er ikke lyskilder - de er bare henholdsvis med emission og unlit)
Til gengæld legede jeg så lidt mere og fandt at det ikke var noget problem i forhold til at holde acceptabel framerate på lavest setting med flere lyskilder hvis jeg skiftede til vertex - ikke så pænt men et sted skal man jo ofre.

Lige med henblik på deferred. På de der heeelt slappe maskiner er det meget muligt du hurtigt render ind i performance issues i forhold til forward. Det må du lige lure på.

Og lige for at nævne det.. har kun viden om deferred i standard renderer. Det virker som om at det er en nyere features i URP. (Som altid noget bagefter)
Har faktisk ikke prøvet et sætte det op i URP. Men i standard renderer var det bare et snuptag. Muligt det er lidt mere bøvlet hvis det ikke er helt klar endnu.
**UPDATE** Det er det! Kræver prerelease Unity version eller meget ny med download fra Github. Så tænker det ligegyldigt at pille ved på nuværende tidspunkt. Men værd at overveje senere når der er en mere officiel og færdig version af hele systemet.
(never assume simple stuff just works)

Hehe.. tror du må have quality modes så du kan få skygger og pixel shading med på lidt bedre maskiner og lade det der integrerede kort æde low quality settings.