[January 26, 12:25 AM:]

January 26, 12:25 AM:
Various things in progress. Did a little bit of procedural maze generation last night. The game won't actually be text; it was just easier for me to prove it out this way. I'm still unsure exactly what the mechanics will be. I like the idea of a one-on-one CTF variant, where each player has to play defense and offense at the same time, but I'm not sure how well that will work.

Trying to get reliable messages working in my networking code. Not sure I'll really be able to stress-test this, but whatever.

Doing some polish on my input binding menus to try to get that into a shippable format for this compo. Started working on it back in like August or September of 2008, so it's well overdue.

Quaternions are pretty awesome, though I'll admit I've never really been able to wrap my mind around how they work and why they do what they do. I just like 'em because they're more convenient and efficient than rotation matrices in many cases.

For whatever reason, though, the loopback address doesn't work; I have to use the actual internal IP of my machine (or use my external IP and enable port forwarding).

Oh, hurr, I get it now.

If I want to use the loopback address, the server has to bind the socket to that address, which precludes it from binding that same socket to another address.

I was just assuming that some magic would happen to match up the client's attempt to connect to the loopback address with the server's internal IP binding, but it seems that's not the case.

Nah, just arbitrary text data. I guess I was assuming Winsock would translate it into a UDP packet under the hood, but maybe that's not the case?

I don't get it. Maybe I'm doing something wrong? I can run two instances, use the same port number for both the server and the client, and get correct result. With UDP.

For whatever reason, though, the loopback address doesn't work; I have to use the actual internal IP of my machine (or use my external IP and enable port forwarding).

I can't tell how much of this discussion is genuine and how much is trolling, but you should only need one port to run two instances of an app on one machine and have them connect to each other. Assuming you're behind a router, the client should connect to IP 192.168.1.x (or similar) using whichever port the server specified.

@piratehearts

Game is too balanced. Nerf all the classes except mine.

An idea: allow a game to notify Twitter when a new game is hosted.  Then people can follow it and know when someone wants to play, to try to fix the usual emptiness of servers for indie multiplayer games.
I don't know if this idea is good or not because I haven't used Twitter.  Would people use something like this?

I like that idea. The other option would be to let the game access a player's own Twitter feed, but that could get spammy and annoying for followers who aren't interested in the game. Keeping all that spam on a single Twitter feed for the users who do care would be a lot cleaner.

It used to be fairly easy to access the Twitter API back when they allowed basic authentication. They switched over to OAuth last year, though, and it's somewhat more complicated now. Details here: http://dev.twitter.com/pages/basic_to_oauth

geez put the port in a ini file or somthin dont be lazy

Sure, but having a standard/default is nice for people who want to host because they don't need to open a different port for every game.

[January 18, 9:20 PM:]

January 18, 9:20 PM:
Started writing a thin wrapper around Winsock. It's threaded and non-blocking, so messages can be sent back and forth either direction at any time. I currently only have support for a one-server-one-client connection, but I may generalize it to support multiple clients soon. Still not sure what kind of game I want to make. Probably will let the tech drive the design, in the interest of getting something finished on time.

What Nix said. Package DirectX with your installer. See here for tips on getting the smallest installation package possible: http://msdn.microsoft.com/en-us/library/ee416805%28v=vs.85%29.aspx

If you don't want to use an installer, I guess you could go with OpenGL, but I wouldn't wish that on anyone.

Hey, someone's gotta make up for the OpenGL lovefest going on in this thread. =P

Yeah, the only problem with NAT hole-punching is that you need a server with a publicly accessible IP that both clients can connect to which will manage the connection between the two clients. And that makes homebrew solutions difficult.

How about Port 12222? It's easy to remember and it's unassigned by the IANA.

I know jack shit about port forwarding, so if you guys can guide me I could organise, i dunno, a poll to decide standard ports to use?

In general, ports 1024-49151 are considered safe for use. Wikipedia has a list of what ports many applications use so we can avoid obvious conflicts like instant messaging services.

http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

There's also a bigger, scarier, more official (?) list here:

http://www.iana.org/assignments/port-numbers

This thread looks to be very helpful.

I don't know much about developing networked games, but I do have a suggestion/concern.
Perhaps games requiring use of some ports to be standardized (all using the same port number) or configurable (can change the port number to what ever the player/host desires), that way players don't have to forward a different port for each game on their router.

Seconded. This would be nice.

Thirded. I'm planning to roll my own solution and let the host pick the port, but if we decide on a standard, I can default to that for simplicity.

[February 27, 1:36 PM:]

February 27, 1:36 PM:
Aaaaaaaaand done. Not my best game ever, but it pushed me to implement networking (not to mention NAT negotiation), so that's something.


Baffle_Install_2011-02-27_15-10.exe (2.0 MB, Windows only)

Supports online multiplayer only. No singleplayer or splitscreen support. Requires two PCs with an internet connection. I mean technically you can run two instances on one machine just to test it, but you really need two machines to play.

Goal is simple: Get to the other guy's spawn point. Whoever gets there first wins.

