• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

GAF Indie Game Development Thread 2: High Res Work for Low Res Pay

Status
Not open for further replies.

DemonNite

Member
Well, Jack B. Nimble is finally done.

Launch Trailer: https://www.youtube.com/watch?v=rPSFaT_-jAc

App Store: https://itunes.apple.com/us/app/jack-b-nimble/id918891211?mt=8

X3aEJyb.gif


Time to relax a while :D

congrats on the launch! :) would love to hear any reports after a few weeks have passed
 

missile

Member
started to work on the procedural map and make it feel like its something physical.

Red Circles are locations to check for something important:
ExZkvLah.jpg
...
Looks cool. Also with the shading on the map.


Well, Jack B. Nimble is finally done.

Launch Trailer: https://www.youtube.com/watch?v=rPSFaT_-jAc

App Store: https://itunes.apple.com/us/app/jack-b-nimble/id918891211?mt=8

X3aEJyb.gif


Time to relax a while :D
Congrats!
Would be interested how people comment on the style of the game.
 

Pehesse

Member
started to work on the procedural map and make it feel like its something physical.

Red Circles are locations to check for something important:
ExZkvLah.jpg


As you progress through the level, you will unveil the fog of war plus draw a line of where you have been:
SyelMZKh.jpg


As the player rotates whilst the map is in view, the Red Arrow (representing the player) rotates as well to give you a sense of direction:
HardFortunateBat.gif

I really like it - the idea, and the way you did it! My only remark would be about the "where you went" line, as it feels a bit disjointed from the paper. I understand the legibility concern, as the player should be able to see it clearly, but it feels it has a very different saturation (and texture, even) from the rest of the paper. I think you could get a line appearance closer to the red circle's without compromising legibility much. But even despite that, cool! :-D
 

_Rob_

Member
As the player rotates whilst the map is in view, the Red Arrow (representing the player) rotates as well to give you a sense of direction:
HardFortunateBat.gif

This is looking really nice, stops the disconnect that you'd get from a pause menu map.

My first thought is that you could have some really cool hidden elements if the paper showed certain things on the map when held up to specific lights.
 

MimiMe

Member
was doing stuff lately which is the most fun for devs: watch a million youtube streamers and get their email adress.

at least the fun part is about to begin soon again
YAY



'DROP NOT!' passed 500k downloads on iOS!
giphy.gif


And we just released the game for Google Play:
https://play.google.com/store/apps/details?id=com.oddrok.roller

Update is coming next week on iOS, new characters,levels and stability!

Next we'll go back working on the Little Knight.

O_O
That's just amazing! Congratulations


Well, Jack B. Nimble is finally done.

Launch Trailer: https://www.youtube.com/watch?v=rPSFaT_-jAc

App Store: https://itunes.apple.com/us/app/jack-b-nimble/id918891211?mt=8

X3aEJyb.gif


Time to relax a while :D

Damn that looks nice! Good luck mate
 

KOCMOHABT

Member
For guys using Monogame or XNA (or their own framework)

I've released a color grading filter with a sample application for you to use. Find the source and setup guide on GitHub -> https://github.com/UncleThomy/ColorGradingFilter-Sample

You can use color grading to really easily change the look of your game, I think this is especially useful for 2d games which do not rely on lighting etc to easily change the look of its assets.

I've also written a little bit about the topic and the workings of color grading / correction with lookup tables here -> https://kosmonautblog.wordpress.com/2017/04/26/color-grading-correction/

5wCQzCl.gif

AuxlmAf.gif
 

DemonNite

Member
Looks cool. Also with the shading on the map.

Thanks! Tried to also require real lighting in the level to see it but it was too harsh

I really like it - the idea, and the way you did it! My only remark would be about the "where you went" line, as it feels a bit disjointed from the paper. I understand the legibility concern, as the player should be able to see it clearly, but it feels it has a very different saturation (and texture, even) from the rest of the paper. I think you could get a line appearance closer to the red circle's without compromising legibility much. But even despite that, cool! :-D

Really useful feedback on the line and I get what you mean :) if I could match it to the circles it would be better I agree

This is looking really nice, stops the disconnect that you'd get from a pause menu map.

My first thought is that you could have some really cool hidden elements if the paper showed certain things on the map when held up to specific lights.

Ah just like Uncharted vita? I really love this idea! Could be showing hidden rooms on the map only if held in front of a light :)
 
I want you to check my game when it comes to completion! :)

I always liked how John Carmack ones said that with only three click you will
be connected to a game on the internet (Quake Arena, iirc).

Sure, no problem, and yes, exactly. Generally I feel that the player should have a very clear interaction, possibly with a call to action can bring them to a game in a single click.

Most games tend to present this with a 'quick match' button. At most, they should have to select find game, then select a game mode.

