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).
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.
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.
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!