Good afternoon. Thank you very much for coming. This is session 512, Game Solutions Open Play with NetSprocket. And today we have a very special celebrity guest for you who will share with us his knowledge and expertise about network playing and open source. I'm very happy to welcome to the stage, from IdeaS to the Deep, Lane Roathe.

Thanks. All right. As he said, I'm Lane. We're going to cover OpenPlay with NetSprockets. So, as an introduction, what is OpenPlay? OpenPlay is part of Apple's open source effort, the Darwin group of open source projects. It is a has been out for a couple years and we'll go into more about where the open source effort is.

We'll also discuss the APIs briefly. I will go through an actual example of the NetSprocket API and how to use it in code.

will give you a demo of a couple of a application that uses OpenPlay. will also cover a little bit on how OpenPlay and its APIs compare to some of the other networking APIs that are available. And then we'll wrap up.

Okay, so as I said, it's one of the open source projects that Apple has put out. Whoa, a little bit too far. It's a collection of protocol and platform independent APIs that consists of three layers. There's a game layer, which is the NetSprocket layer. That was formerly a separate set of libraries. It's now integrated.

is a high-level, easiest-to-use, and can be used to get actual networking going in a day, if not just a few hours. There's a set of protocol APIs. That is the basic OpenPlay API that everybody has known previously. And it is basically a set of APIs for talking to some type of transport protocol and sending and receiving information. The NetModule APIs are what is used to wrap each protocol API that the system has into a set of common API calls.

So, a little bit of history on OpenPlay and its contained NetSprocket. OpenPlay started out as Uber. It was developed by Bungie with cooperation from Apple. And they designed it from the ground up to be running on multiple platforms and using multiple protocols. NetSprocket started its life out as part of the GameSprockets collection under OS 8 and 9. It was originally based on OpenTransport and therefore would obviously only work under classic Mac OS.

Today's OpenPlay has made a lot of strides over where it has been even a year ago. It has integrated the NetSprocket API set, so it's no longer part of the game sprockets, it's now part of OpenPlay. NetSprocket is therefore now cross-platform, whereas before it would only work under Mac OS, it now works everywhere that OpenPlay works.

NetSprocket is also backward compatible with the 1.7 libraries, so that if you have games out there that you want to update to the newest one, you can replace the NetSprocket library and anybody who still has the older versions of NetSprockets will continue to be able to use it.

The open source community has become very active over the past year. There's been a lot of contributions, a lot of new example applications, testing, some new documentation, and a lot of individual effort on a few people to really move the project forward. It's now being used in several shipping titles, and we'll give you a list in a little bit of some of those. And those titles have been testing Openplay for a whole bunch of different types of networking, and it's working very well. In addition, there is now a POSIX version of Openplay.

And that means that there's now an Openplay that is native to Mac OS X. It does not use Carbon. There is also a version now for Linux. In addition, the Windows version, which used to use a Windows-centric API, has been converted to use the POSIX networking module because it fixed several bugs.

Okay, so the open source effort, although moving forward and actively being maintained and improved, can always use help. We recently did a 2.1 release, and this release included some fixes to the way that NetSprockets gathered messages, and this fixed a lot of hard-to-reproduce dropped packet problems. It also included the POSIX build. It included a couple of new programs. There's a NetSprocket stress testing application and a new example program. Amen.

So if you are interested in helping us out in order to move this project forward and make it even better, there's a couple things you can do. You can visit the open source pages. If you get the project and you start working with it, you make any modifications, please be sure to submit those to us.

And then, of course, the one thing that we really haven't focused on is documentation, so if you guys are using it and you see there's a lack of a documented feature or some errors, you can tell us about them and even better submit the changes. That would really help us out as well. Alright, so what is the purpose of OpenPlay? We'll cover that. We'll cover a little bit about the different API layers and what they are used for. And then we'll go on into the actual usage of those APIs.

The whole purpose of OpenPlay is to give developers a way of getting networking into their code, and specifically games. is a multi-task networked application that is designed to help developers to integrate NetSprocket and OpenPlay in as easy a manner as possible so that you guys can concentrate on the games and not writing network code.