It's nice that advanced options exist but I would argue it's better to make these less visible to the player. The average new player isn't likely to care about making custom lobbies or joining a specific lobby, so it risks overloading them with information to present all of this on a single screen.

started to work on the procedural map and make it feel like its something physical.

I really like the map, but maybe less so the red arrow. Don't get me wrong it's very functional, but perhaps doesn't quite fit the rest of the maps style. Did you experiment with things like footsteps or something else more organic? Perhaps these would be less usable though, so you would have to be careful and experiment.
 

missile

Member
Sure, no problem, and yes, exactly. Generally I feel that the player should have a very clear interaction, possibly with a call to action can bring them to a game in a single click. ...
Cool. What I imagine for my game is to have something to play, explore, look
around, or testing weapons of the craft etc. right at the title/menu screen.
So before the game ask you anything, you are right at the controls of
something giving you an instant feedback of the game. What you say?
 

missile

Member
Some new stuff.
Ok, I reworked the camera system and projection. It's quite flexible somehow
but I need to find out how to use it best (which is where any artist comes
into play). A new feature is the larger FOV, it's 90 degrees in here. So you
get a lot to see looking out the front window. Another feature, not visible,
is that I have build sort of a camera shader which allows me to modify the
camera settings on a per-pixel level which should allow me to load,
draw, and animate camera textures, if that makes any sense. I basically need
it to build new panels in the craft projecting different parts of the
surrounding. Will see. Ah, and I've added some minor marks on the window,
helps to make things more alive;

U7uC069.gif


aN9PI4v.gif
 
I created a website for my UX stuff which is a work in progress but any feedback is very much welcomed / appreciated. The only article I have up on there right now is a Flinthook UX Quicklook.

http://videogameur.com/2017/04/23/flinthook-ux-quicklook/

Obviously this isn't game dev, but it's related, and independent. So almost fitting the thread description.

Cool. What I imagine for my game is to have something to play, explore, look
around, or testing weapons of the craft etc. right at the title/menu screen.
So before the game ask you anything, you are right at the controls of
something giving you an instant feedback of the game. What you say?

Most of the time when I consider if something is a good idea I try to recall instances where I have seen similar applied successfully elsewhere. I can't think of many games where the player is simply put at the the controls of a complex vehicle within the opening moments of the game.

In general the sentiment that Carmack expressed related to the accessibility of being able to jump into gameplay, not the lack of availability of options, tutorials, etc. for players that might not have experience with that type of game. Additionally, the context he was describing it was different, the game he was discussing was a relatively conventional shooter, with controls many players would be familiar with. So those are things to bare in mind.

That isn't to say that I think a game should be bloated, with various 'drill downs' before they can get to any real gameplay (David Jafe's recent game, Drawn to Death, makes this mistake). I think the way that many games begin with a gameplay orientated tutorial level works pretty well. I've always enjoyed the introductory segments from Call of Duty games, which do tend to throw you into the action, within an albeit controlled environment. The shooting gallary sequences that these games often open with has grown a little tired over time, but it's a pretty good way to introduce players to the game.

I don't know if you have access to GDC vault but there's a neat video on their from Mushroom 11 developer which talks about user experiences and how players react differently (better / worse) to different types of onboarding. A lot of this relates to the games relatively complex controls, and concepts like how players learn when placed under pressure / risk.
 

missile

Member
I created a website for my UX stuff which is a work in progress but any feedback is very much welcomed / appreciated. The only article I have up on there right now is a Flinthook UX Quicklook.

http://videogameur.com/2017/04/23/flinthook-ux-quicklook/ ...
I like how you do the analysis, it's to the point and pretty clear, not trying
to put any lipstick on a pick or something -- someone we need in here! :)
Speaking about the page, I would at least say what UX means while mention it
for the first time. Second, the style of the page is a bit demanding, the
headlines and the text is a bit bolded on my end making it hard to read.

... Most of the time when I consdier if something is a good idea I try to recall instances where I have seen similar applied successfully elsewhere. I can't think of many games where the player is simply put at the the controls of a complex vehicle within the opening moments of the game. ...
Haven't speaking about any complex stuff. More of some simple inclusive
gameplay. Can be as easy as roaming the craft with the controller in a wind
tunnel to manipulate the swirling pattern forming behind. So I can imagine
if the game starts up you see the craft hanging in a wind tunnel while the
welcome screen runs across with you being able to roam the craft and hit
fire button to hit a fictive target sitting in front.

... In general the sentiment that Carmack expressed related to the accessibility of being able to jump into gameplay, not the lack of availability of options, tutorials, etc. ...
Yeah I know. Easy access.
 

Pehesse

