Concept: FPS sci-fi roguelike with bullet time

I think it’s best to get the weapons prototyped first and try them out in a game environment. Otherwise time could be wasted on making a gun model which doesn’t get used.

I like the idea of data storage upgrades. The game is kind of a scavenger raid, like STALKER you have to find info about what happened, but there could also be commercial data that could be sold, or physical objects which could be valuable… I like the idea of selling data, because it wouldnt require a physical shop. Just wire the data to your broker and then spend your cash on downloadable software upgrades. You could also buy access to military data about the facility, or pay for items to be teleported to your location… not sure how I feel about commercially available teleporters though.

Okay, do it the way you are you doing it.I am looking forward to updates.Keep them coming.

Instead of teleporting, could you have an area where the items could be parachuted in? This area might be heavily guarded and the player must be careful to clear the area first to avoid alerting anyone. The other way would be the Thief system where you stock up before a mission and that’s it: thats your gear (bar a few minor pickups in level). The latter would be simpler to plan, and drive the player to look for more loot as they have to fund the next mission.

As far as items are concerned, could the player have a tool like a 3D scanner that could scan physical objects of interest? It would simplify things as all loot would then be digital. I imagine 3D printing technology would be superior in the future so the client could just print the pattern sold to them (for example, the player could steal the blueprints of a new gun- the client could be a rival corporation and then print it on an industrial scale).

I did wonder if the player themselves could have a portable 3D printer (to make new items in level) but I thought it might complicate matters- it does get round the teleport issue though.

Hmmm… 3d printer would be good, get the plans for a new type of gun, set up your printer and the item is loaded in to your inventory. Sounds like a good game mechanism. But if you have the blueprint why not print an infinite number of medkits?

Perhaps the printer needs cartridges of particular chemicals? I like that idea much more than teleporters. It’d be great if all the technology in the game was near future stuff. Stuff that can actually exist. Maybe we can’t build it now but we have an understanding of how it might be made (like a cybereyes or a powered exoskeleton or a lazer induction particle gun).

Even with the printed parts there would still be room for special equipment modules which are too complex to print. Like a special energy converter to make the gun fire faster, or a serum for rapid cell regrowth. They would be really valuable objects.

I also like the idea of prepping for a mission. I already thought of having a prep area where you can stock up on guns and ammo, or equipment like a cyberdeck for hacking or a stealth suit, as much as you can carry.

You could have a system as in System Shock 2, where everything costs nanites- maybe a good game mechanism would be that between missions you buy nanite cartridges (and that you can only carry a certain number in mission) so it limits what a player can make in mission, avoiding the infinite healthpack scenario. Perhaps there might exist rare loot in the form of extra cartridges within the level too (maybe in hard to hack systems).

A few years ago I made some guns for a 1st person shooter concept, but I don’t think I have them any more. They’re probably going to look a bit similar, but less colorful. :slight_smile:

Yeah, I liked the nanites in SS2 but I felt they were nerfed somewhat. It was pretty rare to find nanites but the things you could buy with nanites were quite plentiful, so you felt a bit disapointed when you came to buy something finally. It did allow you to stock up on rare ammo for a particular gun, but that was about it. It’d be nice to have a more flexible system.

But in SS2 there were chemicals which you needed for research. What if you need certain chemicals for a recipe, Like in a potion crafting mechanism in an RPG?

1 rocket launcher:
2 cartridges of e-steel alloy
1 cartridge of graphine-324
3 cartridges of high grade chem-plastic
1 cartridge of silicone-m solution

1 pack of super magnum ammo:
1 cartridge e-steel alloy
1 cartridge poly uranium alloy
1 cartridge explo-f granules
1 cartridge explo-d granules

Some chemicals could be quite common, like the e-steel alloy above, while others would be rare. This should stop the player from making too many powerful items early on.

Which do you think would be better? Requiring a recipe but no in game data blueprint would bring in the mechanic of “meta-knowledge” so that the more times you play the game, the more recipes you know (as a player, not your character), the better you can play. On the other hand just requiring generic refill cartridges and a data blueprint would limit you to the items you’ve found and scanned in that particular run through of the game.

Or perhaps the a hybrid, where you need a data blueprint, but there are several types of cartridge, like construction, chemical, liquid, reactant, exotic etc… to stop people from making 1000 medkits and force them to diversify a little.

Tonight I worked a little more on the demo. Some basic enemy damage script is in, try shooting the green cubes they should disapear. I added a simple light manager too to make the most of a small number of lights. That needs more testing and development. The lightning gun has been reworked, as has the blaster. I also added some sounds. Weapon accuracy is currently not that great (there’s not targeting reticule yet), but later there will be some more development along that line too.

Do you think auto aim would be a good upgrade?

