Yeah, I noticed the same thing!! This wouldnt be hard to fix. I'm going to put it up on the repo.
I finally downloaded a shell client, as soon as I figure out how to use it i'm gonna zot and slay some bugs, lol
posted in Bug Reports
Posts made by Syn
-
RE: Potion Names
-
RE: Potion NamesYeah, I noticed the same thing!! This wouldnt be hard to fix. I'm going to put it up on the repo. I finally downloaded a shell client, as soon as I figure out how to use it i'm gonna zot and slay some bugs, lolposted in Bug Reports
-
RE: Command Parserposted in Restricted Discussion
~~@Ardghal:~~ > I like this, but keep in mind that a lot of people are, well, lazy, and would want to have shortcuts. Could a system like this be shortcut? > > Also, I think that having shortcuts and shortform would be critical to gameplay, since things would be quite slowed down if everyone had to type everything out in long form. Proper, yes, but it would annoy a lot of people. Say I was typing that to attack Lukus. He would have ample time to get away in the time I'm typing that, most likely, and I'm a pretty decent typist. > > That's my only issue with it. Gamers as a general rule are lazy and want things to go at a reasonable pace to keep them entertained.
Right, the thing we're describing is mainly for newer people who may have never played a MUD before. There will definitely be an "advanced" mode you can toggle on in addition to what is described above, probably even more than one, to configure gameplay for efficiency instead of intuition. So people who are used to things like "get 2.sword bag" would still be able to use that. It will also undoubtedly come with aliases, and command stringing. -
RE: Command Parserposted in Restricted Discussion
~~@Areo:~~ > A few thoughts on the command parser, ideas about what it should be able to handle: > > It may be best to have the parser look for certain keywords, such as 'in', 'and', 'with', things like that.
Yup, that would be an excellent start :) As well as doing this there are throwaway words like "a" and "the" which are necesarry in english for flow but don't actually serve any purpose. I'll get a list of the important words started up in this post as soon as I write down a few more notes on English language syntax. Basicly it would be like the script parser, except with a ton of flexibility since requiring people to essentially learn a language, no matter how simple, is exactly the thing we're trying to aviod. -
RE: Staff Contact InfoSyn:posted in Internal Staff Discussion
anton@terrafuelresearch.com AIM: hustle2getcash MSN:antwizzle@hotmail.com Phone: If you need it, you'll ask for it -
NEWS on New Codebaseposted in Restricted Discussion
Dear Sentience Community:
The time has come for us to take a huge leap forward
in developing our game world and abandon everything
that has been holding us back. I'm talking, of course,
about the ROM codebase.
When I started Sentience 7 years ago, I had no idea
it would attract any players or staff, or even be
up a year after. We've had many ups and downs, but
have always maintained a small but loyal fan base.
Over the years, we as programmers have struggled to
fit our ideas into the ROM framework and have had
hopes of abandoning it. It wasn't until recently
that we have gathered a team of excellent programmers
who have made, among other things, the following
observations:
- It would be far easier to write our own codebase from
scratch than to try to adapt our ideas to ROM
- The ROM code agreement is legally stringent and demands
tribute through constantly spamming the game's players
with its creators' names and antiquated helpfiles
- Even ROM's designers have abandoned it as a viable
codebase (seehttp://www.rom.org )
Thus I hereby announce that we are, as of 02/01/2008,
developing our own codebase. It will be completely open
source, available to anyone who wishes to use it. A very
brief list of features we are developing are (summarized
from the MB):
* Classless, skill-based system with diverse trees of skills.
* Level-less. Players' strength will be determined by their
history and skills rather than some number corresponding
to how many NPCs you've slaughtered.
* Free-magic, wherein 'spells' are an arrangement of magical components,
strung together for the desired effect.
* Apprenticeship, players may teach their custom spells and skills to others.
* Crafting - everything from metalwork to glass blowing and sewing.
* Multiple combat styles, players will be able to set their own tendencies
for automatic combat which isn't just 'slash slash slash'.
* Reputation - you will not be known at first, but over time, your reputation
may grow and lead to being recognized by others. This extends to NPC's as well.
* Coordinate-based locations (vs. ROM's rooms) to allow for ranged combat, magic,
and actual flight.
* Player-run kingdoms, towns, and organizations, able to build out in the wilds
and form their own areas of control.
* Player-run armies, so that they may battle for territory and defend themselves
from the horrors of the wilderness.
* Massive wilderness, with multiple planes of reality (living/dream/death, as well
as Eden and the Abyss), with plenty of room for expansion.
* Chemistry, natural laws that control the world, invisible to players that do not
research it.
* NPC companions that can level with you, be hired on or join your adventurer on
a permanent basis.
* Quest system handled by staff, done in pieces which are strung together, allowing
for huge, large-scale quests as well as minor ones.
* Transportation - Ridden creatures and controllable vehicles will allow for
transportation through the vast wilderness.
* Interactive NPC's. NPC's will use the same skill system as players to decide how
they act. Additionally you will actually be able to talk to NPCs.
* Player creation - players may create their own homes/towns/etc, without needing
staff to do it.
* IRC style channel system, where players can make their own channels, as well as
vcommunicate on the public ones.
* More natural language parser, a normal and advanced mode which can prompt for
clarification on ambiguous commands.
I must clarify that we are NOT doing a player wipe or area wipe in developing
this new codebase. Doing so would be insulting to players and builders who
have hung with us through the years. The crappy areas (e.g. Reza) will be
ditched -- the good ones will be ported over so that we don't lose the Sentience
feel:) .
Throughout the years, Sentience has been graciously supported by its
administrators and hosts. Having our own codebase will allow us to take
player donations so we can buy better equipment and bandwidth. This
MUD was free when it was established and it will be kept that way --
I strictly forbid any solicitation for money, e.g. for reputation,
"donation items", or any sort of favor with the immortals. But
it's great to announce if you enjoy the game and want to throw
a few bucks our way, we can accept them without potential legal
recourse.
Above all else, my goal over the last 7 years is to, above all,
provide a fun game for people to play, which encompasses the classic
features of RPGs we all grew up with, as well as awesome things
that have never been tried in a MUD. I am not alone in this -
we've been lucky enough to attract professional coders (Nibelung,
Vizzini, Soupboy, and Jonastio) to join our cause.
I hope to hear from everyone in the community soon. The players
have done the greatest role in keeping this game going, and we want
to include you in our development. Stay tuned for further updates!
Syn, Administrator, Sentience MUD
syn@sentiencemud.net -
Order of Implementationposted in Restricted Discussion
This thread is for establishing an order of modules to be implemented, whether written from scratch or ported over from the old MUD. Here's what I have come up with so far, in order of necessity:
[*][b]Data structures/dynamic memory management[/b]
A header file comprising the most basic data structures we will need to establish gameplay. Seems like the most sensible place to start since in writing this we will plan out a lot of the codebase.[*][b]Sockets & game input/output loop[/b]
Handle incoming connections, allow other people than whoever started up the program to log in. A simple loop to accept and process input, and issue output. Includes prompt.[*][b]File I/O[/b]
Although a database may be preferable to many files written at once, this would have to be extensively debugged to ensure it's not easily corruptible. It's best to have file IO just in case.[*][b]Logging[/b]
Essential to establish early to keep the game as bug-free as possible.[*][b]Command interpeter.[/b]
Allow people to interact with the game world (send input).[*][b]Player account system[/b]
Can be very simple to start with, so that the game remembers who you are.[*][b]Coordinate system[/b]
[i]- Port: wilderness[/i]
Allows for a "tangible" world instead of floating around in limbo.[*][b]In-game communication[/b]
Things like channels and heads-up display for immortals (wiznet but less lame).[*][b]Online editing[/b]
[i]- Port: projects
- Port: staff
- Port: scripts
- Port: help editor[/i]
Necesarry to build our world from inside.[*][b]Event queue/scheduling[/b]
So that the game isn't based on the dreaded "tick" system.[*][b]Transportation[/b]
With coordinates, people will be have places to go, so they must be able to do it. This will start with very basic walking around and eventually will encompass flying, boats, etc.[*][b]Character stats[/b]
The ideal implementation of this will include both the classic-RPG features we all grew up with and love, as well as some interesting new shit to allow things to be done after you've "maxed" your character out.[*][b]Skill trees[/b]
Gives people something to work towards, instead of slaughtering NPCs for levels. This describes the skill-tree system itself, not any particular skills.[*][b]Combat[/b]
An essential part of any MUD (at least, for bloodthirsty folks like meself). This encompasses fighting styles, combat skills, PVP specifics, and anything else related to kicking ass.[*][b]Magic[/b]
A large part of any RPG. I hope to make this much more interesting than "X spell does Y and costs Z mana points".[*][b]Crafting[/b]
Allow people to do useful stuff without having to resort to violence. Includes: herbalism, metalwork, alchemy, and so on.[*][b]Game stats[/b]
A code module for keeping track of all sorts of things about the game. This will eat the current stats lists (Most quests, Most PKs, etc.) as well as adding many new ones - one I've always wanted to add was gold flux in/out of the game to keep track of money when it is "created" and "destroyed". Hopefully we can cut down on some of these by actually implementing a game economy - e.g. when you buy something from a shopkeeper, the money doesn't just magically vanish but goes into said shopkeeper's account.[*][b]Questing[/b]
A much, much better and more expanded quest generation system than what we have now (the same 3 tasks randomly repeated over and over). This will be semi-random to allow for variation in quests, but also structured so that you get a reasonable quest rather than "Obtain X, sacrifice X, kill Y".[*][b]Everything else[/b]
To be continued when I return home after 5:) Including but not limited to: items, movement, combat, magic, skill trees, chat, groups/organizations and a plethora of other stuff.
[list=1][/list]
Feel free to contribute and criticize, since I'm sure there's a heap of things I haven't considered yet. We can't start doin' stuff until we plan out what to do and who is coding what -- I'll moderate this thread and edit in changes into this original post. -
Dynamic Memory Managementposted in Restricted Discussion
Hi guys,
I wanted to start off this new forum with a thread dedicated to dynamic memory management. This is pretty much a brainstorming thread to address questions like:
* What kind of data structures do we need to establish an alpha release of our MUD? (e.g. account, descriptor, character, command, ...). A list would help us establish prototypes to get off the ground.
* What code would we need to write for most efficient memory management? In college C I learned to use free/malloc, sentience v1 uses the standard ROM recycling scheme which I'm really not sure is so good anymore.
* Is there a way we could do things which involve long linked lists (e.g. char_list in ROM) more efficiently?
I'll post in here some more tomorrow when I get back from work. Feel free to contribute:) -
RE: Feature listYou did a great job summarizing the features on here man. I cant help but notice you left my stuff out though ;) Not to derail this thread, but assuming nobody throws up a huge protest to the idea of restarting the codebase and porting over all the custom things we've done, maybe we should start a thread in here for discussion on that?posted in Discussion