Member
I created a website for my UX stuff which is a work in progress but any feedback is very much welcomed / appreciated. The only article I have up on there right now is a Flinthook UX Quicklook.

http://videogameur.com/2017/04/23/flinthook-ux-quicklook/

Obviously this isn't game dev, but it's related, and independent. So almost fitting the thread description.

I think it's great to gather all of your work in one easy, accessible place, it should make it into even more of a valuable resource! I'm also fond of the site template you use, simple and to the point. However, one detail: reading on mobile, the text formatting gets jumbled by images, making the neighboring lines close to unreadable (one letter per line). Other than that, all good for me and should make an excellent addition to the next OP, looking forward to future analyses!
 
tumblr_op4kkcunqM1w48nado1_250.png


Spent the morning adding some little homages around the gameworld, they don't do anything, other than provide a cute thing to find if you look in very out of the way places. Gotta remember where we came from, after all.
 
I like how you do the analysis, it's to the point and pretty clear, not trying
to put any lipstick on a pick or something -- someone we need in here! :)
Speaking about the page, I would at least say what UX means while mention it
for the first time. Second, the style of the page is a bit demanding, the
headlines and the text is a bit bolded on my end making it hard to read.

Thanks, that's something I'll probably add to the about page to be honest. Every article could be an a entry point and I don't what to explain what UX is within every article, if that makes sense.

Haven't speaking about any complex stuff. More of some simple inclusive
gameplay. Can be as easy as roaming the craft with the controller in a wind
tunnel to manipulate the swirling pattern forming behind. So I can imagine
if the game starts up you see the craft hanging in a wind tunnel while the
welcome screen runs across with you being able to roam the craft and hit
fire button to hit a fictive target sitting in front.

Yeah I know. Easy access.

You don't have to have complex controls for your game to be complex. Your game greatly restricts the players field of view, so it coud be difficult for players to understand what's happening.

In general that's something that I'd really think about with your game. Is there a clear reason that the field of view is so restricted? In general, restricting the players view has the potential to be a usabiltiy issue. This is often discussed in guidelines for heuristic evaluation in games (e.g. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.142.211&rep=rep1&type=pdf)

For me, in order to justify that restriction you would need a really compelling, gameplay driven rationale. There are exceptions for the sake of immersion and simulation, but it's a big usability sacrifice to make if it's merely a stylistic choice. This isn't me telling you that the way the game look is wrong, but I think it's something you should place some serious consideration on moving forward.
 

missile

Member
... You don't have to have complex controls for your game to be complex. Your game greatly restricts the players field of view, so it coud be difficult for players to understand what's happening. ...
In the case I mentioned you would see the craft from the outside and using
perhaps just one stick to tilt it around. Nothing too special for the title
screen, more like showing off the craft (a key element of the game) and
perhaps some dynamic effects like some swirling patterns circling around
reacting to your movement. Well, that's just an idea.


... In general that's something that I'd really think about with your game. Is there a clear reason that the field of view is so restricted? In general, restricting the players view has the potential to be a usabiltiy issue. This is often discussed in guidelines for heuristic evaluation in games (e.g. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.142.211&rep=rep1&type=pdf)

For me, in order to justify that restriction you would need a really compelling, gameplay driven rationale. There are exceptions for the sake of immersion and simulation, but it's a big usability sacrifice to make if it's merely a stylistic choice. This isn't me telling you that the way the game look is wrong, but I think it's something you should place some serious consideration on moving forward.
Let me explain a bit. First I have to say that nothing is final, yet, but
there are some reasons for doing sort of an restricted view for a couple of
crafts. I also want to mention that the horizontal FOV is actually rather
huge, it's about 90 degrees (and I can do a lil more or less if necessary).
The vertical view is much more limited, of course. One reason is indeed
immersion. I want to produce the feeling of being in a confined environment.
The fastest vehicles on the planet do have only a few tiny slits for looking
through, for a reason. Building a fullscreen/cockpit-less variant or one with
an overlay HUD / pseudo-cockpit won't produce the same sensation, which is
what I got from playing lots of fast racing games. I've spent, for example, a
couple of thousand hours (3000h+) into WipEout, online gameplay, community
etc.. One thing is pretty clear. As better you become with this game the more
you want to have a restricted view/cockpit (not everyone, sure), which is what
the professionals want to have. You can see that trend by seeing how almost
all of them switch to bumper-view over time where the camera is right over the
ground, which could be seen as a disadvantage because you will see less
compared to third-person-view from behind. However, it's a way different
feeling/thrill running that way around the track/corners. You need to
anticipate more etc.. Your are closer to the real thing so to speak. But
unfortunately there is no real cockpit-view in WipEout giving you the
immersion of actually sitting in a craft with all its limits.