Limit the amount of stuff the player can carry.And if the player leave stuff down where enemies can see it they will steal it.what if you had to put things in good hiding places in order to prevent them from being stolen.

> Smoking_mirror: That’s a difficult question! My thoughts (text tsunami!)

Auto-aim/target is a good upgrade as you could have /buy incremental improvements like Auto Target 1 that has a slight delay, while Auto Target 3 is almost instant (with a bonus of targeting weakspots / headshots). For non-augmented players you could also have a gun / gun and ammo type that with its first shot ‘tags’ a target, and fires a volley of bullets that home in on the tag. Right now DARPA in the USA are making such a weapon with self guiding bullets (the bullets are thought to have gas jets that alter its trajectory).

I like the idea of diversifying the materials needed for making things, but to have the blueprint / special cartridge model.

I think its simpler (for you too!) and it fits the idea of near future technology better than a universal material (which is a bit too futuristic). If a player is using the in game crafting tool, would limiting the amount of cartridges stop player ‘factories’ churning out too many items? For example, if you could take 20 cartridges with you in a level:

Basic Med-pack
Requires blueprint? No
1 Construction (for injector mechanism)
1 Chemical (for the medication itself)
Heals 10 damage

Enhanced med-pack
Requires blueprint? Yes (found in level or perhaps purchased)
1 Construction
2 Chemical
2 Reactant
Heals 30 damage

By limiting the cartridges you still give the player the ability to make items on demand, but forces them to make choices (thus adding value to that item), especially if the item is complex. Also, there would be cartridges in the level too(?) so the player must keep an eye out for them, especially for the more rare examples (exotic, rare-earth etc). I would think for in game lore the military would have this technology as well, so bases and other areas would keep cartridges as to manufacture items they needed, so it would not be out of place to see them in guarded places.

Finding /stealing/buying blueprints gives an incentive to unlock better equipment possibilities. The player could begin with a core of basic blueprints and then add more. By blueprint, I mean that it guarantees you get an workable item for the cartridge cost, and you know what it does. If the player feels brave, they could try a combination with no blueprint and see if it works. For example:

Basic bullet
Requires blueprint? No
1 Construction
1 Mineral
Deals 1 damage

??? bullet
No blueprint
1 Construction
1 Mineral
1 exotic
Deals ??? damage

The latter bullet has no blueprint but is a bullet. Only by firing it will we know its effect- is it more lethal to humans or robots? It could be a dud and do less damage. Some combinations could do nothing and it wastes cartridges.

(this is what I am doing with wrectified) (~60 fps)

however, my enemy units will float using rays and navigate using navmesh, so they don’t fall through ever,

Concept:

in early levels of game, you collect up to X resources, bring to “recyclery”
objects are converted to base metals/elements

3d printer
can then be used to convert resources to objects,

later in game = teleporter gun -> beams resources to recyclery or “flags” them for a robot to move for you?*

*Wrectified will be using similar mechanics

@rubbernuke
when I think of it the idea of using cartridges with no blueprint seems a little strange… how would it work? We put in the cartridges and press print? however maybe basic blueprints could be in the player’s data library from the start.

@blueprintrandom
I like the idea of a recycler.

I don’t recommend changing the speed of logic or physics with python directly using the setlogicticrate function. In all my tests the physics simulation became unstable.

I just use 60 fps - with 3 substeps physics, and 3 substeps logic,

however I also use “Tap” and “every other frame” often.

I was actually trying to come up with a method that fires every x frames, unless “awoken” by a message or sensor.

I was thinking states.

Smoking_mirror: on re-reading it today it does seem a little illogical- personally the blueprint > cartridges > item chain is good enough.

I think what I was getting at was you could use what you knew worked and join them together. So if you knew xy made a bullet, you could add a third element z and see what you got - by adding a radioactive element you would have made an experimental depleted uranium shell, or by adding a mineral you got an armour piercing round.

You raise an interesting point about how the ‘fabricator’ works in game: does the player change to the item menu, scroll through a list of items and pick the one they want and the cartridges are automatically used, or does the player manually slot each cartridge in? The former implies a blueprint (as you are going by item), while the latter favours the experimental approach (sort of like having a spellbook and ingredients).

I think the fabricator would be a sub menu of the inventory. I thought today that the cartridges could be built in to the fabricator, and you find refills. So for example a single cartridge could hold up to 1 kg of constructor material, and a refill tops it up by 200 grams. A small pack of bullets might need 150 grams while a high powered gun might need up to the full kilo. An indicator on the cartidge could show you how much material you need and if you have enough for the selected blueprint.

Perhaps there could be a blueprint design screen where you get to combine basic parts and materials to create an experimental item…
Maybe something to think about for a future version of the project. Sounds like a lot of work. :slight_smile:

Yes, I think states would work best for that, or properties such as max_wait_count. I sometimes use that, so:

if own['waiting'] >= own['max_wait_count']:
    do_something()
else:
    own['waiting'] += 1

Incrementing a property doesn’t use up much logic even on a zero pulse sensor.

A short video of today’s progress (not much):

Are you going to have enemies that shoot at you from high ledges?Are there going to be any traps in this game?You think puzzle
that you solve would be good in this game?

Smoking_mirror: sounds like a plan as far as the constructor is concerned! Do you think as far as BPRs idea of recycling there should be a limit to how much you recycle? I was thinking the fabricator could have two cartridge ‘tanks’ - one that holds material (as discussed) but also have a tank of solvent that breaks down items back into material too? It would stop players recycling everything in sight and creating too many items. You could scavenge for extra solvent as you do material cartridges.

Well, recycling would be just for mostly useless items. Better to get them out of the way than have them cluttering up the level, and isn’t it great that even junk could have value without having to lug it all back to the local shop for selling? :slight_smile: Anyhow, there’s still the upper limit on how much your fabricator can hold of each material so you couldn’t turn in to a full time scavenger. Just pick up prime junk, that which returns rare materials or large quantities. In any case, the amount of material retrieved from an item would be small compared to the cost of fabricating it. We’re talking a simple shredder, sorter and compactor here not a nano factory.

Perhaps an in game area could feature a large scale recycler, or experimental nano deconstructor, you’d be able to visit that area to get a better deal for your recycling.

I think traps could be great, with perhaps an upgrade to vision to help you locate them. They can be laser tripwires, or pressure plates or anything really. AI is going to be trained to shoot from cover, or retreat to mount an ambush further away from the player. I don’t know if they will work well from high ledges, or even if such a location would be practical given the sort of level layouts I’ve got in mind, but perhaps it could work.

Today I modularized the code for the weapons and plugged them in to “bullets” which can be deployed from the gun.
That means I can start working on other types of “bullets” and set up a weapons fire manager. I’ll be adding a few other kinds of guns in the next couple of days. I want to work on the level builder but I have a few things I need to get straight in my head first. once I have that eureka moment it should all be clear to me how the layout can work, but right now I see a few obstacles.

I have a manager I made, that uses a list (for weapons) to draw and then attach a weapon,

it then fires the weapon using own.child[0] and data in the weapon,

so effectively the weapon manages itself, the player just “nudges” the gun to reload, or shoot etc

so “pickup” adds the value to the gunlist, of the name of the gun on a hidden layer,

this allows me to copy a gun, and change the bullet and ammo type, reload speed etc, without recoding anything,

if fire=1--------and----------------add bullet

if fire min 1 max=(end frame -1)------and------------add 1 to fire

if fire=end frame----------------and---------------fire=0

so if ‘fire’ = 0 the gun can fire again, and the property can be used to handle the animations as well, in effect this allow for a infinite size list of weapons, and as long as the player has the ammo ie “Rockets” “Energy” or any string in the gun he can fire it,

good lord, how many projects are you working on?!?! :smiley:

Its in wrectified :smiley: thats what I use for weapons !

:stuck_out_tongue:

Most of these projects are kind of concepts or large scale tests. There’s still a lot I don’t know how to do in Blender and python and I’m always trying out new things. The problem is that as a project gets more developed and detailed it becomes impossible to try adding new stuff because it’s impossible to know what’s causing bugs that pop up. When you have several dozen systems running at once in a nearly finished game, it’s very difficult to track down a problem in one of them, especially if the problem is caused by how the systems interact.

When a project is in the early stages that’s when you can design new features, or try integrating existing features more cleanly. One example is the bullet time feature I’m using in this demo. It would be impossible to add it half way through development, it has to be in from the start because almost every system is impacted. I want to use the bullet time feature in the RTS project I’ve got on the back burner right now, so this project started as a test bed for that feature. It’s currently mutating to cover a particle and bullet manager and a basic light manager.

Later I should be able to port a lot of the script from this demo back in to my RTS and also use some of it in my RPG.

@ BPR
That looks like a good system, but I’ve got a different one already which works with dictionaries. Each gun in the game is a unique instance of a “gun” dictionary, based on some templates. You can upgrade the gun, change its stats, it will get wear and tear, it keeps track of how many and what kind of bullets are currently loaded and you can drop it on the floor and pick it up later and it’ll remain the same. The gun manager just reads this dictionary to get info about rate of fire, ammo consumed and the type of bullet fired, and then it uses an emitter object parented to the player to deploy the correct type of bullet. The bullet is self contained, it in turn will do things like calculate path or ricochet, drop vector over distance, add muzzle flash and sound effect etc… and then the particle manager script will take over, moving the bullet along the path, playing the muzzle flash sprite animation, checking for collision with enemies or objects and adding damage as needed, all according to the globalDict value “bullet_time”.