is a platform that is designed to be cross-platform, and we're working very hard to make sure that that continues to happen. It currently runs on Mac OS 8, 9, and 10. It runs under Windows, and it now runs under Linux with the 2.1 release. There are a couple people working on actual Unix builds for it as well. And the main reason for the Linux and the Unix builds would be, for instance, servers.

It is also meant to be protocol independent. And while that isn't a huge issue right now, it does mean that if for some reason one of the NetModules that we provide does not work for you, you want to use a different TCP/IP protocol, for instance, you can simply write a new NetModule and drop it in a replacement of the existing one. For instance, that is what we did with the Windows one to fix the problems in the Windows TCP/IP layer.

There is also AppleTalk support, but that is only available right now for Mac OS 8 and 9. If anybody is really up on AppleTalk and would like to provide us a Windows and a Mac OS X client version of that, that would be really great. Is somebody down there going to volunteer? There are three layers available, as I said earlier.

Let's get back there. Okay. They fit into your application as this diagram shows. At the very bottom is the networking solution provided by the operating system. One or more Talking to that are the net modules, and they talk to the appropriate protocol for that net module. The protocol interface, which is basically where you talk to to do your sending and receiving of data, talks to the net module that is active at that time.

And NetSprocket, which is the easiest-to-use layer and provides a lot of high-level functionality, uses the protocol layer to do all of its networking. Your application can talk to any one or more of the OpenPlay APIs at any time in your program. You can also, at the same time, use any of the low-level OS networking that you may want to use.

Okay, so NetSprocket is your highest level one. It manages information about games, players, player groups. Again, it uses the protocol API for networking. It's very easy to implement and use. There's not a whole lot of information that you have to set up for it. There's very simple APIs that allow you to get the networking up and going. Without having to delve into all the power that NetSprocket API provides.

is a multi-task network of software and software development tools that are used to deliver and manage the data of NetSprocket. In addition, NetSprocket handles all of the byte swapping requirements for the transportation of your data, meaning that the headers used to send and receive data and the type information, etc., are all byte swapped for you. So all you have to do is worry about your data. You don't have to worry about any of the data that NetSprocket handles.

is a very popular platform for networking and networking for the Internet. It also handles the reassembly of packets for reliable streaming, which if you are using sprockets or if you're using the protocol API, you have to worry about collecting your data yourself and putting it into meaningful packets. If you're using NetSprocket, everything you get is a complete packet.

The protocol API is basically a simple abstraction layer over the different protocols. It uses the NetModule API in order to have a simple, consistent API for all of the protocols that it uses. It's a little bit easier to use than the base underlying operating system APIs. It does some things for you that they do not. But again, it's basically just a wrap around them, so you will have to do more work than with net sprockets.

The NetModule APIs, being a wrapper around the base low-level APIs, are very rarely used by applications. They're mainly just there for protocol, but if you need to use them, that's fine. They do contain a few specific calls for each type of protocol that they wrap.

We're going to go over some example code, and this is new to the 2.1 release. It wasn't in previous releases.

It was designed from the ground up to be an actual example program to be easy to follow and easy to use. It should be able to drop into your game. You would need to change a few functions, put in some hooks for handling your messages, and be ready to go. My goal in writing that code was to give you guys something that in two or three hours you could have a networking game up and running.

So obviously it's well documented in the code as well. There are both NetSprock API and Protocol API examples. They're wrapped around a fully functional client-host game. You know, it's very simple. It's text-based so that it will run on Linux and whatever else. But it does show you how to handle players coming in, going out, sending messages back and forth, and, you know, some basic error recovery.

So it should have all the basics that you need to get a networking game going. And it's all factored out nicely into separate files. So all the NetSprocket code is in one file by itself that's meant to be able to be dropped into your code. Same thing for the Protocol API.

It's in a separate file by itself. So again, the whole goal of this was to create something that programmers could use as a starting point in their own applications. Whereas existing examples previous to 2.1 mainly showed you interesting usages of APIs and kind of documented them, but they were mainly test apps.

So, we're going to cover the NetSprocket API in actual code next. This is all taken from the example one source base, although it has been hacked up quite a bit in order to fit into this slide presentation. If you're wanting to see the actual code and what it looks like in the compilable, runnable state, be sure to look at the source code that is in the example one folder in the source demo.

