Grimrock

Brief update:

I got a bit distracted with DayZ alpha, however I am still working on this. I am still in the process of assaigning proper hard edges to all objects. That is what I consider phase 2. Once that is done I'll update this thread with another .dat

What follows is my explaination of how I intend to implement computers into the Grimrock Engine from a logic, not scripting perspective. Note that the described features are not actual "computers", just a series of simple switches.

TREATISE ON THE THEORY OF COMPUTER TERMINALS IN GRIMROCK

The basic idea is that you have a wall decoration class object that houses the "screen" of the computer. This .model is a replacewall decoration only. It has a texture on the screen that serves only to distinguish "if you see this the script is broken".

The screen itself is a single face cube in the same size as the screen, set a little bit forward of the first screen. This .model is then duplicated and textured in as many textures as you have need of different screens to display. It is summoned and delted in accordance to scripts. It is placed along the wall so as to naturally have the correct positioning. Adding a lightsource to accompany it is optional.

On map start, a screen is created. When a trigger is activated, one screen is deleted and another created in its place. The mesh between screens is identical, just the assigned texture is different.

To make it user interactive, there are two types of modifiers readily available: buttons and alcoves.

Buttons are simply empty .models that display nothing, and are assaigned as secret buttons. Activating them triggers the creation/replacement of whatever screens you need. Alternatively they could be actual buttons too, but scriptwise thats identical.

Alcoves are "disk drives" in that they are alcoves that only accept certain item types. Namely disks. The presence or absence of a particular item in the alcove creates/replaces whatever screen is desired.

Combine this with buttons and you can basically do all the computer functions you may need from a gameplay perspective.

You might want to consider using the onGui 2D rendering hooks if you want to make a more realistic computer terminal experience. I've got some plans for a sci-fi mod, and have thought a bit about how this could work. Essentially - your 3D model could just have a login screen as the static texture. When you walk up to the computer and click on it, it brings up a full-screen 2D graphic of the screen.

As the onGui hooks let you print images and text and register button presses (and even key presses) you could simulate a login experience quite nicely and even a basic "Movie OS". You know, the sort of thing where there are 3 buttons at the top and each leads to a separate sub-screen "MESSAGES" // "WORK LOG" // "DOOR CONTROLS" or something like that.

Phase 2 of the shuttle is complete. It just remains un-implemented because its a bother to type up object.lua definitions to actually test it. I know it works, however, and the .models are all okay. Instead I'm doing a phase1/2 of a system of modular scifi catwalks, both with hanging cabling suspension, stilts as supports comming from ground, and hanging off of moving machinery. I don't actually like the idea of cable suspension or stilts as elevation, but I thought I would model those options anyway because (1) it isn't hard, and (2) having catwalks just sort of levitating in the air supported by nothing might be weird (although that option is available if the dungeon maker doesn't feel it looks weird)

here is a quick image but thats not really what this post is about. This is:

RECORD EXCERPT
--------------------------------------------------------------------------------------
11378M02D19/197482.06.27 - 423J96V/2.7, GR78194/0.8, 9P37Z15/4.2
--------------------------------------------------------------------------------------

TELECRYSTAL BEAM ALIGNMENT - NOMINAL
DECRYPTION CARD - CODE - 387859790817328573176516273 - NOMINAL
SIGNAL CHECK - RECEIVED - SENT
TRANSMISSION - YES - DECODED
TEXT - BEGIN

__________________________________________________________________________________________________________
Ghedine Republican Strategic Control Center, Ghedine Proxima III - resent via - Polar Stationary Satellite, Ghedine Proxima V

To

Vessel Transmitting FFPDID # 4578 - 1086 - 1984, AKA Object 31984227
__________________________________________________________________________________________________________

Attention Vessel:

Your doffing from hyperspace was identified thirty-seven minutes ago. This message will reach you approximately fourteen hours from its transmission. If you receive this message in time, do not don to hyperspace to continue course. Receive course trajectory alteration as follows.

