从玩家转向世界的建造者
拉尔斯·彭舍（Lars Pensjö）玩过AberMUD和TinyMUD后，希望把两者的长处结合起来。他在瑞典哥德堡写出LPMud：多人通过网络进入同一个文字世界，彼此相遇，操纵物件，也改变其他人的游戏处境。为了让这个世界能够继续生长，他还设计了LPC，用程序定义其中对象的行为。
LDMud维护团队的项目史把这一开端放在1989年。理查德·巴特尔1990年12月的调查已经直接描述LPC如何在LPMud中工作。语言的形成和可见的早期使用因此相互衔接，而不是只有一个脱离用途的设计年份。
驱动程序与游戏内容分开
彭舍的早期手册存本（3.0.50版，含1991年编者注）把系统分成游戏驱动程序和mudlib。前者提供通信、解释运行等基础能力，后者保存构成游戏的LPC程序以及相关资料。房间怎样回应玩家、一个物件有哪些用途，都可以放在对象程序中；不同站点于是能够使用相近的运行基础，建立各自的内容。
这也改变了谁能扩展游戏。巴特尔观察到，玩家达到称为“巫师”的管理等级后，可以创建永久房间、物件、活动角色和命令。创作并非面向每个普通玩家完全开放，而是成为游戏内部的一种资格与职责。玩到高级阶段的人，也可能转而维护别人将要经历的世界。
一条穿衣命令如何找到对象
手册用皮夹克和板甲说明命令的组织方式。两件物品都可以声明处理wear这个动词；当玩家输入wear jacket，驱动程序会调用与该动词相连的对象函数。假如板甲先收到请求，它检查后发现目标是夹克，便返回0，让系统继续寻找其他处理者。
皮夹克的函数识别出自己，执行相应操作，再返回1，结束这次搜索。动作因而不必全部集中在一个巨大的命令表里。对象既保存自身的行为，也参与解释玩家说的话；同一个动词能够在不同物品上产生合适的回应。
参考：[1]
在运行中装入和复制
LPC的语法借鉴C，但彭舍没有让建造者直接使用普通C编写游戏内容。手册解释，他需要对象能够随时装入，也重视换机器时的可移植性，以及编程错误对整个游戏的影响。解释执行、继承等安排，服务于这一持续运行的多人环境。
定义对象的程序存放在文件中。引用一个尚未装入的对象时，系统会编译并装入它；clone_object则能从一份程序产生多个实例，再分别配置其行为。这样，若干相似物件可以共享定义，却不必永远保持完全相同的状态。对创作者而言，程序文件既是内容的来源，也是可反复使用的构件。
参考：[1]
分发带来的共同基础与分歧
巴特尔在1990年的报告中列出欧美多处LPMud站点，并记述1989年底美国开发者修改代码后，与欧洲来源逐渐分开。各站点的房间由当地创作者扩展，部分房间群又在站点之间复制，形成既共享材料、又各有区别的游戏世界。
所存早期手册给出了经查尔姆斯主机匿名FTP取得源码的办法，也区分驱动源码与需要另备的mudlib。分发一个运行器，并不等于交付所有游戏内容。1991年，约恩·伦内克接续驱动开发并形成3.2系列；LPC也随这样的维护与使用过程延续，其历史从一位玩家的构想进入多人协作的软件实践。