Okay. First thing you're going to want to do if you're going to use NetSprocket is start it up. But before you do that, you should probably make sure that the OpenPlay library is actually available to be used. And one of the easiest ways to do that is just make sure that the NetSprocket initialize function has been linked against your app.

Then it's just one simple call to get NetSprocket started up, and that's the initialized call. In previous releases of NetSprocket, there was a lot of variables for memory usage and stuff that you could set in order to make NetSprocket more stable in your application. We've totally redone the memory usage in the 2.1 release. The default values should now always work. You should not have to mess with those. The only thing you should really need to set is your unique identifier for your game. In almost all cases, this is going to be your application's creator code.

Once you've initialized it, you're ready to start using it. We're going to start by creating a server connection and listening on a port for clients. So you're going to have to build a protocol reference list to be used. So first of all, you're going to create the new list.

Then you're going to create a protocol. In the example programs, we only use the IP protocol since it's the only one available across all the platforms. When you create the IP protocol, you're going to pass it in the port that you want to listen on. is a software developer who has been working on the NetSprocket platform for over a decade.

and OpenPlay are cross-platform, open source networking APIs targeted at game developers. First thing you're going to do is pass it where you want the game reference to be stored. And the game reference is going to be how you talk to NetSprocket in order to send messages, receive messages, get information about games, users, all that good stuff.

Then you're going to pass the pointer to your reference list that you created. You're going to tell it how many players in this game, what the maximum number of players are in this particular game. is a non-profit organization that has been involved in the development and development of NetSprocket.

is a game developer who has been working on a number of applications for NetSprocket. He is the director of the NetSprocket team. He is the head of the NetSprocket team. He is the and OpenPlay are cross-platform, open source networking APIs targeted at game developers.

So, to start up a client, all you have to do to get the basic point started is to tell it the IP address and port, assuming that you're talking to IP. And those are C-springs that you pass in. is a multi-task, multi-task, multi-task software that is designed to help developers is a multi-task, multi-task server that is designed to serve the game. It is designed to serve the game in a way that is easy to understand and easy to understand.

It is designed to serve the game in a way that is easy to understand and easy to understand. is a multi-task network of software and software development tools. It is a multi-task network of software and software development tools. It is a multi-task network of software and software development tools.

Once you're in that join process, your client has tried to connect to the server. It's going to send it a message requesting it to be allowed to join that game. So, you're going to want to loop through looking for messages telling you whether that request is going to succeed or fail.

is a multi-task network of open source networking APIs that are designed to serve as a network The best message you can get, of course, is you're join approved. And that just means that your game connected, the host saw the connection, and approved your client to start into the game. Set your flags to start the game up to true, and you're done.

You also can get a couple of reasons that the request can fail. Your join denied is the most common. That could be because the game is full, the password didn't match. If the game has banning, maybe your name has been banned for some reason. You may also get a game terminate if the host happened to quit at the same time you tried to join. And then you can also get the error message if there was some other error that happened. In that case, you just set your join flag to false, and you're also done.

is a well-known network of software developers. Once you have looked at a message, you want to release the message because when NetSprocket sends it to you, it actually sends you a handle and you want to free that memory up. As this slide says, in the example program, to save code and make everything a little bit easier, we put all the message reading into one function, and we use the same function from both the join request and the application's main loop.

Sending messages is fairly easy. All you have to do is to have a little message packet. At the start of every message packet is going to be a NetSprocket message header. This contains everything that NetSprocket needs in order to send and receive and parse these messages.

is a multi-task, multi-task, multi-task, multi-task, multi-task, multi-task, multi-task, multi-task, multi-task, multi-task. And to do that, in the function where we're getting requested to send a message, we get the length of the message that we're going to send.

and OpenPlay are cross-platform, open source networking APIs targeted at game developers. is a platform for networking and networking for all kinds of users. It is a platform for networking and networking for all kinds of users.

Then you're going to set the NetSprocket header size, and that size is going to include the entire size of the packet, and that's how NetSprocket knows how much data to send over the connection.

is a multi-task network of software and software development tools that can be used to is a multi-task network of open source networking APIs that are designed to be able to provide