Another point is reading of the telemetry/status of the craft while running
around. It's good to have some fixed screen space to put these numbers/bars
etc. without annoying the player by letting these elements move with the craft
as an overlay like in Redout. They went fullscreen and as such need to put the
stats somewhere. However, this all depends on how important the stats are for
the game. One thing I noticed for virtually every vehicle going fast is that
such vehicles are basically flown by data.

After awhile you know the tracks inside out, but if you have a craft which is
running on finite resources you need to manage those during the race (to
finish/win whatever). Take WipEout again when racing with the best. In that
case the game becomes a resource management/strategy game. You have to control
the energy of the craft at all times and couple that with all the weapons and
item pads during a race, for, more energy = more speed/options. And this is
where the thrill is. It may sound odd but the track isn't so important nor how
much you see of it under such circumstances. Sure, if you want to make a
pleasing game to watch you better show the world. But that's not what I'm
after. My game will be a bit different. It's also not about the graphics so
much. What's important is that the essential data is displayed at a good
location so you can count on it while making split-second decisions. Telemetry
will be important.

Another reason for limiting the view has to do with all the strobing, epilepsy
things and stuff. The game will be fast and the elements of the track will
prop to some degree. It's much better in this case to just see a part of all
that stuff instead of seeing it all over the place.

Well, I want to add something more to the limited view. I think it's not so
much about what a player can all see. What I think is more important is that
the player knows where (s)he is, i.e. the orientation. And to enhance the
orientation I will, as stated in same last posts of mine, add some more views
by filling some additional panels you can seen in the graphics of the cockpit.
I also plane to have a fisheye sort of view. This element will show what comes
from behind and will also serve the orientation and continuity.

But it's quite too early to really talk about all the details.

Anyhow. I'm pretty sure that such restricted views etc. won't be for everyone,
no doubt about it. But a game for everyone is a game for no one.
 
I decided to test an idea of mine today while I was procrastinating.

Normally, when you bake lighting, UE4’s cubemap actors capture the scene and its lightning pretty well.
When you switch to fully dynamic lighting however, the cubemaps no longer capture light.
I generated my own 360 HDR cubemaps and then specified custom cubemaps in the sphere reflection actors and got this.
My custom cubemaps are more accurate to the scene but have their own possible issues.
 

missile

Member
I decided to test an idea of mine today while I was procrastinating.

Normally, when you bake lighting, UE4's cubemap actors capture the scene and its lightning pretty well.

When you switch to fully dynamic lighting however, the cubemaps no longer capture light.

I generated my own 360 HDR cubemaps and then specified custom cubemaps in the sphere reflection actors and got this.

My custom cubemaps are more accurate to the scene but have their own possible issues.
Your one looks more pleasing.

Is the performance the same/similar? Perhaps they use something speedy?
 
Your one looks more pleasing.

Is the performance the same/similar? Perhaps they use something speedy?
The baked one is the best imo with mine as a close second, I probably should have disabled bounce light for the bake so the scenes matched better.

The performance is unknown (need a more extreme test). The engine already stores the cubemaps it generates and then calls them on its own but I don't know if there's any specific optimizations. Also not sure what the specific disadvantages of my method are as this was just a quick test to see if it worked. The biggest problem with this is generating the maps.

With stock cubemaps I can place any number of reflection capture actors in the level and update every capture with the click of a single button.

With mine I have to place a scene capture entity in the exact place, save the map (engine saves .EXR), export the map (engine converts to .HDR), then re-import the map, and finally assign that cubemap to the correct reflection entity.

I'll run more tests sometime next week when I have more time.
 

missile

Member
... The biggest problem with this is generating the maps.

With stock cubemaps I can place any number of reflection capture actors in the level and update every capture with the click of a single button.

With mine I have to place a scene capture entity in the exact place, save the map (engine saves .EXR), export the map (engine converts to .HDR), then re-import the map, and finally assign that cubemap to the correct reflection entity. ...
Why not computer the cubemaps yourself?
 
