Silly New Years 2015-2016 Jam

I just got done jumping around for like 10 minutes. I always test it and test it. If there is a problem, no offense to anyone, but I don't want to wind up hearing it from someone else. But I would rather catch the bug myself. I still have an ego, after all.

 

Perhaps I should have posted this in another place but since we are kind of "doing our thing" here as a micro group within the community I figured I'd ask my jam colleagues (or buds if you prefer the less formal way).

Anyway... I started designing a GUI and about halfway through implementing it it I had the thought I am probably once again going completely against the Unity Way.

Without giving too much of the game away let me say that in my FPS you will be able to power up various core attributes that will increase your performance in several key areas.

So I made this:



Originally, I had a minus (-) at the left of the bars and a plus (+) at the right of the bars. That's when I was thinking of using the mouse. But then I thought well the entire game is played via keyboard or joypad so it would be stupid to have to use the mouse just for this. And I ditched those little buttons.

Of course, when I say buttons I mean some sprite game objects with colliders I made. The entire thing is a custom GUI created from sprites.

Anyway, now there is a white rectangle serving as the cursor which can be moved up and down with the arrow keys or joypad.

But man this has been tedious. Like of course this stuff is always fairly tedious in every framework but normally I would just program it all and not try to lay out the elements visually as I had to do here. Which makes it much simpler to do. So I am thinking there is a good possibility Unity may have something that would make this less tedious and quicker to knock out.

Not like the UGui with those stock labels and buttons and things. They look pretty odd and out of place in a game in my opinion. I mean some way to use my custom content so the GUI is styled as shown above. With each of those blocks in the level bar being colored the same as the corresponding attribute color.

Like I said, I basically have it about halfway done at this point anyway so if there is no straightforward less tedious way then I can always continue with this route. Actually I probably have the most tedious parts (all of the layout of the elements) finished at this point anyway.

So... what in heck do you guys use to create your custom GUIs?

 

I use the new GUI system. I haven't thought up an easily-modable way of doing GUIs yet, though.

What I do is I have a bunch of New GUI elements underneath a single game object that is a "Canvas Group". I also have a 'presenter' script that controls what shows, what each element shows, etc. Each presenter is also associated to a 'controller' that pretty much orchestrates which presenter is showing, and also passes data to each presenter.