You can also have normal messages, which are datagrams. They are one-try messages. They're sent out immediately when you ask for them to be sent, but you do not know if they're going to get there or not. So if that's important to you, you either want to use the registered or you want to have packet tracking on your own.

You can also have a junk message, which is low priority messages. If you have a very busy game and you want to send out like little taunts or something, that would be a good junk message because they are only sent when there's not, when the bandwidth is not being used. Therefore, if you have a lot of movement data being sent, is a software developer at the University of Michigan.

He is the founder and CEO of NetSprocket. is a multi-task platform that offers a wide range of services and services that are available for all players. You can access the services and services and services in the NetSpocket app. You can also use the NetSpocket app to access the services and services in the NetSpocket app.

For this, you get information about the game, and then you simply index into the structure and return the value that is there. The OpenPlay.h file has all the structures defined, so you can look into that file to figure out what structures and what information is available in each. You can get information about groups, players, and games in a similar fashion.

Now, once you have everybody set up, you're connected, you're going to be running your main game loop. And in that loop, you want to call a function to get your messages and handle each of the different messages that you're going to receive. is a software developer at the University of Missouri.

He is the founder and CEO of NetSprocket. You're going to have two basic types of messages. You're going to have NetSprocket type messages, and these are going to be messages like a player has left the game, a player has joined the game, the host has terminated the game.

Those NetSprocket message types, again, are defined in OpenPlay.h. The example program handles all the basic types in the game, plus it gives you a switch statement pre-built with every message type already in it, even though it may not handle every single one of them for that game. You're also going to have application-defined messages. You know, shot fired, player moved. In this example, there are messages that are just messages. There are questions that would be asked and answers that would be given. And again, when you're done with the message, be sure to release it.

When you're ready to quit the game or just end the game, you simply need to dispose of the game. In this case, we're passing it the forced termination flag. This means that you do not want to wait for anything, shut the game down, and go on. And if you're the host, this would force all the clients to quit, and it would send them a host terminated message.

If you are hosting a game, you then have a few more things to do because you created some information earlier in order to be able to start that hosting process. You're going to want to go through and free up all that information. The first thing you're going to do is get the number of protocols that are in the list, and this is the way you should do that.

Don't assume that something hasn't been added to the list. In a later version of NetSprocket, maybe protocols are added to the list without your knowledge, So be sure to use the list count and not assume that you know what it is. is a multi-task, multi-task, multi-task, multi-task, multi-task, multi-task, multi-task, multi-task, multi-task. For each item in the list reference, you are going to want to get the protocol reference. You are going to want to remove that reference from the list. That doesn't free the reference.

It just removes it from that list. Then you can actually dispose of that protocol reference.

So we're going to cover a little bit about the protocol usage now. The protocol usage, or the protocol API usage, is a bit more complicated, and I couldn't make it fit into a nice little slide presentation very well.

So we're going to cover this a little bit in the abstract. It follows the same general format as the NetSprocket API, because that's how we arranged it in the example code, so that it would be easier to understand. There's a lot of issues it has to deal with that the NetSprocket code does not, so that is one of the reasons why it doesn't fit. and OpenPlay are cross-platform, open source networking APIs targeted at game developers.

NetSprocket and OpenPlay are cross-platform, open source networking APIs targeted at game developers. So if you're going to start up a server, you're going to have to create a protocol configuration. And protocol create config is what does that. It basically creates something similar to a protocol reference in NetSprocket. There's a string that you can retrieve with each reference that is a C string and it has a lot of the basic things like IP address equals, port equals, etc.

is a very popular platform for networking. Once you get that on the host side, you're going to want to replace the port in the string with the port that you want to listen to, because what will be there will be just the default one that the protocol API created.

is a host of NetSprocket. If you are a host that also wants to play on that game, you're going to have to create a separate client connection to yourself so that you can receive and send information.

For a client, it starts out very similar. You're going to create a config reference. You're going to retrieve the string for that. In this case, you're going to want to replace the IP address and the port to match what the server expects. In the example code, there is a function for making this a lot easier. You pass it in the string identifier that you want to replace and the value you want to replace that reference's value with. So, again, you create a new protocol config, and then you open an endpoint to the server.