Some updates about Sitcom Valley for screenshot saturday. Also im super happy I was warking yesterday with the proframmers to see the UI for the battle system is already up and running and looks great (its very Persona with a 90's flair), and also Jules moving around the house with working hitboxes. Thats more in a month than what the other programmers we had in a year, we could have the game up and running a lot sooner :( At least im more happy now that how I was then thanks to the amazing people im working with now.

So here is the concept art one of our artist made for the kitchen backgrounds:
And here is one of the scenes that can happen if you let Alex, the scrounger neighbour, enter your apartment (by losing the fight against him). Eating you food will affect your time management strategies and money as you will need to buy food to get health back up again for the next battle.
cocinasitcom6skqk.gif
 

Minamu

Member
Chronospherics: I'm happy to announce that I might have convinced one programmer to help me make a tutorial level ;) I'm thinking that we could simply allow players to create an offline lobby where the class can be switched at will and the winning conditions are removed so they can run around freely. It won't be easy given all embedded network code we have but in theory it could work. We're still in the very early planning stages so far though so we'll see.
 

missile

Member
What do you mean? Like automate the process? I have no idea how I'd go about doing that.
I mean to render the cubemaps in-engine by setting up the rasterizer to render
the six faces of the cube and using them, instead of making scene captures
and going the .EXR/HDR export/import route.

Edit: But I don't know how UE works nor what scene capture really does. ;)
Am just guessing.
 
I mean to render the cubemaps in-engine by setting up the rasterizer to render
the six faces of the cube and using them, instead of making scene captures
and going the .EXR/HDR export/import route.

Edit: But I don't know how UE works nor what scene capture really does. ;)
Am hust guessing.
I can't really program so I don't think I could do that. Also I imagine it's pretty complex.
 
Been busy so I've missed a week or two of updates, but still moving forward thankfully. This is one of the newer dungeons for our game which turned out pretty well. We also have title cards for areas and bosses! Almost feels like a real game now.

 
Chronospherics: I'm happy to announce that I might have convinced one programmer to help me make a tutorial level ;) I'm thinking that we could simply allow players to create an offline lobby where the class can be switched at will and the winning conditions are removed so they can run around freely. It won't be easy given all embedded network code we have but in theory it could work. We're still in the very early planning stages so far though so we'll see.

I didn't say you had to have one, but it could be helpful. Really depends what your intentions are for the game. It makes me happy to think you're at least thinking about my feedback anyway. But don't think you absolutely have to have tutorial, sometimes you can make a game work without one. Even a bare bones introduction where you can just move your character around and then get shown the objective could be enough, or embedding real gameplay into your static tutorial menu could be a neat way of showing players what to do. There's lots of options for you to consider, relative to the time and resources that you have.

Have you had much opportunity to get it into the hands of players yet? Maybe see how they react to the tutorial information you have in the game at the moment. Don't give them any information about the game, just put some naive users in front of it, with your current text tutorials, and see what happens. I don't know if you have the resources to do that though. But sometimes it's possible.

Oh, something to bare in mind is that in terms of usability, player feedback alone can be pretty misleading, and almost useless. It's valuable in conjunction with behavioural observation, however players often fail to recall issues they faced. Often I'll ask people if they had any issues with the game, any point of confusion, and they'll say no, that everything was pretty simple. But in reality, they don't even know what anything in the interface does. We watch them struggle for 60 minutes and they'll tell us everything is simple and easy to understand.

c4jt321.png


The dog is the user giving you feedback and that's the game burning to the ground behind them.

So my advice would be to record the gameplay and try to analyse what happens, try to look for things that they don't seem to understand, etc. If any of you guys ever run a playtest I can try my best to give you my advice on how to structure it within the scope of your resources. Lots of devs attempt to playtest their games at conventions and expos, and tend to do pretty poor job.
 

missile

Member
... Oh, something to bare in mind is that in terms of usability, player feedback alone can be pretty misleading, and almost useless. It's valuable in conjunction with behavioural observation, however players often fail to recall issues they faced. Often I'll ask people if they had any issues with the game, any point of confusion, and they'll say no, that everything was pretty simple. But in reality, they don't even know what anything in the interface does. We watch them struggle for 60 minutes and they'll tell us everything is simple and easy to understand. ...
Interesting.


Meanwhile...
I've implemented a skydome to see how it lights up the scene. Makes everything
look much more interesting right away;

6aqtLAZ.gif


Needs some more work. I can still further improve on it in reducing more of
the artifacts or dither the world making them go much more unnoticed. However,
I will also try to build a smooth version and see how it performs.
 

Minamu

Member
I didn't say you had to have one, but it could be helpful. Really depends what your intentions are for the game. It makes me happy to think you're at least thinking about my feedback anyway.

Have you had much opportunity to get it into the hands of players yet? Maybe see how they react to the tutorial information you have in the game at the moment.

*snip*
Yeah no, I know :) I was just having a bit of fun. Your feedback was thoughtful and good, no doubt. A tutorial system of some kind is hardly ever a bad idea. I'll respond where needed to your previous post below.

As for intentions, the game is mainly for portfolio purposes, as an attempt at getting a dev job as a designer, be it game or level. That's the primary concern for me, but less so for the rest of the team I suppose. We will put it up online as a free, or extremely cheap, download but that's a secondary concern.

To be perfectly honest, I think our current static system is good enough. Like missile said, a game for everyone is a game for no one, and *some* demands should be acceptable to put on the players. But, do I want a system that is good enough? I don't know about that. So I'm looking into it. My programmer even suggested designing an entire system with icons and explanations dynamically changing as the player progresses through the tutorial level. We'll see. Your other suggestions have been semi-discussed before as well, I currently have poor pictures of the different abilities but they're disabled at the moment.

