Messages

1

Programming / Re: Unnamed: the Roguelike.

« on: April 12, 2010, 05:27:44 PM »

I do need to call it something. I just don't know what. Since the world is not exceptionally fleshed out, there's not much of a story yet, nor a real name for the game. I don't even have a macguffin!

So, Unnamed is not the actual name. It is a temporary name. Maybe by the time I actually have a release I can refer to it by another title...

2

Programming / Re: Unnamed: the Roguelike.

« on: April 11, 2010, 03:52:41 PM »

Current status:
   Several meta-systems are in place: game saving, map traversal, stairways, and caves. These are preset structures that complement the rooms-and-passages structure inherent to the roguelike; they are large, semi-random, and have a Z-dimension. That is, if you look down into a cave or sinkhole you can see the layers of the map below you; if you're strong enough you can kick a monster off a ledge, doing damage to it or even killing it; if you so desire, you can descend into the cave yourself. Even room structures can potentially be multilevel affairs, allowing for rather epic setpieces. There is a map in the interface now, that is filled out as you explore; in addition, various features like level-determined lights are in play. The camera has been moved to a fixed, farther-out perspective in order to aid in actual play, not just pretty views.

I'll probably consider the first milestone releasable when there are some ambient critters to fight, and when the overmap is more fleshed out. That may take a little while, but I feel that I'm starting to get beyond the bare engine skeleton and into the meat of this project.

3

Programming / Re: Unnamed: the Roguelike.

« on: September 08, 2009, 04:25:20 PM »

A couple of changes/updates:
1. Fixed another  bug with multi-Get.
2. Added Wear and Wield commands. Wear is a more general 'equip' command, in that it will also 'wield' weapons; but Wield is there in case you want to Wield a helmet or something random like that.
3. Added special rooms. These are rare dungeon rooms which have unusual shapes or features; they may be pillared halls, trap-laden mazes, water-filled corridors, or vast treasure vaults. These rooms are chosen from a set of pre-designed layouts.
4. Added first (basic) NPC: the Rabbit. He is currently running a random-walk AI, and checking for wall collisions. In subsequent updates, I will give him the ability to detect and run away from the player, as well as using him as a target for implementing the 'T'hrow command and attacking. Then I can begin to add more advanced enemies, giving the player something to kill.

4

Programming / Re: Unnamed: the Roguelike.

« on: August 17, 2009, 11:40:25 PM »

Small update.
Added food + water, Eat command. Added Raw Meat object, Bone object. Fixed serious bug with Getting multiple items.

Update 2.
Battle-tested the Use command. It's halfway there, as it doesn't quite handle inheritance yet. Also, added Carving Knife, Sharp Object, Corpse, and the Use Sharp Object with Corpse command.
Finally, I added Spawn Rarity as a stat in the objects definition file.

Update 3.
Use command complete and tested. Using your Carving Knife with a Corpse will result in three pieces of Raw Meat and two Bones. The sum of food obtainable this way is greater than that obtained by simply eating the Corpse; also, you will be able cook the Raw Meat over a fire to increase its food value yet farther (I might even implement a cooking system whereby spices and other ingredients may be combined to create special dishes of great culinary benefit.)

My inheritance/parenting system is an attempt to save speed at the expense of memory use. You can define interactions for low-level parents (say, define Use|Sharp Object|Corpse to show a message "A maggot appears! It squeaks, 'Hello, world!'"), which is then added to a list of interaction code. The game will, when it starts, compile a list of interactions and work out parenting beforehand; each and every object that inherits from Sharp Object (or corpse, for that matter) will have a pointer to the interaction code for that "use" event, unless overridden. This is a relatively minor memory draw (4 bytes per interaction per item, or per item pair in the case of the Use event), and can be optimized to not even take up extra time at loading, by saving a list of pointers to a file and recompiling it every time the object or interaction lists change.

Update 4:
Modified levelup code to give luck some play in increased health and mana pool. Dexterity is still out in the cold, though. No raw stat increase there - it plays more into the behind-the-scenes mechanics.
Also, I linked carrying weight to various stats. Strength, obviously, plays a big role; dexterity comes second, and constitution has a small part to play. Finally, I made the player's actual health and mana show up alongside the percent bars.

Randomly generated characters tend to have stats which start in the D&D 'normal' range: 8 to 18. My generator also tends to dip a bit lower than the D&D default - stats which aren't focused on at all may dip as low as 3 or 4. Thus overall the stat points a character in Unnamed will receive are less than those in D&D. This is made up for, I believe, by the fact that a character gains one stat point per level, for each profession possible.

