Networking Design Goals

After some good discussion with myndzi, we're closing in on a final specification for the NullpoMino protocol. I'm probably going to drop the dual-protocol idea I'd originally had purely because, as myndzi pointed out, it causes extra points of failure and this hybrid sort of protocol we developed should be able to take care of everything both of my old protocols would have.

The protocol is going to be a lot more generalized this time around, because we're going to have to support things that aren't the game (remember, the plugins are going to use the network communicator to connect to the server as well). We're looking at a protocol that is loosely designed around IRC's protocol, obviously expanded to allow for greater functionality since we're playing  puzzle games and not just chatting.

Some of the things we want out of this protocol are:

1. Decoupling of server and client based on version. Potentially, you can play over lower server versions. myndzi also had the idea of public key cryptography allowing us to update the server based on clients, but we're not sure if this is just wishful thinking.
2. Some sort of ascii/binary stuff. This is helpful because it allows us to transfer files without much of a hitch, but it also allows us to pack bits for the game protocol and save tons of bandwidth.
3. On a higher level, we want to have better rooms. A while back, myndzi came up with a great idea where we can have channels, where players are in as many as they want to be, and the channels have flags, one of which means that it is a game channel. Rooms will be able to have owners and can be permanent, invite-only, or a number of other things. People will be able to have clan channels, now.
4. We want the ability to either send data right away (live data) or wait until we don't have to worry about bandwidth in order to send something large, which could potentially block the socket (bulk data). Before, I'd thought about running a messaging protocol connection for the former and a transfer protocol connection for the latter, but now the server can treat them the same way. The network communicator also doesn't need to use two sockets if it doesn't want to, although it can.

There's more coming soon, which I'll be putting up as soon as we finalize the details.

Tripping Balls: A Network of NEUROs

Are you ready to harness the full power of the event system?

I know I said my next few posts would be about other things, but I lied. This idea came to me today and was altogether just too ridiculous to pass up. This is the maiden post of a series I'm going to call "Tripping Balls," which will basically be my speculations about the future of the game. This one fits that title pretty well, so follow closely.

Performance issues via NEURO (or lack thereof?)

Hey all, it's been a while. Sorry I haven't been able to post much lately, but I've gotten busy and design work is slow right now.

In any case, some people expressed concern that NEURO might have an impact on the performance of NullpoMino. I don't know if this is true yet, because we only have two real plugins written for it so far and they don't interact much. As it is, I'm writing NEURO Light as a sort of pre-emptive counter to this. However, there is something that I will be able to put to rest.

NEURO does not add input lag. Not even one millisecond.

I tested this just before, since I'd feared that it might do something like that due to the reflection-based nature of the system, and many people say reflection is slow. However, this turned out not to be the case. NEURO happily passes along the events, and things are just fine.

The next few posts I have lined up are going to be about the new rule system and possibly the networking protocol, although the latter is kind of in debate right now as I'm trying to decide which approach to take.

In-depth with NEURO

My last post went over the reason why NEURO exists and what it is used for. However, I didn't really get much into how it works or how to use the system. I know the Tetris community has a lot of programmers, so I might as well divulge a little information about how this platform (if it can even be called that) will be put to use.

As I stated before, the most basic unit of NEURO functionality is the plugin. A plugin is a piece of code which can interface with the NEURO system. It does this by registering itself with NEURO and subscribing to different types of events. Once subscribed, the plugin will be notified when that type of event is dispatched to NEURO. It's a basic event subscriber model, which is a nice design in this case, because the parts of the program which are dispatching events (plugins or otherwise) don't need to know about the existence of the plugins handling the events, if there even are any; in essence, we can use the plugins, but we don't have to.

Introducing NEURO

If you've been around IRC or the HardDrop shoutbox for any reasonable length of time, chances are you've heard me go on about something called NEURO. NEURO (NullpoMino End-User Relational Overlayer, which sounds more like a backronym than it is) is the event framework that connects all the different parts of NullpoMino 8. It will allow us to create plugins to expand the functionality of the game without any sort of foray into the code of the game itself.

How will this work? Well, as amusing as it sounds, the actual game of NullpoMino is a NEURO plugin itself.

On engine design

I'm not sure how many of you know this, but NullpoMino 8 was originally going to feature a millisecond-based engine.

Not the engine design I'm talking about.

There are many games right now which operate on millisecond-based engines. For example, Tetris Online Japan's internals work on milliseconds, as does Tetris Friends' engine. Guideline games in general are stated to work on milliseconds in their requirements.

Now, NullpoMino has been one of the games which runs on a frame-based engine. Many other fan games such as Texmaster and Blockbox work the same way. In the original design of NullpoMino 8, we were throwing around the idea of switching around the engine type in order to deal with some of the performance issues in older versions.

What does NullpoMino 8 look like right now?

Not very much, I'm afraid... Can you see the present I left, though?

State of the Nullpo: Volume I

I know some of you might be wondering what this is all about.

NullpoMino 7.5 is a pretty good piece of software on the outside, I think. It might be a little hard to use, but it's fairly functional and packs in just about every feature that anyone would want. We have a really robust engine that can accomodate just about any game of Tetris your mind craves for. So what's the point of all this? What's the point of taking NullpoMino from scratch to a full game once again if we're not going to get much out of it? Aren't there enough features already?

Welcome!

Hello there! Zircean here, and welcome to the NullpoMino Development Blog. This is where I'll document the progress of NullpoMino 8, the long-awaited revision of the most versatile puzzle game ever created. Because we're doing a complete internal revision, this is a rather large task to take on - so here you can check up on us and see that we're doing what we can to get NM8 out in a timely fashion.

It will also help if we can get some feedback on what we're doing so we can explain things that are confusing or design with more feature requests in mind. The more we can do with this game, the better it will fit its purpose, so let us hear everything!