My main issue with these new grand ideas, as good as they might be, is that we were supposed to stop the feature creep more than 6 months ago :lol But it keeps on happening, regardless of my constant complaints. That's why I'm may appear a bit resistant to change.

Nobody but the dev team has tried the game so far unfortunately. That likely means that we have a long road ahead of us with unforeseen issues. One of my biggest concerns is the fact the the game is meant for 4 players, but for over a year, the most we've played with are 3 people over LAN. So it's impossible to know if the level sizes are properly scaled. I might have access to game dev students, and others, at the local university across the road basically, but we haven't tried that yet. As a former design student at that school I've done plenty of projects and tests so I know what you're talking about there :) I'm thinking of contacting the game students, they have their own building with LAN capabilities etc, they might be helpful. I could also send the game to some friends for some small feedback.

I had a look at your menu test and I have some thoughts that you could consider.

How can you minimise it? Does the class information need to be on this screen, can they not learn about these on the class selection screen?
If you're going to talk about concepts like the 'holy sword' and 'hunter', could you not show this to players? Could you use elements from the game, or icons to provide clarity on these key components?

Classes

Again, this screen has a huge reliance on the players motivation to read this information, you should consider planning for the those that they very well may not! Especially if you plan on demoing this game at expos and events, anything like that where people need to 'get' the game very quickly.

Consider making this concise, and clear. Limiting it to the information to just what the player needs to know. At the moment the only important information appears to be the control adjustments at the bottom (speed boost, slow down). Ultimately, this is all the information that the player needs to know about the characters in order to play and understand the game, and therefore it really needs to stand out.

Maps

Map selection has a similar issue. Think about the information you're conveying here. What do players need to know from the map selection? In general a text-based description of the map is not going to suffice in allowing players to understand how the map plays, they are going to experience this by playing.

The key information then, becomes the name and aesthetic of the map. Aesthetics are well depicted, but the maps name is embedded with the rest of the text and does not stand out. Consider making sure that the maps name stands out from the rest of the flavour text, so that players create a connection between the maps name, and its aesthetic. This might help when they want to later replay, or discuss the maps they like the best.

Play Menu

The play menu is packed with information that the player doesn't need. If they just want to join an existing game, do they need to see all the details related to creating their own game? Do they need to see all of the filters for finding a game if they just want to join one of the ones available? This presents an abundance of information that the player does not need.

I should stress that none of these are what I would consider high priority issues, none of them obstruct the player from proceeding forward, but they do have potential to be confusing, or misunderstood. I like the look of the menus and it's clear you put a sizable portion of work into them. There's definitely a lot that they do right, such as a clear navigation bar at the top enabling players to switch between a set of very recognisable menus, but there's definitely ways in which the usability could be enhanced, and this does have meaningful potential to enhance the player experience.

The main reason I used Overwatch as an example is because it has very good UX, and I didn't want to spend too too long on this (loading up different games to capture screenshots etc.) but there are lots of other games that offer similar examples and really good UX practices. Destiny has really nice affordability of interaction and general clarity of what it's intending to convey, and games like Uncharted, Titanfall and Rocket League are similar examples.
I think it's funny that you say that you can tell that I've spent a lot of time on these menus :) Because that is the entire crux of the problem with this project in my opinion. I haven't been involved *at all* in designing these menus beyond the game's logo and spinning background. One of my programmers have taken it upon himself to design all menus on his own, without any kind of feedback. Granted, he has a web design degree and make commercial websites for a living, but still. The rest of us have had zero input on this during its development, which is kinda how all aspects of this project have worked. I've spent a lot of time trying to clean it up after the fact since. I spent all weekend trying to polish up the menus after you posted your comments, and found out yesterday that the same programmer had been redesigning the same menus at the same time without saying anything, even though I was explicit in my weekend intentions. Not exactly a healthy dev environment :) I don't mean to rant, I'm just explaining the work conditions I live with. The same has been prevalent in the gameplay areas as well.

***

I don't think I completely follow your train of thought on the Classes menu. You see the name of the class as you click each respective icon, all of which correspond with the 3D models in the background. I suppose the abstract graphics style could make it harder to understand.

As for the class text, I've discussed it with my programmer and we were of the same opinion that the text itself is voluntary flavor text, and it's the explicit button icons that are the most useful. We could probably change the actual look of the class definitions, and make the buttons pop out more, but the flavor text, if needed at all, need to be there because there is no system for picking a class, it's all randomized at run-time. That's why it's so condensed to one menu. We went with removing class choice from the player to make it more fair during gameplay and to make the menus cleaner. Tough decision either way. Pictures of the Hunter and Sword might be smart though, especially on the How to Play screen. On the other hand, you'd have to be pretty daft not to make the connection to the spinning 3D models ;) We're working on adding proper icons for the Hunter and Sheep, we'll see where that ends up.

