Single player Mod
Skyforger2
Join Date: 2007-10-19 Member: 62681Members
Join Date: 2007-10-19 Member: 62681Members
<div class="IPBDescription">We need one and a lot of mapers</div>It might be early to consider something like that but, i was thinking about it a lot.
NS1 amazed me with art work. So when i played new maps i wasn't looking at skulks but on the map itself. An as we got Spark i see what people are making and it is amazing i would just love to run around those maps and enjoy them. So i was thinking about NS 2 Single player where u could explore mining sites,spaceships and space stations
with some occasional skulk contact's and fade or onus as a boss.
Well there would be all kind of scenarios, just want to know what other players think ?
NS1 amazed me with art work. So when i played new maps i wasn't looking at skulks but on the map itself. An as we got Spark i see what people are making and it is amazing i would just love to run around those maps and enjoy them. So i was thinking about NS 2 Single player where u could explore mining sites,spaceships and space stations
with some occasional skulk contact's and fade or onus as a boss.
Well there would be all kind of scenarios, just want to know what other players think ?
Comments
Very much looking forward to it. I'd certainly like to chip in myself, too.
So give me some single player, guys :)
I would like to map for this as Multiplayer puts to many restrictions ( gird system, onus size etc.) so i would be able to make more realistic maps.
Also waiting for Powergrid system and player mod to see how it works.
It's better to wait and see what entities UWE creates instead of inventing it ourselves first, and not to forget there's most likely very few props and models that you can use to create a story with, since most of it are just props fitted for the environment from what I can tell. NPC animations are probably left out as well, Half Life 2 for example have tons of them but that's because they use them in scripted sequences. Many of those smaller things that is necessary for a single-player level are simply not being worked on because this engine is so far in the development process only made for multiplayer-maps.
The realistic way that would help them out however would be a tutorial-like campaign, but then again I don't think there's too much AI yet to speak of apart from their very highly tailored weldbots and nymphs.
...I really do sound pessimistic, but just saying that it could be a bit better to wait things out ^^;
Maybe they can even give a proper statement on what they think about single-player as a part of Spark.
Maybe it's something they plan to create because new players could use a good way to be introduced to how the game works? Since it's going to be an AAA game it's always a good idea to consider the learning curve.
I think first of all we need a story, and some more depth in the whole universe. Since I didn't play NS for very long, I don't know that much about the background story. Also as far as I know, there isn't much background, so I think a story should be about the beginning of the war, or at least give lots of hints about this. Also it should give the marines some personality, since at the time they are just marines, but we don't know about if they are living like the marines of halo, or more like the imperial army of warhammer 40.000.
Anyway before any actual mapping, coding, modeling, ect. can start we should wait at least to the alpha, when we can see the basic shape of the engine and it's capabilitys.
I think first of all we need a story, and some more depth in the whole universe. Since I didn't play NS for very long, I don't know that much about the background story. Also as far as I know, there isn't much background, so I think a story should be about the beginning of the war, or at least give lots of hints about this. Also it should give the marines some personality, since at the time they are just marines, but we don't know about if they are living like the marines of halo, or more like the imperial army of warhammer 40.000.
Anyway before any actual mapping, coding, modeling, ect. can start we should wait at least to the alpha, when we can see the basic shape of the engine and it's capabilitys.<!--QuoteEnd--></div><!--QuoteEEnd-->
There's quite a bit of backstory in the manual and in the Six Days in Sanjii short story written before NS came out.
But it would be great to have single player telling story how the War beginning and how they found first aliens. <i>Natural Selection: First encounter</i>
Ignoring any backstory and subsequently any 'scripted sequences' that would be required to convey that story, coding the AI would be the largest hurdle. Even the dumbest of AI takes an incredible amount of work to program; path finding, interactions, 'tactics', etc.. all add up to a hefty load of work. Surely not an impossible task, but it would take a pretty large dedication from several individuals.
Ignoring any backstory and subsequently any 'scripted sequences' that would be required to convey that story, coding the AI would be the largest hurdle. Even the dumbest of AI takes an incredible amount of work to program; path finding, interactions, 'tactics', etc.. all add up to a hefty load of work. Surely not an impossible task, but it would take a pretty large dedication from several individuals.<!--QuoteEnd--></div><!--QuoteEEnd-->
I was thinking of using the first good bot to come along.
Like make it so that you download the bot, and then the coop mod would simply look to it for its AI. I don't imagine any bot makers would object to that seeing as it's basically a formalised version of marines vs alien bots or whatever which was somewhat common among NS servers.
I imagine bots would be coded more like NPCs anyway, as there's no real reason for them to be players when you can code actual NPCs for the game. You could add them to both sides and have a sort of ambient war going on if your server has enough jiggawatts.
Like make it so that you download the bot, and then the coop mod would simply look to it for its AI. I don't imagine any bot makers would object to that seeing as it's basically a formalised version of marines vs alien bots or whatever which was somewhat common among NS servers.
I imagine bots would be coded more like NPCs anyway, as there's no real reason for them to be players when you can code actual NPCs for the game. You could add them to both sides and have a sort of ambient war going on if your server has enough jiggawatts.<!--QuoteEnd--></div><!--QuoteEEnd-->
Can't say for sure, but bots would be based on the AI of half life right? Half Life had it's own AI system, I'm guessing those who made bots just modded what was there already.
But with NS2 there's no AI support at all, no pathfinding, no bots, nothing. You'd have to either build it all from scratch and mod the spark editor too, or mod in an AI system someone else has developed, into NS2.
Either way it's a lot of hard work, especially with what people expect from AI these days, and there will be no bots in NS2 until spark maps support pathfinding.
But with NS2 there's no AI support at all, no pathfinding, no bots, nothing. You'd have to either build it all from scratch and mod the spark editor too, or mod in an AI system someone else has developed, into NS2.
Either way it's a lot of hard work, especially with what people expect from AI these days, and there will be no bots in NS2 until spark maps support pathfinding.<!--QuoteEnd--></div><!--QuoteEEnd-->
NS2 will supposedly have weld-bots and (maybe?) controllable nymphs, so AI should be in place.
But with NS2 there's no AI support at all, no pathfinding, no bots, nothing. You'd have to either build it all from scratch and mod the spark editor too, or mod in an AI system someone else has developed, into NS2.
Either way it's a lot of hard work, especially with what people expect from AI these days, and there will be no bots in NS2 until spark maps support pathfinding.<!--QuoteEnd--></div><!--QuoteEEnd-->
No, bots in NS used an entirely original system.
RCBot was originally built for CS as I recall, they adapted it to NS because it's the same running around shooting people mechanic in a new environment. The pathfinding systems are entirely different from the HL2 nodegraph and they use player controls, NPCs don't have controls, they have goals. They also weren't built into maps, they were built on top of maps. RCbot comes with a node creation system which allows you to build a set of instructions entirely separate from the normal entity system in goldsrc, and good bot systems generate their own pathfinding data, CSS can do this built in as far as I know, it looks at the level geometry and creates a bot navigation system based off that.
<!--quoteo(post=1743897:date=Dec 15 2009, 03:44 PM:name=MuYeah)--><div class='quotetop'>QUOTE (MuYeah @ Dec 15 2009, 03:44 PM) <a href="index.php?act=findpost&pid=1743897"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->NS2 will supposedly have weld-bots and (maybe?) controllable nymphs, so AI should be in place.<!--QuoteEnd--></div><!--QuoteEEnd-->
And siege tanks, which are more difficult because they have to navigate floor terrain whereas flying bots can just fly over everything. Flying AI is probaby the easiest sort of moving NPC AI to make.
Half life 2 has buckets of AI stuff in the map editor but most of it isn't needed. All you need is the nodegraph because HL2 uses a predefined nodegraph to move long distance, and some enemies.
The choerography stuff is just for looks, and things like cover nodes and jump nodes and squad systems are just to make it a bit more interesting to go up against. To get functional multiplayer bots it's mostly about being able to move around the level which is generally a lot simpler than a singleplayer level, and how to get a realistic shooting system so they don't kill people instantly but don't suck either.
You don't need stuff like mega squad tactics or anything because they rarely work, all you need is something to spawn aliens in amusing places and get them to jump at players and claw their faces off. Basically it just needs to be the sort of AI that was in doom 3 and quake 4, and you can make the challenge be organising your marines to fight off the aliens, or shooting their weak points for MASSIVE DAMAGE because all good FPS enemies should have an attack pattern and a weak point. Lost planet does really good AI for its critters because they all have good attack patterns and weak points. When it comes to AI old school gameplay is still very good.
Very much looking forward to it. I'd certainly like to chip in myself, too.<!--QuoteEnd--></div><!--QuoteEEnd-->
As such, it would make more sense for everyone to poll their effort into one :P
I like this. What i think of Single player mod would be balance between quests and alien killing. It would be more like quest with random encounters of aliens and this system would work pretty easy. By quest i mean u are just recruited new marine knowing there isn't any active war now and they send u to some training camp or boring peace missions to planets etc. etc. ad u end up in a spaceship where everybody is killed and u don't know what is happening and u have to weld doors,vents repair things search for items etc. etc.
If anything, I'd say do an exploration single-player / co-op experience. Create some kind of challenge where the marine needs to 'Download the research data' from the newly-infested ship and evac. Make them change around so the player needs to get x of y, like 4 of 10. Since they change, there's replayability, and the player is always using different paths.
Then add in simple skulk AI, where skulks hide until they see the player (in pre-set locations, chosen randomly) and just attack on sight. Maybe add 'hordes' on random intervals. Very L4D-esque, but its replayability at it's finest.
This way, not only would it be pretty fun gameplay that can be played over and over (even with Best Times), but it's FEASIBLE. No crazy deep coding required. And it would give reason for larger maps. I always wanted to make such a scenario with Nexus.
Indeed.
What do they teach kids these days?
link is in the new player forum, here: <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=90930" target="_blank">http://www.unknownworlds.com/ns2/forums/in...showtopic=90930</a>
No I know, I'm just making the comparison because HL2 is probably the most obvious example of complex AI people are likely to be familiar with, you can see all the complex stuff available in the editor, it's just that none of it is really needed in order to make dudes that shoot you.
If anything, I'd say do an exploration single-player / co-op experience. Create some kind of challenge where the marine needs to 'Download the research data' from the newly-infested ship and evac. Make them change around so the player needs to get x of y, like 4 of 10. Since they change, there's replayability, and the player is always using different paths.
Then add in simple skulk AI, where skulks hide until they see the player (in pre-set locations, chosen randomly) and just attack on sight. Maybe add 'hordes' on random intervals. Very L4D-esque, but its replayability at it's finest.
This way, not only would it be pretty fun gameplay that can be played over and over (even with Best Times), but it's FEASIBLE. No crazy deep coding required. And it would give reason for larger maps. I always wanted to make such a scenario with Nexus.<!--QuoteEnd--></div><!--QuoteEEnd-->
I was planning on going further.
I'd have a large map with a lot of different 'dungeons' as it were, areas of high geometry concentration, be it other bases or sections of a ship or underwater biodomes or whatever. I initially though vehicles would be needed to allow transit across the intervening space but then I thought a tram system would be easier and better, because standing on a tram and going around is more immersive than basically transforming into a tank and driving around.
Each base would have randomised layout, the general structure would be the same but rooms would be interchangeable, you would make two or three rooms of the same size and with the same exit points but what's inside can be different, and you pick a different set of rooms each time. Certain doors might be impassable so the marines have to explore each time, you can't memorise the level layout because it's always different, you can at best memorise room layouts but you don't know where each room will be. You could also have some rooms be entirely not present, which would randomise the layout even more, or seal off corridors with flush wall sections so players don't know they're there until they play through again and find it open.
Inside the base you have a hive room possibly, and your aforementioned skulks and things semi-scripted to attack. The objective is to find an object in the base and bring it back to marine HQ, which can be another random base somewhere on the map which has a command chair in it. The base would upgrade when you bring items back, unlocking more weapons, more defences, more tools for the marines, and eventually calling in an extraction ship or something to rescue them.
The base would come under periodic attack from alien hordes if you bring an item back there. If someone dies they respawn in a random base and have to find their way out or get picked up. You could have a L4D revival and healing system to forestall death however.
Because it's coop you can introduce light as a mechanic, and also some new gizmos for the marines which would be unfair in competitive play but which are fine for coop, like beef up all the guns and add deployable sentries or whatever. You could also add pickups in the bases as well, like gun cabinets which contain rare guns or addons for them, so searching around for loot has benefits. Killing the hive could also have some sort of loot drop associated with it.
Basically it would be half RPG dungeon crawl, half left4dead survival horror, and half NS.
Take the idea of having separate rooms that can be configured into each other. That concept alone has a LOT of problems.
First, who says it can even be done? I'm almost certain it can't in Source, and we know nothing about Spark yet. You can just 'move rooms around' as you please, most editors need the vast majority of mesh and objects to be static.
Even if you could, it would be really hard to fit them together in a decent way. You'd spend a LONG time figuring out the exact configurations of the origins, and you'd probably need a slew of 'transition hallways' with their own attachment setup, and on top of all this, you'd have to program it all. I could go on about the issues that actually implementing such a concept would entail.
Rather, you can make a larger-than-usual level (like the side of NS1 maps) with an interconnected layout, allowing for multiple routes from any room to any other. Then, to make or enforce different routes, you can simply have static on/off roadblocks (doors, debris, fire), or simply leave all routes open and let the player choose the most optimal route on their own.
Anyways... feasibility should always be in your mind when you consider planning and starting such a project. Sure some ideas are awesome, but they are completely worthless if they can't be implemented. If one idea is 90% as awesome as another but takes 1/4 the time to actually build, and hence has a 10x better chance of being completed in the amateur world, then it's a much better idea. Because it might actually be done.
Take the idea of having separate rooms that can be configured into each other. That concept alone has a LOT of problems.
First, who says it can even be done? I'm almost certain it can't in Source, and we know nothing about Spark yet. You can just 'move rooms around' as you please, most editors need the vast majority of mesh and objects to be static.
Even if you could, it would be really hard to fit them together in a decent way. You'd spend a LONG time figuring out the exact configurations of the origins, and you'd probably need a slew of 'transition hallways' with their own attachment setup, and on top of all this, you'd have to program it all. I could go on about the issues that actually implementing such a concept would entail.
Rather, you can make a larger-than-usual level (like the side of NS1 maps) with an interconnected layout, allowing for multiple routes from any room to any other. Then, to make or enforce different routes, you can simply have static on/off roadblocks (doors, debris, fire), or simply leave all routes open and let the player choose the most optimal route on their own.
Anyways... feasibility should always be in your mind when you consider planning and starting such a project. Sure some ideas are awesome, but they are completely worthless if they can't be implemented. If one idea is 90% as awesome as another but takes 1/4 the time to actually build, and hence has a 10x better chance of being completed in the amateur world, then it's a much better idea. Because it might actually be done.<!--QuoteEnd--></div><!--QuoteEEnd-->
Actually it can in source, quite easily. The only problem is source used baked lighting and you can't bake lighting with brushes tied to entities. I could make randomised geometry in source easily though. All you do is build the room and then tie everything in it to a point_template, then use a logic_case with the pickrandom input to randomly select one of a number of possible rooms for that area. The problem with doing it in source apart from the lighting is that source keels over if you put much in the level, so you'd need some way to mitigate the amount of data loaded when the level loads, ideally you would store all the level data in the map but only load the parts you need. Source I think tries to load everything and then hides the bits it doesn't use, because the templates are stored in the map and it needs to load them all to pick one.
Obviously it depends on what sort of support there is but as long as there is a func_brush and a point_template analogue in spark, I honestly don't see the problem. For added bonuses, spark doesn't need to load huge lightmap into memory and it seems to have far more efficient geometry than source, also it doesn't need to load the visibility data either. It seems to do much more with the processor than the memory which should work in its favour. Plus if NS2 really gets a good modding community off the ground, maybe the devs will expand the engine a little, in source the main problem was some sort of buffer overflow when you put too much 'stuff' into a level. I would imagine that would be fairly easy to change, it certainly wasn't in earlier versions of source, and source is kinda hacked together as well from what I can tell, everything seems to break unless you're very careful about how you construct it.
As for how to construct them, also easy, keep the volume within a limit and the entrances in the same place, what goes inside is up to you. As long as the room is not protruding into surrounding corridors you can do what you want. It's easy to delete a room in a map and make a different one which connects to the same entrances, so making several such rooms and picking one at random should be fine.
Wouldn't be too hard to put together a single player exploration and lore based tutorial, directly following the six days events... maybe showing how he made it out alive. Create roadblock type concept learning events... usable as a tutorial for first timers, sounds like a fun project.
Your entire map's brushwork would be made of entities. I think there's big issues with collision and whatnot, but there's also the vis issues. You'd have to set up some crazy block-rooms of brushes to separate each section, in such a way that every possible level section in every possible level block will fit.
You'd have to make these visblock sections larger than the normal room size too; you definitely don't want every room being the same size. If the visblock sections are big enough to hold both the room and part of the surrounding hallways, you'd have a lot more creative freedom.
But then you'd be visdrawing huge sections of level.
And building sections, even with this pre-planned level of creativity, would still be difficult. Bah. Go try it if you want to. Hope it works out, but i don't think it would.
Your entire map's brushwork would be made of entities. I think there's big issues with collision and whatnot, but there's also the vis issues. You'd have to set up some crazy block-rooms of brushes to separate each section, in such a way that every possible level section in every possible level block will fit.
You'd have to make these visblock sections larger than the normal room size too; you definitely don't want every room being the same size. If the visblock sections are big enough to hold both the room and part of the surrounding hallways, you'd have a lot more creative freedom.
But then you'd be visdrawing huge sections of level.
And building sections, even with this pre-planned level of creativity, would still be difficult. Bah. Go try it if you want to. Hope it works out, but i don't think it would.<!--QuoteEnd--></div><!--QuoteEEnd-->
That depends on how the vis works, if nothing else I could just encase the room in a simple block of world geometry which is fairly basic practise in source anyway, you encase each area of an outdoor map in its own skybox block.
Presumably, if the editor is to be wysiwig, then it must be able to handle vis calculations, and that means vis calculations must be doable on the fly. Also as large parts of the level are prop based it means that props must be able to do vis calculations. If you're not using precompiled vis calculations I don't think it hugely matters whether the geometry is spawnable or not, you could write Lua to define a special entity which still affects visibility and is spawnable.
You don't have to make them larger than the room, you can just make it big and then have that be the largest room size, and then make alternate versions smaller, or more broken up, like the computer room on NS_hera with the big computer banks turning it into a zigzag. If you used the block method the only constraint is that the room has to fit inside the block and connect to all the exits, there are no other rules about its size or its content or how it plays. All you're being asked to do is make a few different rooms which all fit inside a space and have the same exits. That's a lot of variation you could have.
Collision doesn't have to be a problem, there's no problem with collision on func_brushes in source because if they don't move you can compile special collision or something. Plus NS2 will probably handle collision on dynamic objects anyway because it has the trams which are supposed to be in the game. And NS1 also featured lots of lifts.
Building sections wouldn't be hard, I've done it plenty of times in source, if I don't like a room I delete it and build another one to fill the space. And this isn't a compettivie game, you don't have to worry much about making it symmetrical, in fact the more the geometry favours the aliens the better. You can magically teleport aliens in as long as you do it out of sight.
If I didn't have a good idea of how to do this I wouldn't be suggesting it.