I do have a base presenter behavior that I use to control some aspects of the presenter. A good example of a presenter in action would probably be the Title UI Presenter. A good example of the controller is the Title UI Controller, because subtlety is my middle name (actually it's not - I would feel sorry for any child who deliberately was named 'Subtlety.')

 

Isn't the new uGUI limited to interaction only via the mouse or can it be used with Keyboard and joypad as well?

 

I remember somewhere in the tutorials that there was a way of indexing different controls, similar to how you can index controls in visual studio. This makes it so you can scroll through things using a joypad, or I would assume arrow keys if you'd like. I remember seeing that feature but never needing it yet.

 

You can cheat like I did. I used the buttons for the unicorn colours & created a function for each button e.g. ClickBlue() & set the button up to work with mouse clicks but then in my script I just used get input for each number key to call the same function.

And yes, there is a way to map the scroll order for buttons as well when using a controller or getaxis.

 

Hmm... well that would be awesome. Maybe I need to take a good look at uGUI. I have never seen any game around here using it that allows keyboard or joypad for menus. Always mouse. But heck yeah if you can index them and simply do a call to basically set the focus to the next control that would be great.

 

All you need is something like this

Code (CSharp):

1. public class ButtonSelector : MonoBehaviour {
2.  
3.     // Use this for initialization
4.     void Start () {
5.    
6.     }
7.     public Button[] buttons;
8.     public int buttonIndex=0;
9.     private int m_prevSelected=-1;
10.  
11.     void Update () {
12.         if(Input.GetKeyDown(KeyCode.UpArrow))
13.         {
14.             next();
15.         }
16.         if(Input.GetKeyDown(KeyCode.DownArrow    ))
17.         {
18.             prev();
19.         }
20.     }
21.     public void next()
22.     {
23.         buttonIndex++;
24.         if(buttonIndex>=buttons.Length)
25.         {
26.             buttonIndex=0;
27.         }
28.         selectButton();
29.     }
30.     public void prev()
31.     {
32.         buttonIndex--;
33.         if(buttonIndex<0)
34.         {
35.             buttonIndex=buttons.Length-1;
36.         }
37.         selectButton();
38.            
39.     }
40.     public void selectButton()
41.     {  
42.         buttons[buttonIndex].Select();
43.     }
44. }
45.  

 

Well that is basically what I am already doing with my own custom system except I guess I dropped down a bit lower making the elements from scratch with sprites and colliders (that I ended up removing because I don't need them). I mean this way can certainly work because it is the way I normally do it in other frameworks. It's just the positioning of things is dang tedious in the Editor.

I don't actually need to wire things for mouse because I want the player to be able to just use the same controller they are already using to play the game. And in a way that makes it a bit less work on one small thing at least because I don't need to do raycasts to find out which button the mouse is currently over.

That last part about mapping scroll order sounds very good!

I am doing a quick search on the Asset store right now and if I don't find something that makes it super quick n easy I will check into the uGUI!

Thanks you guys!

 

Well that is basically the way I am doing it now with my custom controls. Heck yeah never knew you could do that with uGUI. Seems that nobody ever actually uses it and always use mouse. lol

Thanks! I will check into uGUI.

 

I think if you used getaxis it will work with controller, wasd, & arrow keys by default (unless you remap them)

 

Plus, if you use a little laziness, I'm sure there's a way to make it so that the same code interacts with the menu for a joystick or keyboard. Mouse interaction is a no brainer, although you gotta watch it with uGUI and layers, objects like to block each other and clicks like to pass through unless you work it just right.

 

Thanks! When I had the importer issues I was looking in the animation forum and saw your thread. Thanks for sharing that btw. I happened to have the root bone pointing up already, but that was more luck than anything else.
I'll check rigify and download some free rigs from blendswap and see how they do things. I can live with a few empty bones in the imported rig. For IK solvers I had bought FinalIK, so that's what I'm gonna use. Writing those myself from scratch would be beyond my capabilities I think.

I noticed an "optimize" setting somewhere in the importer, might that be the thing that makes bones disappear sometimes?

By the way I went with letting Unity import the .blend file itself and somehow that seemed to work better than doing the .fbx export myself. Since it is one less step where I could get a setting wrong I think that's what I'll use for my animated object. For the others the FBX exporter has some benefits, like auto-exporting multiple files by using groups inside blender.

Before I get back to work with animations I'll need to do some more concept art so I don't end up redoing too much.


Is there a best-practice to prevent limbs of animated characters from clipping through walls, using colliders? I don't mean walk IK for feet, I mean arms or knees while walking against a wall for example. I always find it immersion-breaking when I see meshes clipping through eachother, so I'd be willing to put some effort into preventing it, at least for the main player's model.

 

About to jump into Diablo 3 now with my gal. Next time I get a chance to work on the game I will have a look at uGUI and see how much work it will be to get what I am looking for. Then depending on what I find out I will either switch to uGUI or just continue knocking out my custom points allocation thingy.

 

The Event Manager that gets created when a Canvas is created is how you can use arrow keys to handle events. Canvases are inherently tied to that Event Manager. You can even get a reference to the Event Manager and wire up custom events, to make a dynamic UI. Usually it's not necessary.

 

Why not just turn color/category pair into single class/struct? Those work out of the box in inspector.

 

Not sure where it's going, but I liked exploring. There was a sense of the unknown to it, until I explored the whole area.

 

There's also http://freesound.org/

And Kevin MacLeod very kindly makes a huge library of music free for use at http://incompetech.com/

Just wanted a bit to what others have mentioned. Keyboard and joystick navigation is built into Unity UI's standard input manager. You don't need to do anything special. It reads the Horizontal and Vertical axes, which means it works with WASD/arrow keys and joysticks.

Navigation is normally automatic, but you can change it to Explicit to manually specify where up/down/left/right go.

The one catch is that you need to give an element focus. You can do this by assigning the Event System's First Selected field, or in script by assigning EventSystem.current.SetSelectedGameObject().

 

Thanks for suggesting uGUI. In the end I had a look at it and returned to creating my custom GUI.

Mainly because as I mentioned I had it nearly completed anyway:

Works just as I wanted. Of course, there are some tweaks needed still as far as the GameManager needing to be aware the GUI is onscreen so it just needs to set the appropriate flag so the game goes into a Pause mode until the player is done messing around with the GUI. Currently, navigating in the GUI is also picked up for player navigation in the world. lol No biggie though.

Soon I'll be able to do a new build with this in. Of course, so far there is only item in the game that actually gives the player an attribute point. I will need to add more as things progress.

 

It looks like the player is moving in the demo I guess you'd want to disable that if the menus open

 

Yeah that is what I wrote... "Of course, there are some tweaks needed still as far as the GameManager needing to be aware the GUI is onscreen so it just needs to set the appropriate flag so the game goes into a Pause mode until the player is done messing around with the GUI. Currently, navigating in the GUI is also picked up for player navigation in the world. lol No biggie though."

 

It is kind of surprising that after all of these years of Unity being around there is not an easy to use rapid development tool for making customized GUIs. I even looked on the Asset Store and all of the stuff just seems like the author's own version of uGUI. Just basic element by element stuff. I can do that kind of thing myself just dragging sprites around and programming it all.

Makes me think if someone made a rapid dev tool for custom GUIs it would probably sell well. Maybe one day when I have no project I am working on (so basically never) I will create one.

 

If no one has done it so far my conclusion would be that it's not that simple to do. I've seen a thread around here where someone was working on a generic main menu / options menu that looked pretty good and he was talking about putting it on the appstore. Afaik he never did. I think I watched the thread, so I should have gotten a notification.

 

Heck I think it'd be cool even to have an asset that came with say 24 different prebabs of custom GUIs.

Basically have like 4 different layouts and then 6 different flavors of GUI for each one. Like some may have a progress bar and others would not but would have other things.

The idea being that even though few would be perfect match for what is needed there would certainly be one that could be used as a template and easily modified to get what we need.

Of course, the best way would be to just make everything modular. Labels, text input boxes, progress bars, drop down boxes, radio buttons and so forth. Yet still offer base templates for the layouts. Like say there are 12 different layouts each containing slots to place controls in. And then we just quickly click and choose the control for each slot. Unused slots are just left empty and do not even show up in runtime.

Of course, more and more layouts as well as custom controls can be created over time.

Basically just rapid development. That is what I am always after. Click here to change the background color of the window or set a texture / sprite for it. And so forth. Quick n easy the way GUI design in 2016 should be!

And I need to stop thinking about it or I will end up putting my game project on hold to build this thing. lol

 

I always thought doing an option menu that would make total biscuit happy, get an endorsement from him and everyone making a PC game would buy it

 

Not a bad idea actually.

I contemplated having fps lock settings of "cinematic" and "glorious pc masterrace" if I were to include that as a feature.


I did a quick google and this seems worth a look I thought:
https://www.assetstore.unity3d.com/en/#!/content/33781
https://www.assetstore.unity3d.com/en/#!/content/27226

And I stumbled over this, a dev console asset (there are fancier ones on the store):
https://www.assetstore.unity3d.com/en/#!/content/16833
I'll probably buy this, for testing things out during development. This might be even quicker to try things out than build a menu for it.

 

It's just overkill. It's better to make what's needed for this game, rather than some epic generalized swiss army knife thingamabob. I think sometimes us nerds get obsessed with the cool factor of one tool to rule them all. I'd personally like to see you develop out an adventure and put more magic spells and items into your game. Go even further into the imagination aspect, you have got the technical part down.

 

Must.....not.....meme......this......with.......a........picture........of.......Bill....Gates........in....a.....crown

 

But with the asset store you can allways tell yourself you're gonna release it as an asset later to justify featurecreeping every aspect of your game into something big and universal ^^.

 

No worries. I was eager to implement the Attribute GUI system so it actually does something.

Now available for web play: FPS Action Adventure Version 0.2

The game window has been increased from 800x600 to 1024x768 just because I think it makes it a tiny bit more immersive. Of course, you can always Right Click and select Go Fullscreen. That makes it the best I think.

The only attribute upgrade that actually does anything at this point is dexterity.

Increasing dexterity increases your movement and turning speed. Ultimately, it may slightly increase your ability to dodge incoming attacks. When maxed out you'll get a whopping 50% increase in movement speed and a 25% increase in turning speed.

The way I see it different players like different things. Some will enjoy pure speed just trucking along a fast as they can. Others will be more defensive players and will prefer slow & steady with high defense or in this case high Vitality (which of course powers up your health). Others will just want to be a real powerhouse of a mage. Strength is their friend. It increases the power level of your skills increasing the speed and damage. Increasing wisdom reduces the cost per spell cast and increases the rate at which mana recharges.

Oh yeah guess I never mentioned each spell will cost a bit of your mana. Of course, the mana bar probably makes that obvious. Anyway, your mana will slowly recharge over time. Of course if you happen to find a mana potion you can fill it instantly.

Of course, you must find the item that grants the upgrade points and as soon as you collect it you will see this upgrade GUI.

Remember this is all very early days. The game won't be some massive Skyrim or craziness like that. Just a (hopefully!) fun little action adventure in the style of the classic FPS games with some new twists such as being able to upgrade your attributes.

 

Hey, you never know. The retro 3D and familiar FPS controls could lead to an adventure, maybe you keep adding on to the adventure and getting more and more ideas "and then this could happen..." and you never know where you could end up.

Here's how I come up with so many random ideas... with your game, I would wonder... what would a cave feel like with this gameplay? Where would the cave lead to? Imagine the endless possibilities of a cave to ???? A village? A lake? A lake village? And so the wonder could be never ending.

People like this kind of stuff, even though they'd never admit it in front of all their cool friends.

 

I asked Jupiter Hadley, a YouTuber to cover our jam and she said would would after it ends. She covers more indie games then anyone.

 

That's actually very much the way I do it too. A big part of the reason I wanted to finally try out 3D game dev in Unity is because I felt like as much as I like 2D games it would be far easier less work to build a 3D game in Unity that feels full of adventure than it is in 2D even in Monkey X. 2D is just a lot of work for the kind of games I want to make.

I don't know where people ever got the idea 2D is easier. I'll still do 2D projects like my Halloween & Christmas games but for a while at least will stick with 3D. Most of my custom tech and workflows still work anyway. Just a matter of ironing out the remaining pain in the arse things. Like I spent 2.5 hours making a little custom GUI for the attribute upgrade. Designing the look, making the images, figuring out how I wanted to actually build it in Unity and so forth. That is something I will need to take care of at some point. Build some kind of slotted template system.

 

That's because problems that are trivial in 2d often turn into significantly more complex problems in 3d space. Rotations, inverse kinematics, collision detection, etc.

Also, producing quality 2d art is easier than turning that 2d art in 3d that has the same look.

I'm not sure where did you find any issue with unity gui. Standard built-in ui is decent, and its only problem is that it doesn't ahve premade progressbar prefab.

This is a game, not a desktop program. You can just paste an image, add some interactive zones to it name it "gui" and call it a day.

 

If you ever come to Austin, I owe you beers*. Good ones.

*: If not beers, then whatever it is you enjoy, provided it's legal and practical for me to obtain.

 

the ui does have a scrollbar

 

Progressbar. Typo.

 

Silly, no one expects you to turn it into Skyrim. We expect you to turn it into Sword Art Online. Duh.

I like what I see of it. I'm probably going to FF-review yours next.

 

Or maybe realms of the haunting.

 

That is basically the way I do things. I am used to always making the menus and other GUIs kind of "alive" with glowing / bouncing text or whatever so that is why I don't just use a single image for the entire thing. And for this particular GUI I needed basically a progress bar but did not see any in the uGUI. Mainly I already had spent the time to build most of it out by the time I asked.

From what I saw it would have taken just as long to build it using the uGUI and likely even more from the learning curve. I mean to build it out so it looks and works the same way it ended up going the custom route.

Well for rotation and collision detection that stuff should be basic, right? I mean Unity does provide clear methods for those. I just shoot out a cast to detect objects for interaction. Rotation used to be just a matter of matrix math and applying scaling, translation and rotation in the proper order. Back many years ago anyway. But again Unity just manages all of that for us now from what I can see anyway.

Now on the inverse kinematics I won't ever run into that issue because for me any animation I do will be just simple animation sequences. I won't ever need to make a model literally track an object and move around it, touch it, etc. I think people just spend too much time on stuff like that when in reality does the player even care if a character drops down to pick up an object and their hand is visibly above it when they take it as opposed to it actually touching the object wrapping fingers around it then taking it?

Maybe some do. Personally that is just a waste of effort & time to me. Not knocking the people who do spend time on such things. Just saying I don't see the value in it probably because you and many others around here are way more into this advanced stuff than I am.

 

You do realize that this is just 2..3 images layered on top of each other? Gray rectangle for background, Yellow stretching rectangle that implements the bar, and black grid with alphatest cutout on top of that that creates illusion of cells.
I just don't understand what is there worth several pages of discussion.

Actually, no. You're still supposed to understand how rotational matrices work and have decent basics on vector algebra. Otherwise there will be a lot of trouble later.

 

I never said it was worth 2 to 3 pages of discussion. We just seem to keep discussing it. lol

Well now you have hit the heart of it. It's quite simple really. I never approached it the way you have just mentioned. That would have been a much simpler design. The way I did it there are 23 different sprites.

1 for the window image that has the text, the gray blocks background and the black separators.
1 for the Points Remaining indicator at the top
20 for the blocks (5 in each row x 4 rows)
1 for the cursor

For some reason I just have a difficult time thinking "simply" whenever I am working in Unity. I am not sure why.

Clearly, as you said, using 1 image for the window base, 4 sprites scaled in x for the bars on the attributes, 1 sprite for the overlay of the cell dividers and 1 sprite for the cursor would have been much faster and simpler. Had I done it in MX or something I likely would have done it that way. Something about working in the Unity Scene Editor just makes things different for me. Always has. Not sure what it is or why but am working on getting over it.

Of course, if I just went back to doing a 5 second paper design first like in the old days that would have helped too. lol
Normally I don't need to do that anymore but maybe as I get back into Unity I will start doing that again instead of designing on the fly as I build.

So there you have it there was value in this discussion. I imagine even something like this GUI people would have built it in a number of different ways with some even using separate elements for each piece of text on the window.

It seems to only happen on 2D stuff though. So far I am just developing in 3D the way I normally do in 2D (in anything besides Unity) and that has all been straightforward and simple. But when I am doing 2D stuff in Unity it has always been a pain in the ass compared to doing 2D in other frameworks. Which is fine because I'll use Unity for 3D projects and MX for 2D projects.

 

General recommendation.

Try to always follow KISS principle.

Meaning, that if you ever start thinking "Oh, I know how I'll do that! I'll write that elegant and extensible small framework for that! It'll be FUN!".... immediately stop, step back, abandon the "amazing" idea you got, find the dumbest solution you can think of that will still do the job, and implement that instead. Ideally that soltuion would involve writing as little code as possible. If you don't write anything, but the problem is solved, that's the solution you needed.

I think that there's a part of brain that sorta represents your "inner programmer/engineer", that gets REAAAALLY excited about complex and interesting problems and would love to spend eternity dealing with those. The thing is, that usually gets in the way of actually getting things done. It is easy to get distracted, waste a lot of time inventing some amazing way of dealing with contents of some unimportant subroutine that only gets called once per year on specific days and only if that day is friday.

So, it is necessary to keep the urge to write amazing /elegant/nice-looking/complex/advanced stuff under control, and that's where KISS principle comes to play - it is pragmatic.

 

Or treat it as a separate project to make an asset that can be sold on the asset store. But be sure that you do keep them separate, don't mash it up with the current game project, get the game done then do the new asset or vice versa otherwise neither project may ever be completed. (Plus the asset store may give a small income stream).

 

Ha ha. You guys are right on both accounts I think. Actually I do always go for KISS. Big time. That is why I don't even look at lighting and inverse kinematics and all of the other things I see people focusing on around here.

Like I said it is just that ever since the first time I opened Unity I have wrestled with this issue. I think it is something to do with working visually in it. Like it kills my logical thinking process or something. But I'll get to grips with it sooner or later. Normally when I am doing game dev it is all just code other than a little time in a Map Editor or when making graphics and so forth.

Of course at work I do GUI design using the drag n drop controls for C#.Net app dev and yet still design and code fine. Like I said there is just some disconnect between Unity and I. I don't know what it is exactly but hey I am making progress and that is what matters most to me.

The GUI is all done and working beautifully so my mind is onto other things now. Looking forward to getting back to work on the game tonight.

 

In extremely poor taste, I've decided that to make the game more interesting, there will be gas cans that will serve the purpose of extending the amount of time that you are on fire, provided you are already on fire when you touch them. There are now spider webs that you can burn up by running through them.

I need to add:

Deadly obstacles that kill you when you touch them
Spiders that kill you when you're normal, but die if you're on fire
A pretty bloody death animation, since that seems to fit the style
Switches and doors
Explosive blocks, probably TNT bricks
A giblet death animation for when you get exploded

But the laziness... the struggle is real...

 

build the explosion & death animations. They are always fun & distracting/motivating. Test them on everything inappropriate just so you don't need to code all that other stuff before you get to watch it.

 

Actually, given the game name, it could be an endless runner where the guy is on fire & has to see how far he can get before the flame goes out. Gas cans will explode & give a boost in distance if the player aims the exploding effect properly or they can choose to pour it on them to keep the flam going longer. The players flame can peter out over time. Obstacles delay the player restricting the distance & there could be water traps &/or firemen to avoid.

(just being silly here)

 

I don't want it to be endless, but yeah, there can be pouring water to avoid. It's basically going to be a simple platformer where you try to figure out how to get through the levels. For now it's just partway into day 2 though. So, gimme a sec

 

Right now im working on adding bots to the arena so its not so lonely. The announcer will even make fun if you get killed by a bot. Ill add next update.