Sending messages with protocol API is a little bit different in that you have to do everything yourself. All you have is an endpoint to another computer. So if you're going to send information, you need to create the header yourself, and that header needs to have all the information you need in order to send and receive that message. The length of the message may be important, it may not.

The type of message should probably be in there unless you have some other way of identifying them. So you're going to... is a platform for you to use to create and manage your own NetSpot. You can use it to is a multi-task network of software and software development, and is a multi-task network of software and software development.

You are going to send out the packet with protocol send packet. And if you have a bunch of clients connected, instead of one call, you are going to have to go through your own loop. is sending out packets to each individual client. This means, of course, that you have to keep track of in your game how many clients are connected, what their endpoints are, and all that other information that NetSprocket handles for you.

Here's one of the things where the complexity issues come up. All your messages are received in a callback function that is called an interrupt time. The protocol API has an interrupt firing that is looking for incoming data on all the endpoints. And when it gets it, it's going to call your callback function for you to handle that data. is a software developer at the University of Michigan. He is the CEO of NetSprocket. is a multi-task network. The data is not going to be handled for you by the protocol APIs like it is in NetSprocket.

In the example program, there's a linked list that's used to handle the messages, and as they come in, they get added to the linked list, and in the main application, the linked list is transversed in order to retrieve the messages. You want to do as little as possible, of course, in your callback function.

So, there's a couple codes that the protocol API uses when talking to your callback function. It tells you why you're getting called and what information you're being sent, and all that's documented in the OpenPlay documentation as well as in the OpenPlay.h file.

is a very popular platform for networking. There is a function called protocol receive packet. That is how you get the information from your endpoint.

is a global network of software and software developers that are committed to the development, is a non-profit organization that is committed to helping developers to create and manage their own And then, of course, because you are in an interrupt, you really don't want to handle any messages in the callback function. You want to queue them up and let the main loop or a separate thread handle those for you so that you use as little time in the interrupt as possible.

So when you're finished, shutting down requires a little bit of work. You have to go through and close all your endpoints that have been created. The server is going to have to go through looping through all the connected clients and close each endpoint. It's opened up to every client. The clients are going to have to do a little bit less. They should only have one or two endpoints open to the host.

And then once you've actually told Protocol API to close those endpoints, you need to loop through a little message handling loop and wait for those endpoints to actually close down. Because you will probably get some termination packets and other information that you want to make sure you empty all of the endpoint buffers before you actually leave your app. and OpenPlay are cross-platform, open source networking APIs targeted at game developers. The OpenPlay API calling your callback function. That would end up in badness. is a global network of open source networking APIs that are used to support and manage open source networking.

So, protocol API in summary, it's more complex as compared to NetSprocket, a little bit less complex as compared to the raw, like OpenTransport or Sockets usage. You have to be really careful with your callback function. That is the thing that's going to really end up being

The example code is on the 2.1 release available on the website. It handles all of this stuff that I've mentioned, including memory interrupt safe routines, replacing information in the protocol config strings, reassembling the packet. It is not handled, however, because the demo uses only datagrams.

and OpenPlay are cross-platform, open source networking APIs targeted at game developers. has mentioned before there's a lot of products right now that are shipping that use OpenPlay or NetSprocket APIs. This is a partial list and there's more that are in development and we expect there to be quite a few more over the next year.

So, Now I'm going to give you a demonstration here. Alright, what we have running here is GameSmith. It uses NetSprocket to do all of its networking, and it makes good use of almost every part of the NetSprocket APIs. is a game-finding service. One of the very cool things it does is that it uses groups in NetSprocket to handle rooms. So when you move from room to room, What GameSmith does is it moves that player into another group, and that's how the user interface knows who's in what room, is by the NetSprocket groups.

So if you have a game that you want to have multiple people doing different things, groups are a great usage for that.

So, you'll notice I gave both of those a password and those were the passwords that were passed in from that dialog to NetSprocket. The game is really quite complex. It needed this one gigahertz machine and the powerful graphics card to handle all the 3D text.

Basically, question answers, you type an answer, type an answer,

will be a little bit more in depth on the topic. So, a little overview on different APIs and how they compare to OpenPlay and its APIs. We'll do a little bit on DirectPlay and OpenTransport and Sockets. will be presenting his presentation on the NetSprocket and OpenPlay. He will also be presenting his presentation on the NetSprocket and OpenPlay.