Mazes are randomly generated for infinite fun. Yep.

I apologize for the terrible music. After my last compo entry, I didn't want to ship a silent game, so I threw in what's probably the most cheesy, grating MIDI music I've written.

And just once more, to clear up any confusion: No port forwarding required!! I implemented a NAT solution! You're welcome! 

Ironic Papyrus is ironic.


February 26, 7:45 PM
Well, there's not much of a game here, but that's what I get for spending about four weeks on NAT negotiation and server browser code. You spawn into a maze and have get to your opponent's spawn point before they reach yours. There is only one path between these two points.

Things I did today:

• Maze generation
• BaffleMan art and animation
• Beacon art and animation
• Staggered blocks for more interesting visuals
• Victory conditions

February 24, 11:59 PM:
I think I'm finally done fixing bugs in NAT negotiation and server browser code. Just getting the basics implemented now. I have two players moving independently and a randomly-generated maze that gets rebuilt on the client side via a replicated random seed.




February 21, 10:45 AM:
Rudimentary server browser is in place. Still dealing with lots of edge cases in my net code that probably aren't as "edge" as I wish they were. Getting down to the wire here, don't think I'll have time to really make much of a game. Too bad, since I had some cool ideas for polish and presentation on this one. Building a robust generic system trumps making a single polished game in my book, though. And maybe I'll keep working on this one after the deadline if the promise is strong enough.




February 14, 9:45 AM:
Oh right, this thread exists. So yeah. I got frustrated with the idea of requiring players to set up port forwarding just to play my stupid little game, so I implemented a NAT solution, just like I said I wouldn't. Also added a reliability wrapper around UDP. These systems should be generic enough to support any future multiplayer games I ever decide to make, too, so I'm sort of viewing this game as a test drive. I'm running the server app at home on this little HP MediaSmart WHS box, so I'll just have to see how it holds up once I get a few games hosted at once. Fortunately, the server app doesn't really have to do all that much once the game begins; game hosts just ping it every now and then to tell it they're still active.


January 31, 11:30 AM:
Got some simple placeholder(?) cube art in place. Just placing tiles at random for now. Some simple networking exists; the server can move SphereDude around and the client will see it. Maze generation, collision, game rules, better interface for hosting and joining a game, and lots of visual flair are incoming.




January 26, 12:25 AM:
Various things in progress. Did a little bit of procedural maze generation last night. The game won't actually be text; it was just easier for me to prove it out this way. I'm still unsure exactly what the mechanics will be. I like the idea of a one-on-one CTF variant, where each player has to play defense and offense at the same time, but I'm not sure how well that will work.

Trying to get reliable messages working in my networking code. Not sure I'll really be able to stress-test this, but whatever.

Doing some polish on my input binding menus to try to get that into a shippable format for this compo. Started working on it back in like August or September of 2008, so it's well overdue.




January 24, 10:00 AM:
Slow progress is slow. I've identified a number of pitfalls in my networking implementation that I might have to design around. Thinking the gameplay might be sort of a one-on-one game of CTF. Not sure yet.


January 20, 9:45 AM:
I have an idea for a game, finally! It'll be all tile-based, with discrete one-tile-at-a-time movements (think Adventures of Lolo for NES) to minimize bandwidth use. There might be some block-pushing and puzzle-solving, but I'm thinking mostly it will be about hiding and sneaking around. Probably going to do some kind of line-of-sight or fog-of-war to keep the other player hidden. Might make the gameplay asymmetric, with one player attacking the other's base. Not sure yet. Kind of going to have to feel it out. Might throw together a mockup tonight.

Already finding that testing a networked game is going to be a pain and a half, but I didn't want to do hotseat, and I don't feel like refactoring my engine to support multiple inputs for simultaneous gameplay.


January 18, 9:20 PM:
Started writing a thin wrapper around Winsock. It's threaded and non-blocking, so messages can be sent back and forth either direction at any time. I currently only have support for a one-server-one-client connection, but I may generalize it to support multiple clients soon. Still not sure what kind of game I want to make. Probably will let the tech drive the design, in the interest of getting something finished on time.




January 17, 2:30 PM:
No idea what I'm going to make yet. Probably gonna roll a networking solution from scratch. Pretty much ruled out a homebrew NAT solution, so I hope you like forwarding ports.

Dead Space 2
ESV: Skyrim
BG&E HD
Portal 2
LA Noire
Deus Ex
MvC 3
Bulletstorm, maybe
DNF 

I brushed my teeth one time. I didn't care for it.

That Oddlabs paper is pretty sweet. I referenced it quite a bit when I was doing a procedural terrain project a few years back. Most erosion algorithms work by carrying soil down the steepest slopes, which helps to smooth out steep cliffs. The Oddlabs algorithm does the opposite; it preserves steep cliffs and instead smooths out the spaces in between. As discussed in the paper, their goal was to create interesting and functional gameplay spaces as opposed to simulating erosion as it appears in nature, but for my money, the end result looks pretty natural anyway.