I think I'm going to have job level gaining difficulty be based on an average of 1. the character's level in a particular job (for instance, a level 1 Assassin would need only about 20 experience points to gain his next level), and 2. the character's total level (a character with 20 accumulated levels might have to gain 4000 or more experience points to gain his next level.)

Thus, level gaining will still be easier in untrained skills, but you won't be able to just gain random levels in odd professions to buff your stats. Doing so will be slower than otherwise, and will make your character gain future levels in jobs you actually care about at a slower rate.

5

Programming / Re: Unnamed: the Roguelike.

« on: August 15, 2009, 10:06:01 PM »

...Anyway.

Added support for group pickup. This means that, when "G"etting from a Pile, you can choose whatever items therefrom you want to get. Also, you can choose the number of said items.

6

Programming / Re: Unnamed: the Roguelike.

« on: August 15, 2009, 05:36:30 AM »

'Auntie' is far, FAR too liberal for my tastes.
And Cactus' games don't necessarily demonstrate the power possible with Game Maker. Most people make simple 2d platform games or horrid looking '3d' games. I like to work at the graphical high end.
http://img31.imageshack.us/img31/204/faroffland.jpg

7

Programming / Re: Unnamed: the Roguelike.

« on: August 15, 2009, 04:40:26 AM »

Aye. Good eye.

It's not quite as useless as one might think.

8

Programming / Re: Unnamed: the Roguelike.

« on: August 15, 2009, 02:26:21 AM »

Progress update:
* Added item handling
* Created graphical item editor
* Added handling of interactions
* Added activation methods for Move, Get, and Drop commands.
* Added inventory
* Added Gold Piece, Pebble, and Flint as items.
* Added basic handling of item stacks.
* Added basic character configuration screen, as well as the code for handling stat increases on level gain.
* Added base framework for level and game saving/loading. Levels are saved as a single 'random seed' variable which tells the engine how to rebuild the level; in addition, the format keeps track of changes made to the level (items added/removed; tunnels dug) and monsters present. This should keep level data rather compact.
* Added rudiments of interface. As you can see, I've removed Intelligence from the stat list (in function, it was a duplicate of wisdom), and added Luck - a primary attribute of rogues.



The following code defines a pebble:
4|pebble|0|1|2|char_pperiod.u3d|gray|0|0|1|0|0|0|0|0|0|1|0|0|0|0|0|0|0|20|

...and the following allows it to be picked up.
Get|Carryable|None|
BEGIN
with modelChar addToInv(global.locx,global.locy);
refreshPoint(global.locx,global.locy);
END

9

Programming / Re: Unnamed: the Roguelike.

« on: August 11, 2009, 05:09:02 AM »

Subject post: Character generation.
I'm trying to handle character generation a bit differently than normal. For one thing, at the moment gender and race are handled automatically - that is, when you make a new character your race and gender are decided for you. This works in accordance with one of the 'meta' feature concepts I have planned - inheritance. Your character grows in accordance with choices you make throughout his or her first twenty years of life, divided up into a 5-stage branching choice tree. You can start as a skilled magician, a craftsman, a warrior, a ranger, a priest, a monk, or someone with a family. This choice tree also determines your starting equipment.

Inheritance:
 Basically, you have a place in the world's history. You can marry and have a family, and - here's the big thing - when you die, you can choose to continue play as your spouse, one of your siblings, or one of your children. Children's stats are decided as randomized between the parents' low and high end stats - that is, if the mother has a STR of 12 and the father has a STR of 18, the child may have an STR of anywhere from 12 to 18. How well the child starts the game will also depend on your progress in the previous game - if you gather 10000 gold and return alive to your family of 4, each child will start with 1250 bonus GP. (the keyword, of course, being 'return alive.') A character with no progeny will deadend that lineage, and you'll have to start an entire new family. This aspect of gameplay should also increase the usefulness of Charisma dramatically.

Races:
I'm currently working with a starting set of four races. Humans are sort of the middle ground - able to do anything well. Fae are magically inclined, reasonably charming and graceful, but not particularly strong physically. Dwarrow are physically strong, but not very pretty or dextrous. Synd are lithe and charismatic, but aren't the smartest knives in the drawer.

Magic:
All physical objects have essences. This is a scientific representation of their very being, and can be manipulated by the skilled. A piece of flint, for instance, may have 1 Earth Essence and 1 Fire Essence.

Essences are as follows: Earth, Air, Fire, Water, Light, Darkness. Most objects have between 1 and 3 points of essence, and pure objects are rare and valuable.