Did you find that the Controls menu and class abilities to be confusing or not clear enough? I agree that the symbols need to stand out, but I thought they did ;) Beyond looking somewhat amateurish of course.

***

I've changed my map names in the flavor text to have a different font color than the rest of the text, it might be better, or not. I liked having the names embedded in the texts, sort of like easter eggs. I don't want to spend screen space on explaining how each map works, I think it's better to experience that on your own as you learn, thus flavor text instead of factual information. It seemed like a good spot to add our basically only "lore" in the entire game. We'll see, it seems the menu look is more in flux than I thought. I understand your point about the names needing to stand out, but since each name is listed in the vote buttons in the middle of the screen at all times, and the corresponding image is shown as you hover over the buttons, isn't that enough of a connection? Maybe I'm blinded by the fact that I've made and named each map on my own, but I'm not so sure of that.

My source of inspiration are my memories of the old Call of Duty 4 Modern Warfare multiplayer menus, iirc they had map names and a picture, that's it. It seemed pretty clear to me back in the day :)

***

I fully agree with you on the Play menu actually. No other menu is more annoying to me than this one :lol. I don't know if you remember how it looks, but everything in that menu beyond the create/find and join buttons are non-functional placeholders for stuff I've said that the game *will never* have as options. But the programmer has still wasted resources on creating the content and somewhat working functionality. But even though the game is built entirely around having only 4 players or less, he insists on having an option for 32 players, on maps with only 4 spawn points, created by the same person. Gameplay is designed around a 4 player free-for-all, but we obviously need options for team-based multiplayer as well. It's ridiculous :/

One funny thing though. I explained your legit critique about how messy and confusing the menus look, and the creator laughed and said that he had already designed them as you described back at the start but it was actually me and the other guy who got confused so he redid them into the current setup :lol I had totally forgotten about that.

I know you weren't supposed to help me in the first place according to your schedule so I just want to say thank you for the time and energy, I appreciate your feedback a lot. I don't think I've ever done so graphical interfaces before, not on my own at least, and I love this kind of work, especially more diegetic styles of interfaces. I don't mean to sound like a douche, I love this game, so it's incredibly frustrating having to fight needless power struggle battles within the team all the time :/ I'm gonna re-read all your feedback and take to heart what I can. I can't promise I can make any lasting design decisions anymore though..
 

neko.works

Member
Hi everyone! Quick question :3

Light Fairytale have been planned as an episodic game from the beginning, as it is way too ambitious for a solo indie dev like me to release as a single, complete game.

The initial plan was 3 episodes, but I'm currently considering dividing each episode by 2. This would allow to release the first one sometimes this year rather than next year.

Basically, here's the two options:
Initial plan: 3 episodes, each one having 6 hours of gameplay, priced $10, with one year between each release. The first episode for Q2 2018.
New plan: 6 episodes, each one having 3 hours of gameplay, priced $5, with 6 months between each release. The first episode for Q4 2017.

So, do you guys think that the new plan is a good idea?

Bonus, here's a few videos on YouTube that I've published since my last post:
The new opening.
The first battle.

And here's a work-in-progress screenshot from a cutscene that I've been working on this week-end:

C-roxvJXsAEOG6R.jpg:large
 
Hmm, on one hand, going with 3 episodes would probably look a lot less "milked", but on another hand, a lot of consumers seem to have a pattern of becoming apathetic towards indie game sequels released over long spans.

So you intend for the further episodes to be separate entries on Steam, or handle them as DLCs like Hitman?
 

neko.works

Member
Hmm, on one hand, going with 3 episodes would probably look a lot less "milked", but on another hand, a lot of consumers seem to have a pattern of becoming apathetic towards indie game sequels released over long spans.

So you intend for the further episodes to be separate entries on Steam, or handle them as DLCs like Hitman?

The further episodes will be handled as DLCs.
 

Gisele

Banned
When I see a game is episodic I always wait until the last episode is out to give it a try. That's just how my instincts run with that label at this point.

I don't know how your story works but I think if you frame it as a trilogy and have viable entry points at the start of each episode then that's your best course of action. That way when the sequels release people aren't scared off from trying them if they haven't started yet, and if they find out they like the game a lot then they can go back and see what there was before.
 
Looks like the Unity forums got hacked (forum.unity3d.com) so if you used the same password somewhere else, now would be a good time to change the other instances of the password.

Otherwise, everyone that has a Unity account should keep an eye on things. At this point it's unclear if all Unity account data is compromised, or just forum-related account information. I'll definitely post once it's resolved, if someone hasn't beaten me to the punch.
 