Object 31984017 at 423J96V/2.6, GR78194/0.9, 9P37Z15/4.2 at time of transmission, travelling torward point 423J96V/2.7, GR78194/0.6, 9P37Z15/4.2 at velocity 0.000000078, at a rate of 0.00027^-4, is an object of interest to us. This object will traverse within 0.5 of your location. Given your approximate position at the time of this message's arrival, you are the only vessel in position to possibly intercept Object 31984017 before it either dons to hyperspace again or passes through the system at a speed and trajectory that make intercepting it impractical and unfeasible by any local asset. Your arrival is fortuitous.

Object 31984017 was identified doffing from hyperspace two weeks, three days, and seven hours ago. Since then it has been on a constant trajectory. It is a second era, fifth generation refit colonial battleship, probably Ygdrammar class of Amakhi Colony design. It broadcasts ancient identification ciphers that we believe identify it as the Gloriana Vi Tempesta, known to the Annals of the Colonial Period as The Doom of Worlds.

As you may know, according to the annals, The Doom of Worlds failed to arrive at its rendezvous point with the Amakhi fleet before the Battle of Taflar, some One Hundred and Forty-Six Thousand Years ago. It was seen donning into hyperspace along with its escort fleet and was presumed lost in transit. Its presence here now, and yours, is nothing short of serendipitous. Surely you know of that ship's history, and understand the importance of its potential recovery and salvage for all of humanity.

Since matching her speed is impossible, you will need to hit a tow line attachment as it passes by the intersection point we are transmitting to you. Whoever you are, you will be rewarded beyond your capacity if you can slow her acceleration down enough to alter her trajectory into a stable orbit around this star. We have sent several possible trajectories based on calculated scenarios for achieving this. We believe that based on her course she must be derelict. If you are successful, please accept the bounty and turn her over to our authority. You may keep anything you find there and can carry in your ship's cargo hold.

We place our faith and hopes in you, traveler.
__________________________________________________________________________________________________________
RECORD EXCERPT END


yes, that's right, the purpose of this post, and likely most subsequent ones, will be devoted to bits and pieces of my (awful) fiction back-story for the Dungeon I want to create with these assets I'm drawing up.

In unrelated news I finished a work of pixel art. The rest of my catalog is here: http://arkkay.newgrounds.com/art/
Still working on stuff here and there, hoping to have everything done to push out a .dat for review by the end of the week. hopefully. HOPEFULLY.

edit: Also this one is more relevant to LoG

Those looks very cool, I sorta want to play those games!

I'm seriously considering doing a Toorum's Quest 2 -like mod based on "Cyber City Escape", the bottom picture.

Its not too tough to do from a programming standpoint. Due to the way the hallway is drawn, I just need to make an image of every single possible viewpoint that the player can possibly see (realistically only a few hundred, and even in case of astounding complexity in variations, less than a few thousand; and in any case most of those would be derivative) then make a database of those images. Then I just summon an image that corresponds to an invisible mini-map grid of what the player SHOULD be seeing based on his previous movements since the start of the dungeon (Which I THINK is actually how the original DM is coded). That creates the illusion of a 3D dungeon.

Something to think about. Last night I actually did a large number of variations. Not ALL of them, but a large number. I also need to finish animating the HUD and creating graphics for an inventory system.

The idea is a DM-like game with a sci-fi twist that would simulate the hardware specifications of the original gameboy (screen size, color constraints, BUT NOT THE SPRITE NUMBER LIMITATIONS). If it worked I could in theory make it work from an item (a gameboy) WITHIN the dungeon. Woah what an idea.

I also threw it up into 4-color greyscale so I could make the option of recoloring it later or up to the player.

here are some quick images:

Oh man, you should definitely do this if you have the time, it's an impressive concept already

I am very sorry, but I have to put this thread temporarily on hold. Work related. Will not abandon for 12 months, but might be a rough march/april. Good for me though. moving up in life. Bad for free time modding.

Hello,

have you done something new? can your actual work be used in a mod?