Review for the last Convention Inoubliable

I would like to give you a review of our last convention with a presentation of EE. The aim is simply to give a feedback and hopefully to give comments and advice for other organisators.

EDIT : I realize that the review is pretty long sorry. I don't know if I write it for me or for you, so I just hope it could be usefull ^^

Place

It was at Lille (France) between the 3rd and 5th of november, for the COnvention INoubliable (COIN), a convention dedicaced on all gaming stuff : roleplay game, boardgame, LARP and some "special" game like EE and Artemis. The COIN is free and regroup regular players and curious during the 3 days.

Setting up

We were 2 to organized the EE room, we used around 10 PC with the debian netboot system of Daid. We set up 1 complete ship (5 stations + 1) and 1 or 2 single ships, depend on the number of participants. Sometimes, the ingeneering station was divided into 2 (power management and reparation), depend of the number of participants too. We use ligh effects with DMX and manual smoke effect, and we create separation between station (for example, science station could not see the main screen. And, finally, we added a cinematic screen outside of the room to show to others the play and to advertised them.

There was 2 phases : 1- during the day, quick mission and 2- during the night, pretty long mission.

1- The quick mission was based on the quick basic already done. The crew had 20 minutes to protect a station and itself and we scored at the end the number of kills. We were always at the GM screen, to add some more ennemy, to provide warp to some ennemy to keep tension and to discuss with relay by comms.We organized around 25 quick missions, with inexperienced and experienced players.

2- The long mission was based on a solar system scenario I reused, and asked players to do some roleplay. They had some individual mission or behaviour. The mission had 1h30 to succeed. Sometime they had to do a road trip near Jupiter to catch some stuff, sometime they had to launch probe in the sun to detect anomalies. We were always at the GM screen too to improvise the mission. We had a WARP problem system into the script : at long as they WARP, every crew members can be affect by a "WARP disease" which appear on their screen (sick, blind, paranoïa).We organized 3 long missions, with mostly experienced players.

Feedback from players

Around 120 unique players participed to EE.We have a very good feedback from the players. Missions was dynamic, the stations were easy to understand but hard to manipulate. The scoring system was a good idea to boost them to be more aggressive (for quick mission, I think fighting is the main goal of the game).For long mission, we had some very pleasant crews and they liked mission a lot. They liked the WARP disease system very good, because that add roleplay during calm period of the game. And because sometime, players had to get out their stations, another players could go to it for some individual mission. That worked pretty good and players didn't rest during all the mission.Light and smoke effects was very apprecied. According to the players, the immersion was very good, instead of earlier when EE was organised "only" with tables and chairs (or like the Artemis room just beside ^^).The 2 single ships was very apprecied because the crew became an armada and they could create more advanced strategy.Players asked for more and more screens. We try, without success, to provide a window screen and it was appreciated. But players thinked that more screens, with informations, logs, windows, ... could increase the immersion. It is even more the feeling for the long missions.

Relay players complain that the comms window is too big and that he/she cannot see the map and doing everything else. Based on this problem, a lot of relay players stopped the conversation often without read our message. Also for relay, some inexperienced players have problems to understand what to do for this station, especially during fights. We added them main screen control to compensate. Hacking system was not very usefull, because it was a bit too long during a fight and the mini game is not very immersive.Weapons players had some problems to see if beams are working or not. I don't understand why, because there is a change of color and the beam is visible on the main screen, but it was a frequent comment.Helm players saw a lot of time that their systems were overheated or damaged without real problems on these systems on the engenerring station. I don't know if some other players have notice that.We don't have comment from Science station, I don't know if it is a good or a bad thing. According to me, probe view and database were not used by players, because they didn't seem to be useful.Engeneering players thought that the power management screen is more usefull than the classic Engeneering. With 2 screens, the engeneer is more able to do the job (even more if the shorcut are set up).

Feedback from organisators

We were also very happy with this convention. We had no server bug and any crash so I was no stressful. The netboot system coupled with the autoconnect system are very pleasant to set up every new mission. We had a lot a problems with the keyboard shorcut file (coupled with the netboot). I don't understand because it worked before so I have to check it again. It was mostly a drawback for a regular player witch is blinded : it can only play power management if shorcuts are available.The single ships was hard for us to manage, because the energy and the systems didn't repair themself. So we always had to cheat with the GM screen or to contect ourself in their ingeneering station to maintain them ok. So, when single ships are used, they had to be planned with auto coolant and auto repair.We didn't use the tutorial mission because it is hard to set up in the same time of the autoconnect system. So each time we explain all the station separately.

For the futureWe plan to add some more stuff to EE to enhance relay station : separate comms and relay into 2 screens, and create a probe screen to follow a probe with a 3d vision.Also, we want to increase the integration of single ships : prepare it in advanced, be sure that visuals are concordants, add docking permission with the "main" ship.We also want to add even more possibility to the tweak system of the GM screen. For example, it is not possible now to change hull and shields of a orbital station.

I will provide each PR and branch into my github for these enhancement.

Conclusion

Thank a lot Daid and all the contributors for this game. We could do a lot a different things with it. The GM screen is very usefull and, because the game is open source, I can now add and propose some changes, enhancement and translation into french.We will organize the COIN next year and hope to provide more stuff, more screen, more fun !

Hope this feedback could be usefull for someone. If you have some questions or remark, don't hesite.

Comments

Never thought about running engineering on two screens. We could actually do the same trick as we generally run without relay on shows.

Note that the fact that relay can do comms or see the map was intentional. It adds a bit of tension on that roll. But generally we run without relay, and with operations instead of science on new groups. Reduces the required crew size, and removes the hacking, probes and relay view. Which are all quite optional as you noticed as well.

Cool review, that hopefully get me to finally work on some small PRs I thought about a while ago.

Unfortunately, one downside in using operations instead of relay and science is: You can't see your current reputation anymore.But on the other hand, thats what the additional info screens could come in. With the http api you can do custom info screens quite easily. I have made a small info screen based on kwadrokes script a while ago, nothing special, just outputting reputation and some of the most vital stats like shields, hull and reactor health.Speaking about it, I guess kwadroke's Alert status screen could be also one of those screens that can add quite a bit of athmospere. (On the other hand it will require relay instead of operations for changing alert condition, or e.G. a web page to do it)

Actually there is a way for single crew pilots to do damage and energy control. You just won't be able to do it with autoconnect. By joining manually you can activate single pilot, damage control and power management, and then switch through them if needed, but of course that can get quite hectic. But: only using damage control and single pilot, while leaving the power distribution to standard, could be feasible.

Out of curiosity a question: As you did run a setup with just linux computers: Were you able to have the glitch and warp shaders work when jumping? I am not able to use them on my linux builds, I always get the message at start that they could not be loaded even though the frag-files do exist. Oddly enough, they are working when running the windows version in wine, so it don't seem to be a graphic card issue. Of course it's no big deal, just odd.

@daid : I am surprising that you prefer to don't use relay in show. Even this is a complex and maybe not fully intuitive role, players like it and i like to run mission with it. I never test operations screen by the way.

@BlueShadow : I don't use reputation point because I like to discuss with players during the game (even for quick mission) and 2- because I didn't take time to translate communications option into french ^^For the single crew pilots, I think that moving between screen could be very hard. I test something to seem working : active auto repair and auto pilot and after increase reactor to 120% to provide energy. With this configuration, the ship is not fully customizable like with an engeneer, but it could work.

My setup is mostly with linux computer. For the jump shaders, i think it work for some PC, not for all of them. I never search why (I compile myself EE and I think I don't do all right for this fonctionality). And I have only one PC windows for the main screen, because my DMX interface work only with windows...

@gozirra : it is strange, because i always see Artemis or EE explanation with projector instead of screen ^^ And it works very well.

I am working these previous days for some PR : - A 3D vision for probe : this work very well. I hope to finalize the PR this night- A button in database to switch between my ship and the target ship, in order to compare values : not tested, but i think it is easy- Separation of the comms view, again for the relay station (for him or her, i plan to have eventually 3 screens : relay, comms and probe 3D ^^)

I've only run on small shows that are not directly space/startrek related. So allowing smaller crews works better then, and I only ran the simple basic.

As for single pilot ships running out of energy, if you set it up to allow docking to the "main" ship, you can recharge energy from there, combined with the autorepair and auto coolant, you should be able to fly with just the single pilot screen.

Warp shaders work on about 50% of our low end machines. So it's a bit of a hit/miss.

I don't use reputation point because I like to discuss with players during the game (even for quick mission) and 2- because I didn't take time to translate communications option into french ^^

Hm.. I don't quite understand than sentence. What is the relation between discussion and a currency unit? Or do you mean you left out the buying options completly, and you restocked the ships per GM screen?

About the things some players were not aware of: Maybe for the next show you could set up a seperate PC just for Tutorials, so inactive Players can use them to prepare themselves. As the Tutorials are pretty calm, maybe the players get the details better like how to see when beams are fired, or that the database can be quite useful, when there is no time to deep-scan multiple ships.

@daid: For me the warp shaders basically worked for all tested machines that support shaders in the first place - at least when using the Windows Version through wine. However, it did not work in the native linux build. But I just found out the reason: It's a path problem. EE looks for the shaders in the relative path resources, not in /usr/local/share/emptyepsilon/resources where the files actually are.I just made a directory "resources" in the userspace, copied the two shader files in there, started EE from the directory above, and the shaders could be loaded and they worked!

Yes, I spoke about change all with the GM screen. But I will go back to the reputations point I think. I think that using a "money" is a good idea, I just no take time to use it properly (and tweaking ship is faster );

For the tutorial screen, It was always difficult to take time and to have a good place to propose it. From now, i don't succeed, but whatever I will try it maybe the next time.

Another question about your original Post: The solar system script you have mentioned: Was it that free to space you shared a while ago or is it another one.The Idea of traveling through a solar system in EE is pretty cool, but I guess it is hardly possible with just a scipt but also would need some changes in the engines (scale, visibility, zoom level)@kalemar s attempts was very promising, but unfortunately it was not made public yet (as I know of) and I am not sure if it is still in the works.

I'm not completly sure if it may be better to to make the visibility not quite as high . Because when it is that high, it may emphasize the different scales too much, especially when there are multiple planets visible at once. On the other hand, planets suddenly appearing may also look weird, at least on a warp ship like in your scenario. But for jump ships, a value in between the two might work better.BTW nice idea with the ongoing calculation of planet positions!

Just another question: did you do the network install on Jessie, like in the help document, or with the new stable version, debian stretch?I tried it recently with stretch, but had some problems, as the build script ended before compiling EE. But it was just a quick try, I may have to investigate further.

you have right, I increased the visibily only to avoid planets. I don't see the problem of the different scales, but i will care about.For the calculation of position, I did'nt find the author, but i quite sure it is not me

Yes, my network install is with Jessie, so I cannot help me about this.

I don't understand what you said. I had planet collision and yes, that is very problematic because no realistic at all. But with a proper Z axe, I have no problem anymore. And I don't understand the link with the rendering distance.

With the scales I mean that it just looks a bit strange to see two planets that are far away from each other, but both of a decent visible size.

Okay so I have to look a bit further in the netinstall thing. What I am wondering about, is there also seems a bug in the script (a line using sudo, but debian does not preconfigure sudo to get root permissions, on a minimal install it is not even installed) and I am wondering why noone seems to mentioned it before. Maybe jessie just ignored the sudo instead of ending the script, but that'll be also rather odd.

I mean, "_glPerspective(camera_fov, rect.width/rect.height, 1.f, 99999999.f);" will give rendering artifacts within objects themselves. Could depend on your 3D model how visible this is.There is a whole math heavy article about it:https://www.khronos.org/opengl/wiki/Depth_Buffer_PrecisionWhich I have trouble following it.

Key thing is, when drawing, we need to know what it in front of another thing. The depth buffer handles this for us. But, as everything in computer land, this has limited range and precision.

I'm looking into changing the rendering into a multi-pass method, to properly render planets. But a few things are not working correctly right now, like the cloud layers on planets, and the size of the atmosphere aura. So I need to go back to the drawing board...

Patch might be a bit hard to follow, but the idea is that objects are rendered in batches in 25U range steps. From far objects first to close objects last. I think the rendering artifacts should be minimal.Note, that there is still a limit on actual planet size, making planets bigger then 10U would most likely introduce artifacts of it's own.

FWIW, in SNIS, we do 2 passes to get more depth buffer precision (I didn't implement that part of it though, my friend Jeremy did that part.) The code is here, not that it's particularly exemplary. There are some artifacts that are visible for alpha blended textures (planetary rings, atmospheres, nebulae) wherever they intersect the boundary between passes which we could never figure out how to quite eliminate. There's a slight overlap of the passes at the boundary as that seemed better than the slight gap that resulted if there were no overlap.