Mik2121

Member
I decided to test an idea of mine today while I was procrastinating.

Normally, when you bake lighting, UE4’s cubemap actors capture the scene and its lightning pretty well.

When you switch to fully dynamic lighting however, the cubemaps no longer capture light.

I generated my own 360 HDR cubemaps and then specified custom cubemaps in the sphere reflection actors and got this.

My custom cubemaps are more accurate to the scene but have their own possible issues.
How is your full dynamic lighting set up? I can have a scene only with dynamic lights and my default cubemaps are properly captured.
 
How is your full dynamic lighting set up? I can have a scene only with dynamic lights and my default cubemaps are properly captured.
What engine version are you on? Can you show me?

Use static lighting (proj settings) = off
Support stationary skylight = off
Movable lights

And then (this is redundant but I did it for the test) the map has ForceNoPrecomputed lighting set to zero.

This unlit cubemap thing has existed since at least forever for me. I'm on 4.16 preview.
 

Mik2121

Member
What engine version are you on? Can you show me?

Use static lighting (proj settings) = off
Support stationary skylight = off
Movable lights

And then (this is redundant but I did it for the test) the map has ForceNoPrecomputed lighting set to zero.

This unlit cubemap thing has existed since at least forever for me. I'm on 4.16 preview.

Uhm, I didn't do any of the changes on the project settings for static lighting, but the way I set it up is:

Start new level (so it has no baked light info) and make a room with the white boxes and enclose it. Put two or three spheres inside like you did.
I placed a point light set to Movable and apply a "chrome" material to one of the spheres (metallic 1, base color 1, roughness 0) and I'm getting lit reflections from both the sphere reflection actor and from baking a cubemap to a render target and applying that to the emissive on my sphere (the render target also shows properly lit).

I might be misunderstanding something from your post though. These are the results I got:

1MBftxd.jpg


(left real time, right baked (I did the real time thing first))
I'm on 1.16 preview 1 too. I haven't had this problem ever, but again, maybe I'm missing something.

Edit: Left has a material with the render target applied to the emissive, right is just a metallic ball with a sphere reflection capture inside it.
 

JulianImp

Member
Oh, something to bare in mind is that in terms of usability, player feedback alone can be pretty misleading, and almost useless. It's valuable in conjunction with behavioural observation, however players often fail to recall issues they faced. Often I'll ask people if they had any issues with the game, any point of confusion, and they'll say no, that everything was pretty simple. But in reality, they don't even know what anything in the interface does. We watch them struggle for 60 minutes and they'll tell us everything is simple and easy to understand.

Yeah, verbal or written feedback is often awful because humans hate admitting they don't understand something (and they often view us developers as some kind of god-like authority testing their gaming skillz), so they're really likely to sugarcoat their thoughts about the game both to avoid defying you and also to save face, which is not what you want when attempting to gather data to determine if an given part of your game is good as is or needs improvement.

Instead of doing that kind of thing, my recommendation is to always keep a mental list of how you expect players to react and behave in particular situations, and contrast your expectations with what actually ends up happening. For example, you might expect players to switch to magic attacks once they realize they deal no damage to a new type of heavily armored enemy, but maybe in reality they still aren't used to checking damage numbers by that point in the game so they just keep dying over and over to the enemy and eventually quit out of frustration, or maybe they were just spamming magic at everything so they never actually realized they had to use spells to beat that particular enemy type, and things get bad later once the game expects them to manage magic points in more constraining conditions. Basically, do a mental "Expectations --> Reality" chart with situations that happen in the game, and that'll tell you a whole lot more about what players get and don't get of your game than any kind of data a post-game survey would provide.

Taking analytics from how players play your demo at expos could also help a lot, such as tracking level clear times, how many times each player died in a level and where/how, amounts of damage dealt/taken/healed, player/enemy attack accuracy, etcetera. You can just have a simple script that tallies those values and appends them to a text file after a level is cleared (or even if the player quits mid-game), and later feed that data to a script that could add up the values in order to turn the data into easier-to-understand statistics such as average clear times or number of deaths for any given level and/or area.

...Oh, and another important thing is to try and avoid explaining the game to them as they play unless you absolutely have to (mostly when you realize you've really goofed up trying to explain how something works in-game and they're about to quit out of frustration or attempt to stop thinking and just try to brute force their way through), since copies of your game (or demo) won't ship with a member of the dev team that'll be handily explaining things to players. Also, notes should be taken mentally in my opinion, since players are likely to feel more pressure if you're sporadically writing things down somewhere as they play.

TL;DR: In a nutshell, I'd suggest that you trust what players do, not what they say.
 
Status
Not open for further replies.
Top Bottom