Did a brief presentation today on MDNS, DNS-SD, and AirPlay... Nothing too technical, but showing the start of the inner workings of how AirPlay isn’t too hard to tap into.
MDNS
MDNS is Multicast DNS - a local-network, decentralized, DNS. What this allows for is things like routing http://AppleTV.local calls to the Apple TV on the local network. How? All the devices that want to allow access via this URL broadcast to a known location, saying they will be known as DeviceName.local - When a call needs to be made to DeviceName.local, there is a local resolution of the IP address: “Hey, raise your hand if you are DeviceName!”
DNS-SD
This is similar to the MDNS setup, but instead devices announce capabilities. Devices or applications will again broadcast to a known location on the network and say what they support: HTTP Server, Printer, AirPlay, AirPlayAudio, etc. When something like a printer discovery service or an iPhone needs to find a certain type of service, they ask: “Who here can print things?”
AirPlay
AirPlay servers announce two things, their name on the network and their capabilities. Your phone then jumps through the hoops to find the devices that can accept airplay and their location on the network (IP and Port of the service). Once the resolution has been made, the fin begins. Simple things like playing a video are just a HTTP POST - http://AppleTv.local/play with a payload specifying the URL of the video.
Boofday Froyo for Tinker Bell - got her own little taste, enough for her to experience her first brain freeze. Happy 3rd Boofday Tink! (Photo credit, and more Tinky Photos at @lm.sartin) #boofday #dachshundsofinstagram #dachshund #doxie #yogurtland (at Yogurtland Marina del Rey)
Creating games, websites, software, and even non-digital pieces of work takes time and consideration. Questions always come up and they can’t always be answered fully when the outcome hasn’t been done before. Will my creation fill the intended purpose or solve the problem? Can I feasibly make my idea work? How hard will it be to pull off? Will people like it? Prototyping is just one tool to help answer some or all of these question.
What is prototyping?
Prototyping is the act of building a prototype which is in reality an early version, a test or a mock-up of your end goal. Prototyping allows teams to form a workable understanding of the problem and solution. The product of prototyping should address the challenge of creating the end result and the need for it - how much the market wants the end result or to entice the market into wanting it. Prototyping is not a fast build on an entire product; it is instead a probing of the dark corners, a look into the areas the team may consider challenging, not defined, or refining the idea for the target market’s wants.
Through prototyping, many solutions and ideas are given a chance and the outcomes can fold into a more polished final product. Testing multiple ideas, even odd ones, allows for more thought and consideration into the next step of work.
How should I approach prototyping?
There are plenty of ways to build prototypes, but they all start from some assumptions of an end goal. Examples could be a swinging mechanic in a game, an app that helps you collect your favorite recipes, or even a machine that automatically adjusts your chair for better posture. Each problem-space and unknowns of the product lead to different approaches in prototyping.
Focussing on an outcome of answering how challenging the task is, the team will generally produce a primordial working solution - a demo or schematic. In this case the goal is to understand if the idea is even able to be completed and how much effort it will take to complete it. In this type of prototype, usually one or two key functions of the end goal will be demonstrated to a small scale - works best for game mechanics or innovative tasks.
When a team is unsure of the market need or trying to sell an idea, building wireframes or mock-ups to show to their target market is an end goal. The team’s outcome should be focussed on refining the idea to the feedback of end user input, understanding their needs. During this stage of prototype construction the team should be constantly seeking feedback from potential users and peers.
Building a prototype should never be a singular outcome, after all there’s more than one way to skin a cat. Considering multiple options gives opportunity for feedback and understanding that may result in new approaches. Care must be taken to not spend too much time on any one idea or on too many ideas, overly refined choices or too many choices makes it challenging to choose the best solution.
When should I prototype?
Prototyping should be done before starting into a risky portion of the project. Generally, projects with start with a prototyping phase - one which sets the tone and direction for the first section of work. Once the project starts you are not done prototyping, there are still more questions to answer as you go along. In software development, developers may “spike” features - this is prototyping the solution to the problem and get an understanding before tackling the complexity of the entire feature. Other projects may call for mock-ups or approaches to re-validate the direction. Ideally, you should be prototyping any phase of work that has unknowns!
Examples
Sometimes prototypes can take go through multiple stages. Here is a game prototype where some assumptions were made, sketched and eventually turned into a playable prototype. The focus was to test the assumptions of a game mechanic and then get buy in for further development.
Assumptions, designs, and ideas for a game mechanic
Game mechanic in a minimal prototype to test and demonstrate
Woo! I have my first build of an HTML5 engine working as a bower package. It is definitely alpha and needs tons of work, but it is exciting. Harnessing the power of Pixi.js and Howler.js and lots of my own code for scenes, layers, input, and more!
At some point this may be open-sourced, but right now it is private. Look forward to a game in a few months that will be built in it. More details later.
In just shy of 2 months I turn 27. In the spring of 2013, just over 2 years ago, I made a goal of doing full time game development work by the age of 27. During that same life planning session, I also made goals to get back into better shape. I am happy to report that both goals have been met! I am done, life is set... Or is it? I can’t stagnate - I must push further. By the age of 30, I plan to elevate my game development skills and tackle native and console arenas.
I currently am a web game developer for Ludomade, a really awesome marketing and game company. While I am happy I am making games, I would love to move away from web and more towards the native builds. In my short time with Sony, I realized I have a passion for console and platform development and want to pursue it more. That is not to say I am leaving Ludomade, it just means I am filling my spare time with C++ and C development instead of Netflix and Disney Infinity.
What’s next? Well, I am planning on doing lots of spare time learning. Reading the Game Engine Architecture book, building some demos in various setups (RayLib, SDL2, Unreal, etc), and growing! One day I would love some work in systems design - like combat systems or such. We will see where it goes and what happens in the next 3 years.
Super long term goal: Lead role at a place like Ubisoft, Naughty Dog, or my own studio. We will see! I have been blessed so far.
baratheonpilled
2087
dededos
kianamaiart
andulkaphoto
tangentwithtanner
annaxmalina