Hired Guns: Your memories (plus some fun fan-created stuff!)

[Cherno]

Hello,

I decided to upload the most recent version of my HG2 editor. I was not able to correct the save/load problems, so some objects like elevators and switches will probably lose their trigger targets when a map is loaded.

The save game system itself is far from user friendly. Basically, You can spcify a name for your map, and then this map can have multiple save games of your progress. However, I suggest keeping the number of saved games for a map at not more than five, so use the delete save game function regularly.

Press F1 for keyboard commands and Escape for save/load menu. Other than that, just derp around and click on various buttons, including the mouse, to see what happens

https://www.dropbox.com/s/yoes6tvdtd...2_004.zip?dl=0

[Cherno]

I also uploaded a web player version without save/load capability:
http://cherno.lima-city.de/hg2/build004/Build_004_web.html

[Predseda]

I am looking forward to try it.

[Cherno]

I finally started learning how to save and load scenes without resorting to third-party plugins and it's goign well so far. More to come

[Lord Aga]

Heh, nice Keep pushing !

Originally Posted by Cherno

Up to four items can now be in one space, the game creates an invisible item pile object that has four slots for items. It is created when a space onto which an item is dropped doesn't already have one, and destroyed if all items from one space are picked up.

I've also been working on a Hired Guns -like engine, and from the beginning, wanted to avoid the single feature I hated the most in the otherwise brilliant original: Ability to drop only one item in any block. As such not critical, but combined with the HUGE amount of "trash" items found in the game, it soon became annoying having dedicated "trash areas" where players should go to get rid of unwanted items (which you don't often know, before picking the item up)

Of course there's one exception: Whenever player character dies, all inventory is pickable (one item at a time) there, so they probably had some different "item pile" object for that one special case.

Sure, 4 items per block isn't as bad as the original, but why have a restrictions at all?

For me, the perfect solution turned out to be linked lists. Basically something like this:

struct ItemData
{
struct ItemData *prev;
struct ItemData *next;
ItemType type;
// Whatever else you need
};

and then for each block, have a linked list element, which basically just points to the first item (if any). That way there's no much memory overhead either (as each block needs to have one pointer if it has items), so no much point freeing / allocating it as the game runs.

So for handling items, something like:
Item *item=block->firstitem;
while(item)
{
HandleItem(item);
item=item->next;
}

What about the inventory then? Another linked list.

Pick up item:
pickeditem->previous->next=pickeditem->next;
pickeditem->next=inventory->first;
inventory->first=pickeditem;
(adds at the top of inventory list)

