Paid job offer: unity textbox replacement. (Retracted for now)

[x4000]

Hey folks,

I know we have a number of programmers on here.  Any of you familiar with Unity, or in particular the AI War build that is currently in use, know how wonky their terrible textbox support is.  I have coded single-line textboxes in the past (in GDI+, as a replacement for the built in ones -- don't ask), and I've done attempts at multi-line textboxes, but there are a lot of side use cases that are completely frustratingly bonkers there.

Anyway, I've got plenty of other things going on at the moment and this really isn't something Keith or I have the time to devote to.  So if anyone else is interested in a paid gig to develop this for us, please send me a PM.  Incidentally, this is something you are then free to turn around and sell on the Unity Asset Store if you like.  I imagine that selling something like this for $5 or so a pop if this is high quality would net you some good ongoing revenue on top of the initial development fees we'd pay you (which would obviously be much more appropriate given the first-customer basis).

The Specs:

Restrictions:
------------------------------
1. Your version can use GUI drawing methods for sprites if you wish, but no gameobjects or anything like that.
2. You can't use any of the native unity calls to textboxes.  I'm basically talking about you draw some text, and then a box that represents the area of the textbox, a line that is the cursor line, and then handle mouse clicks.
3. For the scrolling of a multiline textbox, please do not use the actual unity scrollbars.

Rationale for these restrictions: We are not going to be using these in the GUI layer at all, and won't be using the unity fonts at all, actually.  We'll be using our own existing GUI framework, which is a lot more flexible and efficient, and we'll be using our adapted version of EZGUI's SprintFont and SpriteText (that already runs outside the GUI).  The textbox is literally the last of our code that uses GUI.whatever for anything other than mouse clicks or keypresses, and we want to get even that out of our code.  Partly because it behaves so very badly in the default unity implementation.

Single-line textbox:
------------------------------
This is the relatively easy case.  It should basically work and feel like the single-line textboxes that we all are already familiar with.  Specific specs:

1. When you are not clicked into it (focused on the control), it should just show the text, period.

2. If the text is too long for the textbox area, then it should scroll to the left or right as you type (as single-line textboxes in windows do).

3. It should draw the little line cursor for your current keyboard cursor location when it has focus, and you should be able to click anywhere and have the cursor go to that click offset.  Including if the text is scrolled over.

4. Drag-select, copy and paste via keyboard shortcut (OS-specific in windows, OSX, and linux), and typing over highlighted text to replace it should all be supported. 

5. Dragging and dropping highlighted text is not required, but is a nice touch if it is easy.  That part is really not very important, though.  Similarly, you definitely don't need to support "Overwrite" mode from windows, just the regular "Insert" mode (aka, the modes that the Insert key toggles between would just stay on the one everybody uses).

6. Tab should work, but should insert 5 space characters rather than a \t.

7. Delete and backspace should work as expected, and there should be an optional event hook for the return and enter keys (just one for the both of them) that lets us trigger special functionality on those (such as sending a chat message, for instance).  I'd also like a similar hook for the Esc key.

8. This should not flip out and work incorrectly no matter how many single-line or multi-line textboxes (any combination) are on the screen at once.

9. Double-clicking a word should highlight it.  The arrow keys should move you around.  The home and end keys should work.  Ctrl+A/Cmd+A should work, and whatever the linux equivalent is.

10. Holding shift and moving your keyboard cursor around should add or subtract to your current text selection based on the current position of the keyboard cursor relative to the selection start.  Same deal with the home and end keys while holding shift.

That is all that I can think of for the single-line textbox based on our experiences with the unity version (which does not meet all these specs), and based on my own past experience coding these. 

Largest Single-line textbox Obstacle:
------------------------------
One of the most major challenges that you'll have is that, unlike in GDI+ or similar, there is no easy way to define a clipping area that I am aware of.  So doing the text scrolling is incredibly awkward in some senses.  If you figure out a way to do clipping areas, I'd definitely pay a bonus for that, as it would be extraordinarily useful for us in a variety of other contexts.  Right now we use diffuse coloring to fade out text and images in things that we scroll, and then stop drawing them entirely once they leave the area that would be the clipping area if we had one, and that works but isn't exactly elegant.

Multi-line textbox:
------------------------------

1. Everything from the single-line textbox pretty much applies here.

2. However, this should be able to be defined as vertical-scrolling or horizontal-and-vertical-scrolling.  The former is what is generally used (such as on these forums!), while the latter is like a code IDE.  Useful for things like the scripting interface in Shattered Haven's level editor, for example.

3. In the case of vertical-scrolling, we'd be looking at vertical scrollbars appearing only when there are enough lines to warrant it.  We'd also be looking a word wrapping, and the added complexity that this brings to actually find a click offset.  HOWEVER, in the case of our EZGUI spritetext rendering methods, we wind up calling a "wraptext" method that does the wrapping based on a stated maxwidth, and then gives a resultant string with all the linebreaks in there.  So in that case you could easily create an array of linebreaks from the text wrapping, and then do offsets from there a lot more easily than otherwise.

4. For vertical or horizontal scrolling, I want to make sure we're not having to render a bunch of text that is off the top or bottom of this.  Let's assume that someone might type a small novel in one of these; I still want it to perform reasonably well.  We can set a maximum use case of something like 100k characters for reasonable performance, and 10k for very good performance.  This is one of the trickiest things with multiline textboxes, in my experience with coding them.  Anyway, so I don't want to draw a bunch of extra lines that are invisible but clipped out.  Drawing one string per line shown on the screen would be acceptable, since the GPU performance hit of that won't be too extreme and it is typically in lighter-GPU-load parts of games anyway (menus).

5. Multi-line drag selection is definitely something required here.

6. As someone types, or uses the mouse to drag-select, or uses the arrow keys to move around, auto-scrolling horizontally and/or vertically should act in a sane manner.

7. The PageUp/PageDown keys should work, and should also work with selection just like home and end and the arrow keys would.

8. A single line break should be \n.  Any entries of \r should simply be stripped out when the text is first put into the textbox.

I think that's about it for the multi-line textbox.  If there are any other common functions I am overlooking, they would be nice.  The big thing for both textbox types is making sure that they feel natural to players, because the current ones really don't.  Part of that is, of course, performance, which is mainly an issue with the multi-line ones.  Frankly most multi-line textboxes are going to use 1,000 characters at the extreme upper end, but I want to make sure this doesn't break down with larger numbers.


If you're interested, please shoot me a PM and a proposal for a timeframe and a quote.  Given the nature of this project -- it's easy to kind of mess this up, frankly -- this is payable on delivery.  I don't want to get stuck with the bag if someone takes it on and then discovers partway through that this is beyond them.  But if you nail this, I am absolutely more than happy to pay, because this has been a bugbear for us since 2010!

Thanks!

[keith.lamothe]

1. Your version can use GUI drawing methods for sprites if you wish, but no gameobjects or anything like that.

To clarify, do you mean functions in the GUI class like GUI.Label() ?  I'm guessing we'd want that to not be used, as we don't intend to invoke OnGUI() at all in the future (iirc).

Or by "for sprites" do you mean only GUI.DrawTexture(), which we'd then replace with our own engine's drawing wrappers?

Perhaps it would be good to say "don't use any built-in Unity methods we don't specifically approve"?  Just to avoid somebody completing something that technically meets the specs, only to find it uses some bit of unity we don't want to use, etc.  Though perhaps it's the sort of restriction that leads to having to ask for too many approvals, etc.

[x4000]

That's a really good point, yeah.  No GUI.Label() or anything of that sort.  But GUI.DrawTexture() would be fine, since I can convert that to my own non-GUI code linearly.  It's probably best that any takers on this clear any methods they use with use that are unity calls at all, just to be sure, as you note.

[Draco18s]

I pointed a friend of mine at this who earlier was making a ton of fixes to FMOD (apparently Unity only integrated the barebones of it for 4.6) and said that this is obsolete with 4.6

I still understand wanting to move away from the GUI functions, I just thought he might be able to help.  Apparently not.

[x4000]

I do know that as of 4.6 they are moving to a new GUI system, which is fine.  However, I don't really have much intention of shifting to it, as their entire approach is a bit counter to ours.  The way they handle fonts isn't ideal for our purposes, and things like inline font colorization and so forth really don't work as well, as well as the ability (in our unique case) to integrate aspects of our GUI more deeply into our own graphics pipeline, which sits squarely on DrawMesh and DrawMeshNow, and doesn't use any gameobjects or any of that jazz.

Even when Unity2D came out, that still wasn't something I was interested in, because their workflow is just so terrible compared to ours for the sorts of games we want to make.  It's a great workflow for other kinds of games, and a super common style of workflow in general, but it's not for us.  Same with the way they handle GUI stuff, hence my looking around for someone for this.

If someone is interested in the work and can do it, it's not going to be obsolete for us.  I can't speak for the further value on the Unity Asset Store, but that was more of a bonus in general; the negotiated rate between us and the contractor ought to be sufficient to make it worth the contractor's while, or we aren't doing this right.

[Draco18s]

Oh I know.  I know.

[Hearteater]

You've gone and made me curious so I installed Unity today. Curse you! I realize you may already have this issue resolved but I figured it to be an interesting project anyway. Just to speed me in the correct direction, it looks like this would NOT be a MonoBehaviour since you don't want it part of a GameObject? Also, what specifically is the clipping issue? I'm baffled how any game engine can be missing clipping. That's kinda core functionality  .

[Draco18s]

Also, what specifically is the clipping issue? I'm baffled how any game engine can be missing clipping. That's kinda core functionality  .

3D engines, which Unity is at heart, don't offer a "clipping mask" in any easy way.  You have to cheat.  Usually by creating another object that only writes to the depth buffer and only in the pixel areas you don't want rendered for that thing you're masking.  Which also, inconveniently, hides everything else behind the textbox to boot.

So then you need a second camera....etc. etc.

[Hearteater]

Hmm, in XNA you normally do something like using a scissor rectangle although you can use a stencil buffer too. Does Unity not have any spritebatch equivalent?

[Draco18s]

Hmm, in XNA you normally do something like using a scissor rectangle although you can use a stencil buffer too. Does Unity not have any spritebatch equivalent?

It might, I haven't looked into using sprites.

[x4000]

Heya!  Okay, let's see, to the questions:

1. First, thanks for taking an interest!

2. This would be a standalone C# file that is called via a monobehavior on the camera gameobject.  In other words, our game code has one monobehavior that is on the camera, and then ALL the code comes off of that.  We basically use it for a gameloop and that's it.

3. Using multiple cameras to do something like this is definitely way over the top of what I'm willing to contemplate.  Too many potential compatibility things.  Not that I think you were suggesting it, Draco, but yeah you are right on how other people tend to do it.

4. In XNA you can do a number of things that you can't do in Unity, because XNA is using the Direct3DX extensions, which is generally not available to most programs.  Unity uses Direct3D and OpenGL interchangeably (its shader language mimics HLSL iirc but is definitely cross-compiled to either one as the need arises).  SpriteBatch is something I used to use a ton of back in my raw DirectX9 days and then my SlimDX days, and I absolutely loved it.  It was super handy.  But it was in a helper library, not part of the base functionality of the DirectX system (at least as of DirectX9 -- that may have since changed, but I've never used the newer ones for compatibility reasons).