So, for direct play, some of the similarities would be that The DirectPlay API set compares most closely to the NetSprocket API set. They're both high-level APIs. They both handle things like games, players, groups, and all the basic requirements of passing messages for the game back and forth. and NetSprocket provide about the same type of message flexibility as far as sending in reliable and unreliable type packets. They both do the important job of handling message reassembly for you. So if you're looking at DirectPlay applications and you're wanting to use OpenPlay instead, then NetSprocket API would probably be the best fit for that.

will be talking about some of the pros to using OpenPlay as opposed to DirectPlay. Obviously, one, it's platform independent, so it will run on a lot of different platforms that DirectPlay will not. is also going to handle byte swapping issues for you where, of course, DirectPlay will not because it doesn't have to worry about that ever.

OpenPlay's NetSprocket API is easier to use. There's fewer calls that are needed to get it going and have your game actually up and running. It's also less vulnerable to system upgrades. If somebody installs a new version of DirectX, your DirectPlay app may or may not work depending on what they changed in DirectPlay. also provides low and high level APIs. So while the high level API may not provide everything you want, you can always go down directly to one of the lower level APIs to get that functionality.

And, of course, another big benefit is that the OpenPlay project is open source, meaning that you have full access to everything about the API. If you need to add features, you find a bug that you need to fix, it's all there and available for you. It's also a good point if you may need to port it to another system, like a console, or if there's a future OS system that you end up wanting to support, you'll be able to do that.

There are some cons, and we'll cover those a little bit briefly here. OpenPlay's user interface is not as robust as DirectPlay's. It's actually a very simple user interface, but since most games actually want to put up their own user interface, it's usually not a big deal. But if it is for you, that might be a consideration.

DirectPlay has a voice functionality where you can talk to a microphone and it will transmit that to the players in a game and give you chat over voice kind of functionality. OpenPlay does not provide this. There's nothing that is preventing it. It's mainly the voice compression codec that is missing.

So if that's an important thing to you, OpenPlay may not fit very well. There's a few things that DirectPlay has functionality-wise that OpenPlay doesn't. There's some statistical things like how much traffic am I sending, what's the ping time, a little bit of that kind of statistical gathering that OpenPlay does not. Of course, some enterprising developer can obviously add that to the code and submit it back to the community. . .

The OpenPlay community is going to be smaller than the DirectX community. There's not as many developers out there, so it may or may not be harder to find information. So far, all the requests to the OpenPlay list have been able to be answered, but that might be an issue for some developers.

So, if you're going to be porting a DirectPlay application, Again, I would suggest that you look at using the NetSprocket APIs. They're going to match up most closely to what the DirectPlay application is using, and I believe that that's pretty much what all of the Mac porting houses currently use, is the NetSprocket APIs.

If you have not done a NetSprocket game before, I would obviously look at the new NetSprocket example code so that you can come up to speed most quickly and get a better idea of how it fits into matching up with that direct play usage. is a very good idea to factor out the code. Initially, that's going to take a little bit more time, but once you have everything into one or two files, it's a lot easier to control the access and therefore port it.

is a multi-task platform that offers a wide range of support for all types of

Okay, we're going to do basically the same thing in comparing it to the OpenTransport and Sockets.

is a very popular network of network functions, so it's going to be pretty similar in using those. They both have the datagram and stream type connections. They all use the TCP/IP transport system.

is a developer of NetSprocket and OpenPlay. He is the founder of NetSprocket and OpenPlay. He is the founder of NetSprocket and OpenPlay. He is the founder of NetSprocket and OpenPlay. He is the founder of NetSprocket and OpenPlay. is a developer at OpenPlay. A lot of the details in OpenPlay are handled for you that you must handle yourself if you are using one of these lower level APIs directly.

and OpenPlay are cross-platform. And while, for instance, Sockets is cross-platform to a lot of different things, OpenPlay is cross-platform to a much higher degree. There's not little things about each platform that are different. It's the same on each one. And if you're thinking about, like, OpenTransport, of course, OpenTransport's not very cross-platform at all.

