[HIRING] Create a game-like GUI for my project using Unity

in #utopian4 years ago (edited)

I'm looking to hire someone to create a game-like GUI in Unity for an existing project, which is already written in Max/MSP. Therefore, I would like this new GUI to be a full standalone app that can run alongside my existing app, communicating with it via OSC/UDP.

Eventually I would like to build this GUI into a full game with Unity, but for now I'm only looking for the very beginnings of one to be created. Just a bare-bones implementation, a working prototype. Most of the mechanics will still be handled by the existing Max/MSP app, which will simply send OSC/UDP messages to the Unity app telling it what to display visually. All user input will actually take place in the Max/MSP back-end, not your Unity front-end.

The Proposal

For simplicity sake, I won't even explain what my existing app does, only exactly what your Unity app needs to do. It boils down to essentially these things:

  1. Have a UDP receiver set to a designated port on localhost, which will be the source of all your command messages.
  2. Place a large number of simple spheres on the screen, which grow from a tiny pinprick to their full size over a designated interval and then disappear. Call these spheres the targets and the period over which they grow their morph interval.
  3. Have specified targets suddenly jump to double or triple their full size and potentially change color for a few hundred milliseconds, then shrink back down to nothing. Call this the hit event.
  4. When a target is hit, a numeric score (e.g. +500) will need to pop up from it and then disappear. A cumulative total of the scores will need to be kept track of in a simple text scoreboard off to the side, along with a few other metrics.
  5. When targets are hit at the same time, draw simple colored lines between them.

#1.png
imagine the stars shimmering in the sky (but rainbow-colored) all fading in and out

#2.png

#3.png

The Code

OSC/UDP

OSC/UDP messages will dictate when all these things happen and provide you with all the necessary information. You can watch a sampling of the messages as they're sent below.

The OSC/UDP messages are as follows:

amanuensis/wake/ i

  • An update to a variable called the wake, which is an integer denoting a number of milliseconds (see below).

amanuensis/tolerance/ i

  • An update to a variable called the tolerance, which is an integer denoting a number of milliseconds (see below).

amanuensis/played/ i i

  • This is the message that will spawn new targets. Many will be created at once with each of these messages.
  • The 1st argument is an integer that can be called the track. The numbers here can vary from -16 to 16 (excluding 0).
  • The 2nd argument is a unique millisecond timestamp denoting when the event occurred in the main app. Call this its timestamp.
  • These timestamps will need to be stored in an array of some kind or dictionary, because there's a small amount of calculation that will need to be done with them before they're used. The incoming timestamp should be stored and then have each other stored timestamp subtracted from it. This series of numbers will be the morph intervals for each of the targets that should spawn at the moment this message comes in.
  • Do not spawn targets for any interval that's over the number of milliseconds found in the wake variable.
  • All of the targets that spawn at this moment should be associated with the track in this message (1st argument).
  • Targets need to vary by color based on track.
  • Track numbers will be both positive and negative. Without getting into the reason for this, just know that targets from negative tracks will need to appear somehow brighter than their positive counterparts so they stand out by comparison, but still be of the same color. It could just be the positive targets that are a darker shade or even semi-transparent.
  • In this prototype version targets can simply appear at completely random locations on screen.
  • For each target that spawns, its track number and interval will also need to be stored along vwith its timestamp for later reference.

amanuensis/hit/ i f l

  • This message will trigger one or more hit events.
  • The 1st argument is an integer denoting the track all the hit events should be associated with (not necessarily the same track as the target(s) themselves). Again, -16 through 16, excluding 0.
  • The 2nd argument is the interval of the successfully hit target(s).
  • The 3rd argument will be a list of any length, consisting of the timestamps of every target that was hit.
  • Since a single amanuensis/played/ message (and therefore a single timestamp) will spawn multiple targets, target objects on-screen will need to be looked up first by their timestamp, then by their interval, when determining which target(s) are about to be hit.
  • The interval (2nd argument) may not be exact. When looking for specific targets, you will need to assume +/- a few milliseconds when comparing against the value of stored intervals. Specifically, this few milliseconds will be equal to the variable tolerance, so the comparison will be incoming_interval - stored_interval <= abs(tolerance). In the rare event multiple intervals under the same timestamp are within tolerance milliseconds of the specified interval (2nd argument), they should all enter into hits.
  • Once the hit target(s) have been identified, the event(s) can begin. Hit targets should suddenly double or triple in size for a few hundred milliseconds, then suddenly shrink back down to a tiny pinprick so they can restart their morph interval.
  • During these few hundred milliseconds, the targets should change color according to the track in this message (1st argument), using the same color scheme as the targets themselves (including the difference in shade/transparency between positive and negative tracks). After the event, targets should return to their normal color.
  • If there is more than one timestamp in the list (3rd argument), then lines should be drawn between each of the involved targets in the hit. These lines should form a single chain from oldest target to newest (based on their timestamps) and also be colored by track (1st argument of this message). After the event, these lines should be removed.
  • Each target that's hit will need to have a numeric value (e.g. +500) pop up from it and then disappear. This value will be equal to its interval.

amanuensis/cleanup/ i

  • This message will come in eventually for every target, signaling when it can be removed from memory.
  • The 1st argument is the timestamp of the target(s) to be removed. Since more than one target can be associated with a single timestamp, when this message arrives it means all targets with this timestamp are ready to be removed.

I'm not familiar with Unity, but I'm sure using its game engine will mean having a central main function that executes every frame. I would also like to specify there be a target class as a separate file, instances of which would be created for each target that appears on screen, and the hit event be part of that class.

Communication

Reply to this post for more details. I can also be found on discord @to_the_sun#5590 or you can message me at soundcloud.com/to_the_sun.

Coin Marketplace

STEEM 0.36
TRX 0.12
JST 0.039
BTC 69965.85
ETH 3540.49
USDT 1.00
SBD 4.71