5. I could definitely see something tricky like the stencil buffer or something working, but I'm going to be honest that I don't really understand what that is.  I've read about it before, but I just never have really retained the info because I never had to actually use it.  In Valley 2, for the lighting I am using the depth buffer to do a form of clipping, though.  But it's not more widely applicable, unfortunately, I don't think.  Basically I was having some shaders draw to the depth buffer and others not, and then translating the depth buffer float into a diffuse overlay on the whole screen.  Aka, you get the lighting, and it carves out and is additive and can have fancy shapes, etc.  I used that again in Shattered Haven, I think, but it's hard to remember.  Valley 1 used a different kind of lighting, one much more primitive but quite cool looking in practice.

6. Overall the clipping isn't really the #1 issue for me.  That can be solved with simple fades, really.  And pure clipping isn't a solution anyhow, because if someone writes half a novel in a textbox and you draw it all but then clip it, well, that's pretty inefficient.  You wind up needing to clip the text somewhat anyhow, although usually you'd leave a buffer area where you overflow and then clip that.  Here you lose that ability.



The overall textbox issue is something that we've solved in the sense of AI War not acting absolutely insane anymore, though, so there is that.  If someone had a great solution for this I certainly wouldn't say no, but in the meantime it's not worth nearly as much to me and I don't think others should sink a ton of time into it.