It also has, of course, its own set of unique features that should help you get your game up and going networking-wise quicker than if you were to use an open transport or sockets type low-level interface. is a member of the OpenPlay community. He is the CEO of NetSprocket. While this hasn't gotten completely functional on TCP/IP, we have got it working to a pretty good extent. And if you're playing on a local LAN, you don't have to have some special type of functionality that you have to write if you're using a lower level API.

is a multi-task network of software and software development tools that are used to Some of the cons. You're not going to have the full control of your networking access that you would have if you were using the lowest-level API. So if that's going to be critically important to you, that may be a reason that OpenPlay wouldn't work.

It's also going to add a small amount of overhead because it's doing some of the things that it does for you. This overhead has not proven to be a major deal in any of the games or any of the testing applications that we have seen, but obviously it does add some overhead to it.

So if you're in a really data-driven, critical application, that might be an issue. also might be overkill for some really simple usage. If you're just doing something really simple, you may not need all of OpenPlay's functionality. is also not fully optimized, which I would hope all of the low-level APIs are.

and OpenPlay are cross-platform, open source networking APIs targeted at game developers. This is a broad array of topics related to NetSprocket and OpenPlay on Mac OS X. NetSprocket and OpenPlay are cross-platform, open source networking APIs targeted at game developers. This is a broad array of topics related to NetSprocket and OpenPlay on Mac OS X.

So, porting hints. First thing again, look at the new example program so that you can get a good idea of how it fits to what you're porting. Factor out your networking code so that you only have one thing to touch and not a whole bunch of things scattered throughout the code. If you're looking for something that's as similar to the OpenTransport or Sockets usage as you can get, you want to be looking at the protocol APIs.

is a very popular networker. However, it may benefit you to rewrite the networking, especially if you can factor it out using the NetSprocket APIs because the NetSprocket APIs are going to be a lot easier to use and they are a little bit quicker to get implemented and running.

So, starting to wrap this thing up, one thing that everybody should keep in mind is that OpenPlay and NetSprocket have merged in the past. Like I said, they were separate projects. They're now one project. So, when you think of OpenPlay, it's both. The base idea of OpenPlay is to make networking easy, and of course we hope we've done that. If there's things you find that are missing from those APIs, be sure to let us know or contribute changes.

gives you a choice of high and low level APIs that you can work with. of course it's also cross-platform, which is one of the big things that we're trying to keep everybody informed of. Protocol independent, and you can also write new protocol modules if you find a need for one.

is an open source project and it has active members and an active mailing list.

And if you use the OpenPlay project in your code, be sure to let me know or somebody on the list know, because you never know when your name will appear on a slide at a show.

The technical documentation that is available. We have the NetSprocket 1.7 documentation. It's a little bit out of date. And if you look at testing.rtf, it will tell you pretty much where we stand in the terms of how our functionality matches up with the 1.7. And you should always refer to the OpenPlay.h file if you find something that doesn't compile from the documentation. I know that there's a few constants that have been renamed, for instance. But for the most part, the 1.7 documentation does still apply.

The OpenPlay API is a new document that was written recently by one of our contributors. It's a pretty good general description of using the protocol API. It's very well done. There is the older API reference for the protocol interface as well. And if you were looking at writing modules or using the module interface, there's the writing op-net modules. And all of those are in the documentation folder when you get the OpenPlay archive.

So, here's a bunch of sessions that somehow relate to this one. And if you had a time machine, you could go back and catch each and every one of them. If you do not have a time machine, the next best thing you can do is get the DVD set and all of these sessions in their full length are on there.

So there are a few sessions that are still happening today and tomorrow. Open, the advanced OpenGL sessions here. and the core networking session would also be a good one if you're interested in networking.

is the Darwin project manager. If you have questions that aren't code related but are more related to the Darwin project or the OpenPlay open source effort, you can direct those questions to him. If you send them to me, it's not a big deal. I'll forward them to him. I might even be able to answer them.

is the first developer to launch NetSprocket. For the most up-to-date information, you should go to the OpenPlay project page. This is the new URL that they've set up. This will have the latest release package on it. In fact, right now it does have the 2.1 release on it. It's 2.1 R1. There are two packages available there. There's the builds and the source code. And there's also the mailing list link and so forth.