How about equipped item then? (assuming there's only max. 1):
Simply have a pointer to currently equipped (or NULL for none). When equiping item, remove it from inventory / block linked list, and assign to slot. When putting back to inventory, append to inventory linked list.

And of course, it makes perfect sense to have some nice dedicated linked list functions to make it all more clean (or use some ready implementation)

Of course if you want to reduce the memory footprint, you can remove "prev" pointer, and manage with only "next". Linked lists can also have ->last, of course.

Yes, this was reply to a rather old post, so no idea if this was solved already. Personally I just found this approach so ideal to this issue, I just had to share it.

So in a nutshell, advantages, as I see it:
-No need to have "I guess this is large enough" maximum amount of items per block, that also increases memory usage. Of course you still CAN introduce such artificial restrictions, if you want.
-Minimal per-block overhead (min. 1 pointer)
-Manageable per-object overhead (min. 1 pointer, 2 if linked in both directions)
-It's faster to remove item from the middle of a list (in case you would need to move other items in an array to get rid of empty slots)


And of course some (minor) "bad stuff"(tm):
-It's slower to get n'th item of a list (compared to direct array access)
-Great care should be taken when managing all the lists items can belong to (it's too easy to end up with same item in several lists)

As for Unity3D / C#, don't really have any experience with either.

I guess this ended up rather technical for an average forum user, but hopefully someone finds this useful

Just makes me wonder, why they didn't do it like that in the original to begin with?

[Cherno]

Originally Posted by Jupp3

I've also been working on a Hired Guns -like engine, and from the beginning, wanted to avoid the single feature I hated the most in the otherwise brilliant original: Ability to drop only one item in any block. As such not critical, but combined with the HUGE amount of "trash" items found in the game, it soon became annoying having dedicated "trash areas" where players should go to get rid of unwanted items (which you don't often know, before picking the item up)

Of course there's one exception: Whenever player character dies, all inventory is pickable (one item at a time) there, so they probably had some different "item pile" object for that one special case.

Sure, 4 items per block isn't as bad as the original, but why have a restrictions at all?

For me, the perfect solution turned out to be linked lists. Basically something like this:

struct ItemData
{
struct ItemData *prev;
struct ItemData *next;
ItemType type;
// Whatever else you need
};

and then for each block, have a linked list element, which basically just points to the first item (if any). That way there's no much memory overhead either (as each block needs to have one pointer if it has items), so no much point freeing / allocating it as the game runs.

So for handling items, something like:
Item *item=block->firstitem;
while(item)
{
HandleItem(item);
item=item->next;
}

What about the inventory then? Another linked list.

Pick up item:
pickeditem->previous->next=pickeditem->next;
pickeditem->next=inventory->first;
inventory->first=pickeditem;
(adds at the top of inventory list)

How about equipped item then? (assuming there's only max. 1):
Simply have a pointer to currently equipped (or NULL for none). When equiping item, remove it from inventory / block linked list, and assign to slot. When putting back to inventory, append to inventory linked list.

And of course, it makes perfect sense to have some nice dedicated linked list functions to make it all more clean (or use some ready implementation)

Of course if you want to reduce the memory footprint, you can remove "prev" pointer, and manage with only "next". Linked lists can also have ->last, of course.

Yes, this was reply to a rather old post, so no idea if this was solved already. Personally I just found this approach so ideal to this issue, I just had to share it.

So in a nutshell, advantages, as I see it:
-No need to have "I guess this is large enough" maximum amount of items per block, that also increases memory usage. Of course you still CAN introduce such artificial restrictions, if you want.
-Minimal per-block overhead (min. 1 pointer)
-Manageable per-object overhead (min. 1 pointer, 2 if linked in both directions)
-It's faster to remove item from the middle of a list (in case you would need to move other items in an array to get rid of empty slots)


And of course some (minor) "bad stuff"(tm):
-It's slower to get n'th item of a list (compared to direct array access)
-Great care should be taken when managing all the lists items can belong to (it's too easy to end up with same item in several lists)

As for Unity3D / C#, don't really have any experience with either.

I guess this ended up rather technical for an average forum user, but hopefully someone finds this useful

Just makes me wonder, why they didn't do it like that in the original to begin with?

Thanks for the suggestion. It is indeed related to an older post, as in the meantime I switched to a free movement scheme that puts away with the block-by-block movenet and 90 degrees turning. So, there's no need to keep items organized per block. The reason I had the four item limit was because I really wanted to preserve the different generic item containers that represent dropped items. Four of them can fit in a tile without any mesh overlapping.

[Hanzu]

My Hired Guns memories:

• I always liked the stuff that game with the original game. I read all the booklets that were included and they opened up the atmosphere for me.
• Amiga 3000 with internal flicker fixer made the interlaced loading screens not to flicker and look really high density by that times standads. I really liked that, since I did not want to pay all that big money for for A3000 and not getting enough extra for gaming.
• The music was really nice. The loading screen music especially.
• I mostly played with friends and with 4-player adapter adding 2 extra joysticks. Which was extremely fun, because there were not so many games utilizing that method.
• I liked the idea of co-operative gaming, since I already had got tired of so many competitive games available.
• I liked the use if items and the idea of exploration and little puzzels.
• I hated ravines filled with water, since they spoiled your food and to avoid the need of food and air, I usually played as character that did not need those.
• Enemy AI was really nice, they pursued you and sometimes went through a lot of trouble to get to you. They also used those lifts/elevators. I also liked pushing the big blocks to make enemy "mechs" to go past you and you to shoot them in their side.
• I did not really like the idea of the ultimate weapon beeing a banana. After playing so many hours, it felt like the designer got tired of desinging and did not take player seriously by adding a banana. Maybe funny for someone, but not for me.
• I wrote a detailed walkthrough for it, but it is still somewhere in my Amiga archives. Have to really motivate myself to dig it up sometime.
• Waited for Hired Guns 2 with high expectations and looking fresh screenshots, but as you know it never came.

Now I would also like to test how different is PC version. Please go and vote for this wish to have it for sale again. When I write this there is only 70 votes and hopefully they may add Amiga version too like they did with Wings: http://www.gog.com/wishlist/games/hired_guns

[Cherno]

The PC version is not much different, some color changes here and there (Desvergers coat is purple!) but otherwise it's exactly the same as the Amiga version.

I voted, but I have to say that the game, especially the PC version, just doesn't hold up by anymeans. Even when it came out in 1993, it was very son eclpised by the release of Doom (thanks to it's protracted development schedule). Thus the need for an updates version that preserves the things that were great about it (four player coop/competitive, dark and gloomy sci-fi/horror atmosphere, puzzle/action hybrid gameplay) while avoiding the bad things (mainly the GUI, especially the inventory system, and mostly meaningless character stats).

CIM lives again!

I remember keeping that damn No for the whole game and then finally getting the Disruptor to find that it practically kills CIM using.

Still very fond memories.

[Cherno]

I needed a weapon for my current project, which is not related to a specific game but rather aims to create a FPS/ARPG character control system (input, moving, animations). So I decided to revisit my all-time favourite, the Naomi IV Assault Rifle. I aimed for a low-poly look and pixel-art style textures.

The original (with filter applied):


My take on it:

[Predseda]

Naomi IV is imho only modified M-16

[Cherno]

There are similarities, yes... Which is actually a good thing because it helped me extrapolate from the few pixels of the icon graphic towards a 3d model

[Cherno]

All files have been re-uploaded after my old webspace provider closed.

[Predseda]

Damn, where to?

[Cherno]

Er.. To another free webspace / my DropBox. All links have been repaired.

[Cherno]

Hey all

Just sayin' that I amk working on this again I had to finish work on my voxel engine first, and now I am adapting it to Hired Guns. Things are progressing fast and I'm currently coding the menus (inventory, map, stats). As always, I'm looking for 3d artists who share my love for the game and would like to contribute (items, monsters, environments...).

Anyway, keep low and watch out for Rahls!

[Predseda]

I rahled.

[Cherno]

A quick look at the HD version of the user interface, specifically the DTS (Digital Terrain Scanner). The map is generated from the map data which in turn was edited by myself right before taking the screenshot via the map editor.

DTS.png


The DTS is about 80% done. Missing are icons for stairs and pushable blocks, as well as the player icon.
The inventory is also in a fairly finished state. It is possible to pick up items, drop them, open containers and take items from there and store items in it, and assign hotkeys for things like weapons and medkits. The whole user interface is designed to also support gamepad controls (besides mouse + keyboard).
Edit: Somehow, the "Store" tab is missing, I must have hidden it by accident

[Predseda]

Do you plan to release any WIP version? I enjoyed those you threw to us earlier.