We’ve made a number of improvements to our CastleClientServer unit and the associated examples in examples/network/tcp_connection. The CastleClientServer allows to use a “classic” TCP/IP server/client architecture to communicate in Castle Game Engine applications. It relies on Indy — FPC developers will need to download it.
The examples in examples in examples/network/tcp_connection show a simple client and server that can exchange messages, as strings, reliably. The server and client(s) may run on any system (desktop, mobile) as long as they are reachable over the network — e.g. make sure you have the firewall properly configured on the server device.
Improvements done:
- Big upgrade to the client/server samples in examples in examples/network/tcp_connection. UI is now designed using editor. Code is simpler and follows CGE conventions (all relevant code inside a view,
TViewMain). We added buttons to stop server/disconnect the client, to test this flow. We show current state, including IsConnected.
-
Fixed CastleClientServer to be able to send messages with international characters (beyond ASCII).
-
Fixed IsConnected value for both server and client on Android — it was broken, now it’s good. As a consequence, also fixed sending messages from Android clients.
-
Fixed clean client disconnection/destruction on desktops (Linux, Windows, actually anything non-Android).
We’ve also tested various scenarios, including
Note that our engine is not committed to any particular networking solution. We use URLs and we have TCastleDownload for HTTP(S) requests, but that’s it for “core” engine features. We leave it open how you can make multi-player games, we just show you various examples — using Indy client/server discussed above, using RNL (see our demo not-quake), and we plan Nakama integration. See the networking manual chapter for an overview.