All living beings can draw upon and store essence to some extent, as determined by their skill and Wisdom. They can convert an object to its essential elements, then store that essence for use in spellcasting.

If a being has too much essence within them, it will become unstable and prone to accidents. This is one reason why most mages start out with fragile constitutions. The same goes for spells cast beyond a user's ability.

A being's ability to store essence increases with use. Even the least apt of users may eventually learn to use magic. However, it is impossible to store more than ten essence points (the cost of the highest-level spells), so choosing which spells to be able to cast is an important part of being a wizard.

Spells are cast by drawing upon one's essence pool and transforming it to a particular purpose. They are fuelled by one's mana or, at last resort, by the essence pool itself. The cost of a spell in mana is equal to the square of the spell's cost in essence. A 5-essence Moderate Fire Ward spell would cost 25 mana to cast.

Gemstones have negative essence. This means that they can store within themselves foreign essence, and put it to use, in similar manner to how living beings can. Gems inserted into wands, rings, weapons, amulets, and armor can imbue those items with magical attributes. Special inks may be assembled, containing similar properties, and may be used for the writing of single-use scrolls.

Death is a tenth-level spell, consisting of 10 darkness essence. Very few mages have 100u of mana at their disposal, making Death a costly spell to use.

A wand of death would require a 2-socket wand implanted with two extremely valuable -5 essence Nightstones. as well as 10 points of pure Darkness essence gathered from pure-Dark objects. This makes for a very difficult crafting process. Plus, the mana pool in a wand is limited to 100u per stone (although you can force a third shot by eliminating all darkness essence from the wand) and recharges have a chance of shattering one of the stones.

Rings can only hold one stone. This limits their spell set substantially.
Amulets can also only hold one stone.
Weapons can hold up to two stones, with similar restrictions to wands.
Armor can hold up to one stone.

If a given weapon, wand, or ring can cast more than one spell, it will choose between them randomly unless blessed, in which case it will ask which one to fire.

10

Programming / Re: Unnamed: the Roguelike.

« on: August 09, 2009, 04:37:05 AM »

'U'se is to use one item with another. For instance, 'U'se Sharp Object with Corpse == 2 meat, 3 bones.


Alternately, 'U'sing an object with nothing will perform the default command for with-self use. With food, this is to eat it. With a potion, this is to drink it.

On second thought, I think that 'A'pplying objects was supposed to be for using them with external objects. 'A'pply Key to Door, for instance.

There would also be a set of more specialized commands available - 'T'hrow to throw objects, 'D'rop to drop them, 'w'ear to put on armor and weapons (although there would be a special 'W'ield command, allowing you to wield anything you wanted)

11

Programming / Unnamed: the Roguelike.

« on: August 09, 2009, 01:28:56 AM »

The above is a realtime game engine render. It can handle shadows, 3d character models, etc. It allows zooming out, and I intend to add a 'pseudo-2d' map display, similar to classic ASCII, at extreme zoom levels.

I plan to couple it to an existing game design of mine, based around the concept of game objects with inheritance. (In other words, behaviors can be defined for entire classes of objects with very little effort. A wooden weapon may be made to burn when it hits a fire golem without any special coding.)

Other feature concepts include:
* A persistent overworld.

* A monster list drawn from the mythos of a particular cultural region - say, Europe. This would include more esoteric mythical beasts, such as the Kelpie.

* A 'scientific' magic system. Spells require 'essence,' which is contained in all things and which can be extracted by those skilled in the subject, then stored or released as needed.

* A 'job level' system - you gain levels by participation in various jobs (ranging from monster hunting to woodcutting), which add points to your essential stats according to what that job would require. A woodcutting mage would not be very good at it at first, but would get stronger.

* A world which 'makes sense.' Interactions should be designed so that they mirror the expected as closely as possible - if you cast fireball and it hits a door, the door burns.

* A thinning out of the typical Roguelike command list. For instance, 'I'nteract would allow you to take typical actions with external objects - opening and closing doors, for instance, or ascending and descending stairs. 'U'sing an object would allow both item combinations and the use of the object on external sources, while 'A'pply would attempt to use an object with itself. Hence I hope to make the game world more accessible.

I might attempt to make gameplay 3d as well, but only in the future.

Credentials:
I've worked on this concept before, albeit without the snazzy engine. I got many of the basics working - combat, level generation, monsters, items (with inheritance), identification, persistence, magic - so I'm confident I can duplicate my success here.


Thoughts? Ideas? Skepticism?