[Hearteater]

Heh, thanks for the info. I've just started messing with Unity, but not surprisingly the way you guys do things doesn't appear to have any resemblance to how things are normally done in Unity . Glad to hear you've got your textbox issues mostly worked out though. I actually ended up in this thread as a result of that strange box appearing in AIW after the recent upgrade (textbox with a scroll bar, even when it is empty).

[x4000]

Heh, thanks for the info. I've just started messing with Unity, but not surprisingly the way you guys do things doesn't appear to have any resemblance to how things are normally done in Unity

No problem.   And yep, their thing was really horrible in terms of performance on the sort of scale we needed, so I basically went "bare bones" on a lot of it.  Since we were porting from SlimDX, that made sense anyhow.  We used their baseline GUI fairly directly for a while, but had endless problems with it and so Keith rewrote pretty much all of it from scratch except for textboxes.  So between the two of us, we got it down to using as little as possible of the main unity engine.

Glad to hear you've got your textbox issues mostly worked out though. I actually ended up in this thread as a result of that strange box appearing in AIW after the recent upgrade (textbox with a scroll bar, even when it is empty).

That actually isn't a textbox, it's the message log chat window.  It's drawing the scrolling area at all times because if you don't -- wait for it -- it messes with the focus of the chat textbox DIRELY.  Having it only show sometimes was one of the biggest things that was causing the chat textbox to act insane in terms of focusing and so forth.  Simply making that little scrolling area always visible fixes it.

Hence the little box.

[Draco18s]

3. Using multiple cameras to do something like this is definitely way over the top of what I'm willing to contemplate.  Too many potential compatibility things.  Not that I think you were suggesting it, Draco, but yeah you are right on how other people tend to do it.

It's pretty much how I handled this, although I was able to get away with a single camera because the back-most layer isn't transparent, so it's not clipped by the depth mask.  In the end I needed 5 (technically 6) layers:

1) background
2) Scrolling containers
3) Depth mask
4) Foreground (black border on the container)
5) Tab-thing (sits above the black border)

The 6th is the unrendered containers.  They're actually shunted out of view of the camera rather than disabling them.  Its easier to += and -= the transform than it is to disable a bunch of renderers and colliders.

[x4000]

Whew, wow!