Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Fayrik]

That's true, however, what if you have the initial keypress move you one square in that direction anyway?
Then to move two squares, it's just two keypresses.

[Sowelu]

That makes players estimate how many tiles away an important thing is, in the heat of action, which is tricky.  Though things like Nethack or ADOM or etc do support that kind of thing with a command like 'n 20 (something)'.

[Virex]

Yeah, repeat is a staple of roguelikes and an easy way to solve this. A MUD I once played (Accursed Lands) also had an option to keep following roads, which made traveling from one city to another easier.

[eerr]

-Needlessly complex for an aspiring game desinger

If it's not complex, where's the "FUN"?


There when you produce something people might actually want to look at?

It's more satisfying than you might think.

[Sowelu]

There when you produce something people might actually want to look at?

As long as you produce it, it's cool.  But all the awesome ideas and planning and work are meaningless to the rest of the world if you don't follow through.  Even a simple thing can be awesome, but only if it gets FINISHED.  Way, way, way too many indie coders fall into this trap.

[Virex]

-Needlessly complex for an aspiring game desinger

If it's not complex, where's the "FUN"?


There when you produce something people might actually want to look at?

It's more satisfying than you might think.

You shouldn't start out with an ungodly complex idea because that makes it very easy to lose sight of the basics. First get the basics down, then worry about adding the complexity when you've got something running.

[Muz]

Heh, I do have a complexity complex myself. I've been in that spot. This isn't that complex, but it's  I don't think this is a good idea though, just the game designer's instinct where it doesn't click.

First, the roguelike thing is not a good idea. Roguelikes being represented by characters are a limitation of technology. Graphics are normally better. It's purposely making it worse than it should be.

You haven't really gone into detail what factions are there. Most online games have factions in one form or another.

Also, ideas are cheap in the game industry. They're like.. iron.. or something. Everywhere. You have to form it into a proper design document before anyone can see whether or not it's viable. And while you're typing out the document, you'll see if it works. Game design documents don't work so well with action games, but great with strategy/RPG/simulation style games. If you still don't see it as a good enough idea to be bothered to write a proper documentation of it, then chances are that it's not a great idea.

You could probably make much of it in BYOND. Don't create more technology than you need to, you're going to start with a prototype.

[jplur]

Well, I think it's a great idea. 

I was, and might continue, working on an online Telnet roguelike: http://www.bay12forums.com/smf/index.php?topic=55591.msg1198538;topicseen#msg1198538

About button mashing: I put in a walk command, which would auto move you in the desired direction.  Maybe a 'follow' command to follow a friend or fleeing enemy would work well too.

[Fayrik]

Ech! I now begin my dark summoning ritual to arise this thread from it's grave!
(Yeah, sorry for the two month necro going on here, but I figured this would be better than starting a new topic and cluttering the forums up again.)

So, the last time I posted in this thread, I'd figured I had too much on my plate as it was, and this idea was way too vague for me to keep going.
I did however have a console with a little @ in it that would move around a predefined room. If I could just get ramps working on it then I'd have the base to a solid tile-based world here.

Anyhow, today, while playing Dwarf Fortress, I had another wave of this damned inspiration.
Several things have come to my attention here.
First of all, if I write a client program then it greatly reduces the amount of sent information required.
Secondly, I had an interesting idea for a server architecture.
Just for the moment, imagine this game is complete and running. There's a map, about the same size and style of a Fortress map in Dwarf Fortress. In this map is something like a village. All the members of this server have been playing together in this village, fortress, cave or whatever the heck the server's been doing.
But.. One person isn't content with this, and wanders to the edge of the map. Well, at the edge of the map the server has stopped generating land, so they inevitably run into that age ol' invisible wall. Except...
Here there's actually a smooth obsidian wall (or whatever really, this is just an example after all).
It's... Like a giant border.. And.. there's a gateway too!
They step out through the gate... And woosh! The map behind them unloads... And suddenly a new one loads out infront of them. Both sides of the wall completely oblivious to eachother, it's like the player just stepped through a portal to another dimension.
...Has the server just dropped or killed everyone who was playing? Not at all!
They're oblivious to what's just happened. It looks to them like one of their players has just logged out.
...And to their server, it looks the same way.
That's how the gameplay works.
Behind the scenes however...
It's not too complex. It's hardly what I'd call an efficient system, but it's quite interesting none the less.
Imagine if you would, player one logs onto his home server that his friend player two hosts. They're both playing happily, they're both logged into the same server.
So, player one then crosses that thresh-hold. At this point, the server that player two goes and contacts a master server, which looks at all the servers connected to it, finds the one that's the other side in that direction and sends the server information on it, which it relays to the disconnecting client, whom if all is a-okayed, then connects to the other server.
Player three's server, this new one that player one has just logged onto, can then double check with that master server to check player one is who he claims to be.

TL;DR version: Map edges would act as fortified gateways to other player's servers, allowing players from different servers to interact.

Okay, so you've managed to read this far. Well done!
And, by this point, you're probably wanting to ask "Why do you want to do this? It's crazy!"
Yeah, it's crazy. The great part is that actually posting this doesn't make me have to do it... But don't get me wrong. I'd love to do this.. And that's why I'm posting it.
I'd love to play this game, but it'd only work if other people want to play it too... And a few ideas and such would come in very handy.

A quick question for the programmers out there too:

Spoiler (click to show/hide)

How would you normally send binary information (in byte format) over the network then intentify what it is? It always confuses me when I try to send non-text information. How can I tell when something like a picture has finished sending, without having any form of EOF byte?

[jplur]

Interesting ideas.

Regarding the server shards, what would happen if a server is offline, would those segments of the world be inaccessible?

My suggestion, is to use a procedural world.  The server would only have to send the seed and the map section to the client, and both would have access to the same generated data set.

Then, you can store all non procedural information (like player terrain modification) as a seperate data layer, compressed to account for empty space. AFAIK this is how DF and Minecraft are structured.

About sending data through sockets, there are serialization libraries that can convert your data types to binary.  The resulting data is unpacked via the same library in the client.  This ensures that your data is as compact as possible.  Here a python library I use (included with PodSixNet, a great TCP networking library) http://code.google.com/p/podsixnet/source/browse/podsixnet/PodSixNet/rencode.py?r=145

For sending the map, you'll need to decide how many tile types you want.  I would just encode it as ascii but you have a lot of options.  Sending a png would be overkill but there might be some indexed color image formats that would work well.

[Fayrik]

Regarding the server shards, what would happen if a server is offline, would those segments of the world be inaccessible?

Server shards is a fantastic name for it. 
And yes, those segments of the world would be inaccessable, however, I think if we had some sort of fast travel thing, so that you can walk over offline servers, and onto other servers.

My suggestion, is to use a procedural world.  The server would only have to send the seed and the map section to the client, and both would have access to the same generated data set.

Well, I was planning on using a procedural world anyway, just so that worlds can be replicated. I also thinking of having a server control console that would let you modify the world manually.
However, things may work faster if the client is only sent visible map components.

Also, the reason I was asking about binary data transfer was so I could theoretically setup a segment of the connection to send data files, much like Dwarf Fortress's RAW files.
Though, I'm not entirely sure how much customization you can add before it starts to conflict, what with the idea of server-shards.