Here's the work in progress blurb so far: Shadows of Starlight "You are a covert operations specialist for the Union of Federal Planets (UFP). A recent spy report indicates that a new weapon is being constructed in secret by the Zirax Empire - the Union's biggest threat. Your mission is to find out what the secret weapon is, to locate it and then to destroy it. You have landed with the Tactical Commando Module on Brexxis, a desolate ice planet. Your superiors assume you can pick up the trail from there." Hey everybody, with the wonderful additions, Eleon Studios gave us with patch 6.0 we are finally able to make our own scenarios. So @Taun Hawk and I got together to actually build our own scenario. We always loved building our own modules (like in Neverwinternights 2 and in D&D Swordcoast Legends). I like Empyrion a lot. But I never enjoyed open sandbox games for a longer period of time unless there was some sort of purpose or story which drives my motivation. Since the core game doesn't offer it we decided to do it ourselves. What we are aiming for: The scenario we are building is story driven, with an intro, middle part, and a highlight end. We are aiming to offer a different experience you can have when dropping out of an escape pod on any MP server. But at the same time, we wanted to keep all traditional elements which make Emyprion fun as part of the scenario like building a spaceship to go to your next destination. Since this will be our first scenario, we intended to keep it short and a Single Player experience only. The goal was to make it completable over the weekend. We want to add a lot of custom structures to surprise the player. We also want to make every planet matter. We want to avoid forcing you to warp jump through 20 systems - just to get from story part A to story part B and in between, there are nothing but bland planets. We would be bored by this and so would be players. And finally since taking POIs is an activity the two of us enjoy the most, there will be a heavy focus on it. Our biggest goal would be if a player has so much fun playing our scenario that he is also willing to stream it on Twitch or putting his "Let's Play" on YouTube. Some observations about scenario building so far: IT TAKES TIME: Even when still relying on ready-made trade stations and POIs to fill up planets it's a big amount of time you have to invest when making a scenario. Being two people already helps to share the workload. Re-using structures other people have built and uploaded also helps. MAKE THE STORY FIT THE GAME MECHANICS: As we are on the receiving end of what the game engine allows it's often easier to make the fit the story to the capabilities of what the PDA.yaml file allows. WORKAROUNDS: On the other hand to what I just said you always have to think hard if there is a workaround to make your idea work. Switches and sensors giving global signals and progressive chapters are your friends. PLAYERS WILL BREAK YOUR SCENARIO: We are currently relying on the new sensor objects to progress the story. We are aware that this can be rather game breaking since we can't protect the sensors from damage. We tried to hide them as good as we can but the risk is always there that the player messes up the scenario by a bombing a structure with rockets and explosives. Sometimes you simply don't want a POI to have an Alien core so the player can blow up things... NEVER TRUST OTHER PLAYER MADE CONTENT: You can't 100% rely on planets, playfields or vehicles other players made. We tried to incorporate them in our scenario only to find out that there are bugs which we then have to track down with meticulously effort (typical candidates are: creatures not spawning on playfields, vehicles lacking proper setup light sensors, bad block decisions, uneven base designs). CONSTANT PLAYTESTING IS ESSENTIAL: Every small change to a YAML file could cause an error. If you don't test every step over and over again inside the game it will be extremely hard to track those bugs down. Making a scenario beyond hacking a few planets together is a quite some work and requires dedication. I'm not surprised we only see so few on Steam. Our ever growing list of things, we'd like to see added to the game from a scenario building perspective: Error messages should be more clear - even in Alpha: I don't mind things don't work right away. But tracking things down without knowing what to look for is a pain. The blunt "An internal error has occurred" has caused more headaches than rewriting lines of code. More dev comments in existing YAML files to explain how things work would be nice: There is a lot of time we have to "waste" experimenting with settings. I wish there would be YAML files with more detailed # comments about what each setting does and which parameters are available. With each update, this is getting better of course and Hummel tries his best to also add to their FAQ. There are still so many open questions. But I'm sure we're getting there. Quest system: Decades of playing MMOs have taught gamers how a quest works and set a certain expectation: "You walk up to a NPC; he asks you to do something; after you did it you come back to the NPC to get your reward. If you decide to you can also skip a quest without breaking the story flow." A system like this is not part of the game yet. You have to play around this traditional course when writing a scenario at this point. But I guarantee that people will expect something like it when they try to build a scenario. I'm aware that this is not easy to implement as this system also requires adding mechanics which allow interesting things a player can tackle (like destroying a certain object within a base, vehicle or killing a named NPC). Progress of "Shadows of Starlight": Story and text writing: 80% Proofreading: 15% Custom structures built: 70% PDA Chapters: 90% Playfield and sector code: 70% Internal playtesting: 10%
Yup, all of what you said is true. Especially the time and effort involved. Once you get it done, you can look forward to the next version that will break all your custom stuff. Ok, not totally true, but with all the features being introduced, maintenance is a big issue too. I think scenarios have a PDA feature that allows for custom quest events. Someone else might be able to chime in and confirm. Good luck on your endeavor. Send it my way and let me play it!
One of the things you learn when building scenarios are the completely two different ways how the game treats playfields. You either have a playfield with randomized objects: The game distributed all elements (POIs, TOs, starter bases, ore) for you via the seed number. As long as you stick to the same seed number all objects will stick to the same place. Alternatively, you have a fixed environment where every single element needs to be placed manually with its proper X, Y, Z coordinates. Planets and moons can either be fixed or random playfields. Asteroid fields and space orbits can be (afaik) fixed environments only. Both settings give you unique ways what you can do with the game: Advantages of random playfields: * the game does the object distribution for you * it saves a lot of time when populating a playfield * resources are being placed just as the players knows it from the base game * you can spawn SVs and CVs as part of this random distribution, but they will be "bases". You can sit in their cockpit, but they simply won't move / fly. Fixed environments: * you have total control where everything is placed * you can place objects in any altitude (either high in the air or buried into the ground) * you can spawn object onto or in mountains, which is something the random usually evades * you can spawn any object in an angled position just as you would do with the "setrotation" console command * you can spawn SVs and CVs and they actually do fly and work as such! * you can dig objects deeper with the YAML file than you can with the setposition console command; CVs, for example, will "bounce off" the ground in a live environment Unfortunately, you can't mix them. This can become an issue when you want to build a planet quickly and the player is supposed to pick up an abandoned and flyable ship waiting for him there. Prepare to fill the whole planet with objects manually or it will look abandoned. Takes time and playtesting. Work continues for our scenario otherwise... we spent a lot of time texturing objects this weekend. It's possibly one of the biggest time sinks in this game atm and gets annoying with huge objects. I wish I could preset a texture and color on a block before placing it for example. Then we wouldn't have to go all over again after we are done building something. I also tried to create a simple warning light. A light that goes on and off. Something that indicates an alarm. I tried all tricks with different sensors the player walks through or a stacked delay command. Unfortunately, the logic system is rather unforgiving. Only a single logic can change the value of a certain variable. I gave up. Heck, I'd be happy if a light would turn on and off 3 times only instead of indefinitely. Couldn't find a good workaround. If anyone found a neat trick to pull it off with the current system, please let us know. Ever growing wish list of things we want to see as scenario builders: * SVs and CVs that work like real ships in random distribution spawn playfields * Make texturing/coloring easier! Mirror texturing which works just as the mirror building tools. Preseting a texture and color before placing a block would also help. A T2 color tool which spreads textures and colours on a bigger radius would be a blessing, too. * Blinking lights! We need alarm lights, warning light for vehicles, signaling space stations, antennas with warning lights for passing flying vehicles, warning buttons, attention warning lights when the ramp activates and animated runway lights. It fits perfectly to a sci-fi setting and is hopefully not too hard to implement. This could either be an animated object or a frequency you can set in the light object settings Progress of "Shadows of Starlight": Story and text writing: 80% Proofreading: 15% Custom structures built: 73% PDA Chapters: 90% Playfield and sector code: 73% Internal playtesting: 12%
Questflow Working with the current PDA functionality is easy once you get into it but a bit hard to deal with if you never made a mod for a game before. The biggest challenge is dealing with player expectations versus what the current engine is able to supply as feedback to the players. If you have played the "Dawn of Galaxy" scenario introduction or played the tutorial missions of Empyrion you have already came across the different structure types EGS currently offers and which the PDA.yaml file uses. We have chapters, tasks, and actions. A "chapter" has 1 or many more "tasks". Each "task" has 1 or many more "actions" (= things the player must do to complete the task). First of we have the "Chapter": A chapter has small preview image, has it's special sound when you finish it, can yield a reward and - best of all - has a small pop-up in the middle of the screen with centered text. Unless you are giving the player the option to activate several independent chapters at the same time then a player should only have one chapter active at one time. Several active chapters cannot interact with each other (as in you cannot check a status of chapter X to influence things to activate or become available in chapter Y). The very first chapter of a scenario additionally has a prolog text on a big screen filling popup. It's the only time you can activate such a neat big pop up. You can also see the name of the next chapter after this one you will receive as a reward. Next in the structure hierarchy is the "task". Each task can have a small preview picture inside the PDA. There is only a text message you can activate in the chat once the player completed a task. If the player misses it, then he either might not realize what's going on in your story or he might have missed that he is supposed to do the next task now. The task title will appear as a headline on the left side of the screen above the actions. Tasks of a chapter can only be finished one after another. The lowest hierarchy is the "action". The actions of a task create the bullit points list on the right-hand side of your screen. They can be fulfilled in any order. This is important to remember as you cannot control which actions the player completes first. So keeping this in mind we tried to create a simple quest NPC: 1) You walk to him, 2) he gives you a quest to do something, 3) you do it then 4) come back to get the reward. That's not as easy it could be in the game at this point. 1) You walk up to the NPC. No NPC has a big exclamation mark over their head. You have to indicate with the task picture how the NPC looks like so they player won't miss who is supposed to "talk to". The NPCs also don't talk at the moment. So what did was placing a sensor area right in front of the NPC. It gives a global signal back to the PDA simulating that the player is now "talking". Additionally, we hardly have single NPC standing available atm. We have "traders" which always will be clickable traders. Single NCPs sitting or in a group are the better option here. 2) NPC gives you a quest to do something. Looking at the structure I explained above it's not a good idea to have the action to go up to the NPC in the same task like the rest (do something, come back). If we would do that there would be no indication that the player has arrived at the spot where he is supposed to be. They only feedback the game can give is sending a text message in chat - yes the chat system which blends out after a few seconds of inactivity. Good luck telling the player that the NPC greets you, and gives you details about his quest in a short comprehensive chat message. So we needed to do was placing the action "Chat with the NPC" at the chapter. Once the player finds him he now gets a handy small pop up in the middle of his screen thus forcing him to stop what he is doing. This way he also won't miss it. Here we can give him the quest text. 3) Do the quest / 4) come back to get the reward. Now doing the quest action can be together with the "return to the NPC" action inside the same task, right? No, it can't. Unless you are making the player "hand in" his quest at a completely different location, the player will most likely head back to the NPC who gave the quest. Since we are using a single sensor inside a POI to check if the player has found this NPC it will also be the same sensor who will signal again to the PDA file if the player has returned after completing his task. This means if the player walks around the NPC a bit he will trigger the "return to the NPC" before he has completed the actual thing he is supposed to do. I will not go into details what a player can actually do as a quest as we are super limited at the moment. So: It's all about workarounds at the moment. Ever growing wish list of things we want to see as scenario builders: * Possibility of having a pop up when a task is done - no only at the end of chapters. * Possibility of turning off the feature that actions can be done in any order. * Adding a sound when a task has been completed - not only at the end of a chapter * proper word wrapping at the end of PDA or chat lines. Currently EGS cuts of words right in their in the middle without any separation dashes or any kind of proper word or syllables separation. Progress of "Shadows of Starlight": Story and text writing: 82% Proofreading: 15% Custom structures built: 77% PDA Chapters: 90% Playfield and sector code: 76% Internal playtesting: 14% Fancy stuff (screenshots etc.): 17%
Hello,. i came home today from vacation and i see that i had a message on steam,. I here by i coppy-paste : Hi Overlord! We love this Oil Rig Base, in fact we love it so much we would like permission to add it to our upcoming scenario: Shadows of Starlight, created by me and Amurayiwestgate. Let us know if this is ok, thanks My answer is yes ,. shure ,. go ahead i am honnored . i am realy interested what you will do with it. So i hope this is answer enough to the Question
Doing this little project is an astounding timesink. We are talking about a small single player scenario of merely 3 planets and 9 playfields here. Yet, we want to make sure it's fun and bug-free in all aspects. All things must work as intended before we release it. We also always often feel we are trying completely new things which we haven't seen in the game before yet. Of course, we don't know what kind of surprises all those multiplayer server hosters prepared for their players in their galaxies - so we can never be sure. Some of the problems we are currently tackling: PVs dropping out of the sky: Our patrol vessels work fine in random spawn planets. Yet we have a fixed position planet as well and the PVs, unfortunately, drop out of the sky as if they would have run out of fuel. As fixed playfields are not really a thing in EGS I suppose this isn't a high priority for the devs to fix. Planet colors: Oh god - what a nightmare! We have been given quite a few knobs we can adjust to make the planets looks fancy. With so many factors like light, fog color, atmosphere color, day/night colors it's extremely hard to come up with a specific color set you have in mind. Instead, it's all about trial and error... and saving fancy color combinations for later. But a single task like "make a yellow fog" turned into dozens of combinations on "greenish fog", "blueish fog" or "gray fog". We really need more info how the different color settings interact which each other from Eleon. Creature spawn delay: A quest like ... "look around the planet and kill 3 dinos" sounds simple, right? And it should be easy to test, right? Well, it isn't. The game hard coded a 36 (?) minutes delay into the system which prevents any creatures from spawning too early. They made it so that once you come out of your escape pod you aren't killed by raptors right away. However, this dreaded timer has a major impact on quests on planets: If you fly to a planet the first time and you are being asked to kill X monsters right away, the player might not actually find any creatures until the timer delay has kicked in on this planet. The player might even consider the game or the scenario to be bugged. We are currently testing how to circumvent this issue. The initial "delay" inside the biomes part of the planet YAML files are all set to 0 already. Not sure how easy it will be to make them instant spawns. If this doesn't work we need to add game elements to make the play "busy" for 36 minutes before he has to kill some spawn. Exploding bases: We always liked that the crashed Titan parts are buried in the ground at a slight angle. We decided we also want something similar. However to put bases (or non-flying CVs) into the ground at an angle the playfield MUST be a "Fixed" version (instead of a random spawn playfield) as you otherwise cannot add the rotation. So every single thing must be manually placed on this planet. Like our crashed ships. Once done we happily teleported to the crashed ship, readied our drills and we were ready for some testing. Oh, a closed door? Well, let's blast it open so we can dig out the dirt inside. What then happened caught us by surprise. With a sudden BOOOOOM not only the door burst open... no, the whole wreck exploded all around us, scattering around and breaking apart! We totally forgot that this buried CV is now considered a base. Thus its structural integrity now balances on a few tilted blocks. No wonder it broke apart. Testing now which angle is still OK for certain base forms before it explodes. Ever growing wish list of things we want to see as scenario builders: * Allow a "set rotation" command also for random spawn playfields. C'mon - can't be that hard to implement. Saves us the trouble to create fixed playfields. Or even better: * Allow objects in fixed X, Y, Z positions as long as it's a fixed seed on a random spawn playfield * Please explain how colors interact with each other - the super short descriptions of the color values inside of planet YAML file isn't very helpful. We need examples or even better: an exact explanation how the color values will interact with each other. It's easy to simulate different RGB color value interactions in Photoshop... but we simply need to know how to simulate it to be able to create a specific effect. * Creature spawn delay: Remove the hardcoded 36 minutes delay for any creature spawn. Make it a flexible value in each playfield file, please! The progress of "Shadows of Starlight": Story and text writing: 83% Proofreading: 16% Custom structures built: 91% PDA Chapters: 91% Playfield and sector code: 85% Internal playtesting: 21% Fancy stuff (screenshots etc.): 18%
So far no luck using bases which don't "explode" in fixed environments which are placed a bit underground (even though they are not angled): BOOOOOOOOOOM! Next try... Shooting a single bullet at a door in 3... 2... 1... Back to the drawing board...
We're making good progress. We hope to have the complete playable scenario ready at the end of this week (even though it might require a few beauty updates next week) Just out of curiosity: I there someone willing to playtest it and report any issues here in this thread before we put it live on Steam? As the updating abilities scenarios are rather limited at this point in Steam we'd prefer to squish possible bugs before it goes live instead of people having to come here daily and post about issues the have with it.
i have a small friends only server i am testing these on, we're just fooling around with Aaronstar's scenario right now until Piddlefoot gets his all done and fixed up. let me know if you need a server testbed and i'll load it up during our downtime overnights and i'll test things out
@amurayiwestgate I don't mind some testing. Regarding your exploding base CV's, some of the prefab wreckages have additional trusses on the bottom - and I would imagine just because of this reason. Might be worth checking/testing.
