#or 'i like testing the limits of what the devs/writers allow you to do'
Explore tagged Tumblr posts
Text
Anyway. I think you can very much make the criticism that forcing a player to only be "nice" and write really awkward "unproblematic" HR-ass Marvel dialogue that has no conflict or zest is really creatively bankrupt and corporate, without saying shit like "I don't like this character and I wish I could misgender them because I'm an adult who can do so many critical thinkings."
"Limiting the player's choice in a role-playing game to only one type of response is counterintuitive to the genre" versus "If I can't do a genocide in an RPG then the devs are moralistic woke hacks."
Ya know???? Well. Anyway.
#da4#yeah i'll maintag it. what of it??#da fandom critical#and of course OP is an edgy russian lmao#and the post was transphobic af!! very cool!!!#love these folks they're always caricatures of themselves#'look guys!! i'm made of straw!!'#like not even using the guise of 'i enjoy playing evil characters and getting into that headspace'#or 'i like testing the limits of what the devs/writers allow you to do'#straight up 'i don't like this character and wish i could misgender them and call them slurs'#bro#for an Adult you sure are throwing a tantrum right now
21 notes
·
View notes
Text
•.̇꒰🌙 𝐇𝐈 𝐅𝐄𝐋𝐋𝐋𝐎𝐖 𝐒𝐄𝐋𝐅𝐒𝐇𝐈𝐏𝐏𝐄𝐑𝐒 𓂃⋆ .°
today i have a new pro tip for enhancing your experience of daily dose of daydreaming about your f/o!
all you have to do is basically downloading an app called "ai dungeon" (or you can simply search it on the browser version if you want to play it from there).
the game according to what wikipedia says since i kinda suck at explaining:
" AI Dungeon is a free-to-play single-player and multiplayer text adventure game which uses artificial intelligence to generate content.
AI Dungeon is a text adventure game; however, unlike traditional text adventure games, which use pre-written content, AI Dungeon uses artificial intelligence to generate effectively limitless open-ended storylines. "
so yeah, basically you can use it for roleplaying.
my experience + some notes:
• altough i haven't been using it for a while, i used it plenty of times. i have to say that the ai it's really funny to play with and isn't that bad at all, it can get fairly precise within the gameplay. although, since it's an artificial intelligence which we're talking about, sometimes its answers might tend to look weird or out of character/context, but you can easily fix it by redoing the action and by adding in the memory more notes about what the ai must keep in mind.
• also, it is free (unless you don't want to subscribe for premier features which aren't essential in my opinion unless you don't want the dragon model) and it's frequently upgraded.
• you can play an infinite amount of scenarios by creating your own, but there are also popular ones made by other users as well, the only limit is just your creativity and imagination -literally- you can do everything including nsfw
• you can play it in multiplayer mode with other users or with your friends. once there was the option to search online scenarios but for what i got it was temporarily removed for fixing purposes. i heard that hopefully they plan to get it back or to add new ways for sharing promtps which was one of the funniest things trust me
• the game allows you to create your own world and customize everything, locations, characters, info etc etc. what i suggest you to do (unless you don't want to play an original version/au) is searching info about your f/o contents on wikia, copy and paste and tadaaa, the ai will assimilate the informations!!
i personally find this app really useful for who is struggling with writer block, you can also create generators as well, talking with the ai, the possibilities are endless.
sadly i heard that the last updates caused some problems in the gameplay experience, but i've seen they devs are always busy at working on it so i hope it's only a matter of time before fixing it. alternatively, if you don't like the ai you can use NovelAi which is a valid alternative to this game. But you can find plenty others online, you just need to type "ai dungeon alternatives".
i haven't played it in a long time, but i just stumbled upon the game again and now i want to roleplay all the cute prompts i found on this site with my f/o lol
these are two screens i made last year when testing the ai.
i hope this will be useful!
#f/o imagines#imagine your f/o#platonic f/o#f/o#romantic f/o#f/o scenarios#imagine your favorite character#otp#selfshipping#roleplaying#roleplay#ai dungeon#AID#self shipping community#self shipping#selfshipping community#selfshipping tips#tips#k's tag
308 notes
·
View notes
Text
Insights into DAI’s development from Blood, Sweat, and Pixels
The book is by game industry journalist Jason Schreier (it’s an interesting read and well-written, I recommend it). This is the cliff notes version of the DAI chapter. This info isn’t new as the book is from 2017 (I finally got around to buying it). Some insight into DAO, DA2 and cancelled DA projects is also given. Cut for length.
BW hoped that DA would become the LotR of video games. DAO’s development was “a hellish seven-year slog”
The DAI team are compared to a chaotic “pirate ship”, which is what they called themselves internally. “It’ll get where it needs to go, but it’s going to go all over the place. Sail over here. Drink some rum. Go over here. Do something else. That’s how Mark Darrah likes to run his team.” An alternative take from someone else who worked on the game: “It was compared to a pirate ship because it was chaotic and the loudest voice in the room usually set the direction. I think they smartly adopted the name and morphed it into something better.”
A game about the Inquisition and the large-scale political conflicts it solves across Thedas, where the PC was the Inquisitor, was originally the vision for ‘DA2′. Plans had to change when SW:TOR’s development kept stalling and slipping. Frustrated EA execs wanted a new product from BW to bolster quarterly sales targets, and decided that DA would have to fill the gap. BW agreed to deliver DA2 within 16 months. “Basically, DA2 exists to fill that hole. That was the inception. It was always intended to be a game made to fit in that”
BW wanted to call it DA: Exodus, but EA’s marketing execs insisted on DA2, no matter what that name implied
DAO’s scope (Origin stories, that amount of big areas, variables, reactivity) was just not doable in a year, even if everyone worked overtime. To solve this problem, BW shelved the Inquisition idea and made a risky call: DA2 would be set in one city over time, allowing locations to be recycled and months to be shaved off dev time. They also axed DAO features like customizing party members’ equipment. These were the best calls they were able to make on a tight line
Many at BW are still proud of DA2. Those that worked on it grew closer from all being in it together
In certain dark accounting corners of EA, despite fan response to DA2 and its lower sales compared to DAO, DA2 is considered a wild success
By summer 2011 BW decided to cancel DA2′s expansion Exalted March in favor of a totally new game. They needed to get away from the stigma of DA2, reboot the franchise and show they could make triple-A quality good games.
DAI was going to be the most ambitious game BW had ever made and had a lot to prove (that BW could return to form, that EA wasn’t crippling the studio, that BW could make an ‘open-world’ RPG with big environments). There was a bit of a tone around the industry that there were essentially 2 tiers of BW, the ME team and then everyone else, and the DA team had a scrappy desire to fight back against that
DAI was behind schedule early on due to unfamiliar new technology; the new engine Frostbite was very technically challenging and required more work than anyone had expected. Even before finishing DA2 BW were looking for a new engine for the next game. Eclipse was creaky, obsolete, not fully-featured, graphically lacking. The ME team used Unreal, which made inter-team collab difficult. “Our tech strategy was just a mess. Every time we’d start a new game, people would say, ‘Oh, we should just pick a new engine’.”
After meeting with an EA exec BW decided on Frostbite. Nobody had ever used it to make an RPG, but EA owned FB dev studio DICE, and the engine was powerful and had good graphic capabilities & visual effects. If BW started making all its games on FB, it could share tech with sister studios and borrow tools when they learned cool new tricks.
For a while they worked on a prototype called Blackfoot, to get a feel for FB and to make a free-to-play DA MP game. It fizzled as the team was too small, which doesn’t lend itself well to working with FB, and was cancelled
BW resurfaced the old Inquisition idea. What might a DA3 look like on FB? Their plan by 2012 was to make an open-world RPG heavily inspired by Skyrim that hit all the beats DA2 couldn’t. “My secret mission was to shock and awe the players with the massive amounts of content.” People complained there wasn’t enough in DA2. “At the end of DAI, I actually want people to go, ‘Oh god, not [another] level’.”
It was originally called Dragon Age 3: Inquisition
BW wanted to launch on next-gen consoles only but EA’s profit forecasters were caught up in the rise of iPad and iPhone gaming and were worried the next-gen consoles wouldn’t sell well. As a safeguard EA insist it also ship on current-gen. Most games at that time followed this strategy. Shipping on 5 platforms at once would be a first for BW
Ambitions were piling up. This was to be BW’s first 3D open-world game, and their first game on Frostbite, an engine that had never been used to make RPGs. It needed to be made in roughly two years, it needed to ship on 5 platforms, and, oh yeah, it needed to restore the reputation of a studio that had been beaten up pretty badly. “Basically we had to do new consoles, a new engine, new gameplay, build the hugest game that we’ve ever made, and build it to a higher standard than we ever did. With tools that don’t exist.”
FB didn’t have RPG stats, a visible PC, spells, save systems, a party of 4 people, the same kind of cutscenes etc and couldn’t create any of those things. BW had to create these on top of it. BW initially underestimated how much work this would be. BW were the FB guinea pigs. Early on in DAI’s development, even the most basic tasks were excruciating, and this impacted even fundamental aspects of game design and dev. When FB’s tools did function they were finicky and difficult. DICE’s team supported them but had limited resources and were 8 hours ahead. Since creating new content in FB was so difficult, trying to evaluate its quality became impossible. FB engine updates made things even more challenging. After every one, BW had to manually merge and test it; this was debilitating, and there were times when the build didn’t work for a month or was really unstable.
Meanwhile the art department were having a blast. FB was great for big beautiful environments. For months they made as much as possible, taking educated guesses when they didn’t know yet what the designers needed. “For a long time there was a joke on the project that we’d made a fantastic-looking screenshot generator, because you could walk around these levels with nothing to do. You could take great pictures.”
The concept of DAI as open-world was stymying the story/writers and gameplay/designers teams. What were players going to do in these big landscapes? How could BW ensure exploring remained fun after many hours? Their teams didn’t have time for system designers to envision, iterate and test a good “core gameplay loop” (quests, encounters, activities etc). FB wouldn’t allow it. Designers couldn’t test new ideas or answer questions because basic features were missing or didn’t exist yet.
EA’s CEO told BW they should have the ability to ride dragons and that this would make DAI sell 10 million copies. BW didn’t take this idea very seriously
BW had an abstract idea that the player would roam the world solving problems and building up power or influence they could use. But how would that look/work like in-game? This could have used refinement and testing but instead they decided to build some levels and hope they could figure it out as they went.
One day in late 2012, after a year of strained development on DAI, Mark Darrah asked Mike Laidlaw to go to lunch. “We’re walking out to his car,” Laidlaw said, “and I think he might have had a bit of a script in his head. [Darrah] said, ‘All right, I don’t actually know how to approach this, so I’m just going to say it. On a scale of one to apocalyptic... how upset would you be if I said [the player] could be, I dunno, a Qunari Inquisitor?’”
Laidlaw was baffled. They’d decided that the player could be only a human in DAI. Adding other playable races like Darrah was asking for would mean they’d need to quadruple their budget for animation, voice acting, and scripting.
“I went, ‘I think we could make that work’,” Laidlaw said, asking Darrah if he could have more budget for dialogue.
Darrah answered that if Laidlaw could make playable races happen, he couldn’t just have more dialogue. He could have an entire year of production.
Laidlaw was thrilled. “Fuck yeah, OK,” he recalled saying.
MD had actually already realized at this point it’d be impossible to finish DAI in 2013. They needed at least a year’s delay and adding the other playable races was part of a plan/planned pitch to secure this. He was in the process of putting together a pitch to EA: let BW delay the game, and in exchange it’d be bigger and better that anyone at EA had envisioned. These new marketing points included playable races, mounts and a new tactical camera. If EA wouldn’t let them delay, they would have had to cut things. Going into that BW were confident but nervous, especially in the wake of EA’s recent turmoil where they’d just parted ways with their CEO and had recruited a new board member while they hunted for a new one. They didn’t know how the new board member would react, and the delay would affect EA’s projections for that fiscal year. Maybe it was the convincing pitch, or the exec turmoil, or the specter of DA2, or maybe EA didn’t like being called “The Worst Company in America”. Winning that award 2 years in a row had had a tangible impact on the execs and led to feisty internal meetings on how to repair EA’s image. Whatever the reasons, EA greenlit the delay.
The PAX Crestwood demo was beautiful but almost entirely fake. By fall 2013, BW had implemented many of FB’s ‘parts’, but still didn’t know what kind of ‘car’ they were making. ML and team scripted the PAX demo by hand, entirely based on what BW thought would be in the game. The level & art assets were real but the gameplay wasn’t. “Part of what we had to do is go out early and try to be transparent because of DA2. And just say, ‘Look, here, it’s the game, it’s running live, it’s at PAX.’ Because we wanted to make that statement that we’re here for fans.”
DA2 hung on the team like a shadow. There was insecurity, uncertainty, they had trouble sticking to one vision. Which DA2 things were due to the short dev time and which were bad calls? What stuff should they reinvent? There were debates over combat (DAO-style vs DA2-style) and arguments over how to populate the wilderness.
In the months after that demo, BW cut much of what they’d shown in it. Even small features went through many permutations. DAI had no proper preproduction phase (important for testing and discarding things), so leads were stretched thin and had to make impulsive decisions.
By the end of 2013, DAI had 200+ people working on it, and dozens of additional outsourced artists in Russia and China. Coordinating all the work across various departments was challenging and a full-time job for several people. At this sheer scale of game dev, there are many complexities and inter-dependencies. Work finally became significantly less tedious and more doable when BW and DICE added more features to FB. Time was running out though, and another delay was a no.
The team spent many hours in November and December piecing together a “narrative playable” version of the game to be the holiday period’s game build for BW staff to test that year. Feedback on the demo was bad. There were big complaints on story, that it didn’t make sense and was illogical. Originally the PC became Inquisitor and sealed the breach in the prologue, which removed a sense of urgency. In response the writers embarked on Operation Sledgehammer (breaking a bone to set it right), radically revising the entire first act.
The other big piece of negative feedback was that battles weren’t fun. Daniel Kading, who had recently joined BW and brought with him a rigorous new method for testing combat in games, went to BW leadership with a proposal: give him authority to open his own little lab with the other designers and call up the entire team for mandatory play sessions for test purposes. They agreed and he used this experiment to get test feedback and specifically pinpoint where problems were. Morale took a turn for the better that week, DK’s team made several tweaks, and through these sessions feedback ratings went from 1.2 to 8.8 four weeks later.
Many on the team wished they didn’t have to ship for old consoles (clunky, less powerful). BW leadership decided not to add features to the next-gen versions that wouldn’t be possible on the older ones, so that both versions of the game played the same. This limited things and meant the team had to find creative solutions. “I probably should’ve tried harder to kill [the last-gen] version of the game”, said Aaryn Flynn. In the end the next-gen consoles sold very well and only 10% of DAI sales were on last-gen.
“A lot of what we do is well-intentioned fakery,” said Patrick Weekes, pointing to a late quest called “Here Lies The Abyss”. “When you assault the fortress, you have a big cut scene that has a lot of Inquisition soldiers and a lot of Grey Wardens on the walls. And then anyone paying attention or looking for it as you’re fighting through the fortress will go, ‘Wow, I’m only actually fighting three to four guys at a time.’ Because in order for that to work [on old gen], you couldn’t have too many different character types on screen.”
Parts of DAI were still way behind schedule because it was so big and complex, and because some tools hadn’t started functioning until late on. Some basic features weren’t able to be implemented til the last minute (they were 8 months from ship before they could get all party members in the squad. At one point PW was playtesting to check if Iron Bull’s banter was firing, and realized there was no way to even recruit IB) and some flaws couldn’t be identified til the last few months. Trying to determine flow and pacing was rough.
They couldn’t disappoint fans again. They needed to take the time to revise and polish every aspect of DAI. “I think DAI is a direct response to DA2,” said Cameron Lee. “DAI was bigger than it needed to be. It had everything but the kitchen sink in it, to the point that we went too far... I think that having to deal with DA2 and the negative feedback we got on some parts of that was driving the team to want to put everything in and try to address every little problem or perceived problem.”
At this point they had 2 options: settle for an incomplete game, which would disappoint fans especially post-DA2, or crunch. They opted to crunch. It was the worst period of extended overtime in DAI’s development yet and was really rough: late nights, weekends, lost family time, 12-14 hour days, stress, mental health impacts.
During 2014′s crunch, they finally finished off features they wished they’d nailed down in year 1. They completed the Power (influence) system and added side quests, hidden treasures and puzzles. Things that weren’t working like destructible environments were promptly removed. The writers rewrote the prologue at least 6 times, but didn’t have enough time to pay such attention to the ending. Just a few months before launch pivotal features like jumping were added.
By summer BW had bumped back release by another 6 weeks for polish. DAI had about 99,000 bugs in it (qualitative and quantitative; things like “I was bored here” are a bug). “The number of bugs on an open-world game, I’ve never seen anything like it. But they’re all so easy to fix, so keep filing these bugs and we’ll keep fixing them.” For BW it was harder to discover them, and the QA team had to do creative experimentation and spend endless late nights testing things. PW would take builds home to let their 9 year old son play around. Their son was obsessed with mounting and dismounting the horse and accidentally discovered a bug where if you dismounted in the wrong place, all your companions’ gear would vanish. “It was because my son liked the horse so much more than anyone else ever had or will ever like the horse.”
MD had a knack for prioritizing which bugs should be fixed, like the one where you could get to inaccessible areas by jumping on Varric’s head. “Muscle memory is incredibly influential at this point. Through the hellfire which is game development, we’re forged into a unit, in that we know what everyone’s thinking and we understand everyone’s expectations.”
At launch they still didn’t have all their tools working, they only had their tools working enough.
DAI became the best-selling DA game, beating EA’s sales expectations in just a few weeks. If you look closely you can see the lingering remnants of its chaotic development, like the “garbage quests” in the Hinterlands. Some players didn’t realize they could leave the area and others got caught in a “weird, compulsive gratification loop”. Internet commentators rushed to blame “those damn lazy devs” but really, these were the natural consequences of DAI’s struggles. Maybe things would have been different if they’d miraculously received another year of dev time, or if they’d had years before starting development to build FB’s tools first.
“The challenge of the Hinterlands and what it represented to the opening 10 hours of DAI is exactly the struggle of learning to build open-world gameplay and mechanisms when you are a linear narrative story studio,” said Aaryn Flynn.
“DA2 was the product of a remarkable time-line challenge,” said Mike Laidlaw, “DAI was the product of a remarkable technical challenge. But it had enough time to cook, and as a result it was a much better game.”
Read the chapter for full details of course!
#dragon age#bioware#video games#SW:TOR#mass effect#I've seen plenty of this info discussed in articles/thinkpieces and on online communities over the years#but it's nice to read it first hand#some very insightful stuff here#these behind the scenes looks are very valuble#a lot of DAI's elements make sense given the context and what was going on in the background and the tech challenges they faced etc#be kind and respectful to devs folks they're human beings#also in general this book is really interesting and easy to read#funny in places too#it has lots of other chapters on lots of other games including Stardew Valley#I def recc buying it#anyway hope this post is useful/interesting to someone!#oh and as always support good treatment of game devs#crunch culture in the industry is harmful and exploitative
240 notes
·
View notes
Text
The 100: 7x09 The Flock
And finally, the end of my and @jeanie205‘s little rewatch, and the last review I still have to post before the show’s return. And for once, I can write a shorter review than usual, because this episode isn’t all that interesting. It’s my least favorite episode at least since mid-season 5.
I have liked season 7 more than most people seem to - even though I miss Bellamy and want to see more focus on Clarke, and I’ve mostly been patient about waiting for the story to really kick into gear. I understand that BTS issues have affected the season and caused a lot of rewrites, that the first half of the season was mostly setup or it focused on developing stories for other characters (and I have enjoyed many of them, especially for Octavia, Murphy, Emori, Diyoza and Indra).
But the pacing hasn’t been the greatest, and that particularly became obvious with this episode. There was no reason to stall the action and go back and waste this entire episode on flashbacks to the 3 months that Echo, Hope, Octavia and Diyoza spent training to become Disciples. Some of this could have been included in 7x07, and this episode could have featured maybe 5-10 minutes of flashbacks and then returned to the present day action, instead of leaving Clarke, Raven, Miller, Jordan and Niylah in that same Stone Room where they have been for 3 (soon to be 4) episodes, and completely leaving them out of this episode.
I’m not even speaking from the perspective of a Clarke fan here - I enjoyed the Skyring storyline in 7x02 and 7x04. But these extended flashbacks strike me as unnecessary and far more predictable than the writers seemed to think. It’s not like we needed to see why they agreed to join the Disciples - we know it, they had no choice and that was the best solution at the moment. Clarke may be wondering whose side they are on and if they have been brainwashed, but we know better. It was never a mystery for the viewers. And this episode’s Bardo scenes are no “1984″, we aren’t wondering “oh no, are they really brainwashed?” There is little ambiguity - except maybe for Echo, the only one we could maybe wonder about “is she really going to be loyal to the Disciples now?” - but even that isn’t because she seems to have drunk the Kool-Aid, but because she may just think there isn’t anything better to do and no one else to follow. And that is probably not what’s going on, though it would probably be more interesting than the more probable and predictable plot about Echo pretending to be loyal to the Disciples while planning revenge on them.
Maybe it would be different if this episode had the Disciples deliver some important new info that would convince both the characters and the viewers that the “last war” is really something worth fighting. But the show keeps withholding information about what these concepts are - who is the Last War to be fought against? What is transcendence? And no one seems to ask about it - or they do, but off-screen.
In the meantime, the Sanctum storyline reached its climax - Sheidheda revealing himself, killing a bunch of people and staking his claim to the throne, so to speak - but it’s a climax that pretty much everyone has been expecting since Sheidheda took over Russell’s body in the season premiere. What’s worse is that this was made to happen through an incredibly OOC action by Indra. And I don’t think many will miss the Faithful - an incredibly annoying bunch of minor characters. (They are, of course, some of the titular “flock”, together with the Disciples. We get it! It’s all about blind faith and worshiping false gods! The entire season has been hammering it home!)
The episode started well, with Anders taking HEDO to the surface of Bardo to show them the crystallized forms of the extinct Bardoans. I guess the giant aliens story was true after all. This made Octavia realize “Gabriel saved us” (so I guess they won’t be too angry at him when they see him again, which they haven’t so far), It was supposed to show what kind of threat the humans are facing in the last war. Except that was all the info we got on that subject. No one asked: Who is the enemy? Where are they? When will they attack? Why do you need the Key to fight that war? Or, if they did, it was off-screen. (Surely they would have asked some questions during those 3 months?)
Instead, we get to hear more details about the Bardo society. They grow babies artificially, like Primes did with the other people in Sanctum. Not a huge surprise. They don’t want any family relationships, just like they don’t want any friendships or romantic relationships, no individual ties, except the worship of the Shepherd. We already knew that. We get it, they are ultra-collectivist. They want to get rid of emotions, etc.
We don’t know for sure how they feel about sex (if it is fully forbidden, or if it’s allowed if it’s supervised and people get approved sex partners they exchange on a regular basis, as in some dystopias) - so I’m not sure how they (would) feel about Octavia and Levitt getting it on, which was one of the few new developments in this episode (also easily predictable, especially after their tender face touching scene in 7x06). Echo mentions at one point that the Disciples are always watching them - so does that mean Anders also watched Octavia and Levitt having sex? Surely Anders must be aware of their relationship, or at least that Levitt is really into Octavia? I’ve always been open about my lack of enthusiasm for this romance, but I generally support the idea of Octavia getting a chance to enjoy herself with a nice hot guy who’s helpful.
But Anders even letting Levitt be involved in their training and testing, without controlling him, makes no sense, unless Anders is incredibly stupid. This has been my problem with this storyline all along. I’m never sure if Anders is really that stupid to trust Levitt, or if he has some kind of smart plan and has been using Levitt on purpose to get Octavia to join the Disciples. There has been speculation about whether Levitt himself is manipulating Octavia, and/or she is manipulating him - and a part of me would want some of that to be true: this relationship and this entire plot would be a lot more interesting if they were manipulating each other (while also liking each other), but I don’t think that’s the case. Levitt is probably exactly what he seems to be, and I don’t think the writing here is that smart. But I can at least hope that Anders is not a total idiot and that he’s figured out Levitt is helping Octavia, but decided to use him anyway.
Now, I did have a tiny flicker of hope that Levitt may be intended to be seen as a more ambiguous figure - when he was rating HEDO for “participation, stamina, strength and speed” (he rated Hope 1 for participation) - and Diyoza was suspicious of him and asked him: "You always have so many jobs?"
Another “are the Disciples really that stupid?” moment was when Levitt randomly told HEDO that they keep samples of the same Gem 9 that killed the native Bardoans, and that could kill everyone on Bardo. Why the heck would they be keeping it, let alone telling people about it? Does Levitt want HEDO to kill everyone on Bardo? I hope this is fake info and another test - but I fear this is just bad writing and a clumsy exposition to set up the Chekov’s Gun that our protagonists will be tempted to use.
We also learn Anders was Orlando's mentor, It’s weird that Hope mentions him as a way to try to get Anders upset (you’d think she would also be upset, since she made him think she was his friend and betrayed him). But Anders remain calm and cold, and Hope only gets upset when he mentions Dev.
If there is any ambiguity, it’s only with regard to Echo - she is probably just pretending, too, but there’s a tiny possibility that she really has decided to join them because she needs to be a soldier and have a war to fight and someone to follow. which has been established as her trait. And Echo does point out that the brainwashed Disciples children have it much better than she ever did with Azgeda. Hope throws that into her face here when she says “You just like someone to give you orders”. But that’s probably just a red herring.
The Disciples breed a limited number due to the limited resources, Why don’t they all instead just go to Sanctum, or Skyring?
The simulations were somewhat interesting, but it was pretty clear that Diyoza, Octavia and Echo were pretending to be able to kill Hope because they were threatened they would be sent to Skyring individually to die alone. Diyoza even straight up told Hope it’s what they need to do, and Echo noted “they are watching us all the time” before starting to talk about how the Disciples have convinced her to believe in their goal. Hope was acting like a child and was unable to pretend - because she is still inexperienced, she has spent most of her life on Skyring with just a few people. Now, I did gasp at first when I saw Echo killing Hope, and to be fair, I can see Echo killing Hope in real life, but Diyoza and Octavia killing Hope? Hell no.
The only thing that made me think a little bit was - is every detail in the fear simulations planned by the Disciples (probably Levitt) - or do their own minds fill in the blanks? In Echo's simulation, Hope told her "they took Bellamy from you" and called her out “I thought Bellamy meant something to you". If that was a product of Echo’s own mind, it’s a bit like Clarke calling herself out through Blodreina in her mindspace in season 6 - “I thought you cared about Bellamy” - which was the embodiment of her guilt. That would support the idea that Echo is not planning revenge, because why would she be calling herself out in her subconsciousness? But that’s a moot point if it’s all designed by Levitt.
Speaking of which, has Levitt seen Echo’s, Diyoza’s and Hope’s memories, and has he seen anything past Octavia’s season 3 memories? That has never been clear - the Disciples don’t know Clarke doesn’t still have the Flame, but they knew what Gabriel looked like (in 7x01), which they could have only learned from Octavia... and Octavia here says “You’ve seen me at my worst”, which seems to imply he saw her as Blodreina.
But while Echo may have wanted to save Hope from a worse fate when she sentenced her to 5 years on Skyring, that’s cold comfort since 5 years all alone would be terrible and drive anyone insane. (It did with Orlando.) Somehow I doubt Hope will get to be sent there - something will happen and she will probably be saved from that.
The highlight of this episode for me ended up being the mention of Etherea- because it confirms some of my theories and it’s a new planet we will be seeing soon and where Bellamy probably is.
On Sanctum, Emori is put in danger again, as Nikki’s hostage - and Murphy is worried and trying to save her. Which has been a recurring theme - it’s the only way to make people care about this plot. I doubt that many people care about the Faithful, a bunch of stupid a-holes who have so recently planned to burn their own children out of their misguided faith. I did feel a little tinge of sympathy for Jeremiah, the guy who keeps thanking Murphy for saving his son - because the guy is so clueless that he doesn’t seem to understand that he himself had the agency to decide what happens to his son. But this is probably why Madi’s friend is shown here with Madi (his name is Rex, according to the credits - he is the Sanctum boy who clearly doesn’t follow in his parents’ footsteps and invited the null boy from CoG to play soccer with him) - we need to see someone who will be hurt by what happens when Sheidheda kills these people. (The trailer shows Rex grieving one of the victims in the next episode.)(Trey, the “adjustor” who brainwashed Jordan and acted as the leader of the Faithful in earlier episodes, was not in this episode, so I’m afraid that a-hole is still around.)
But Murphy and Emori did have good moments in this episode. Both were very brave - Emori did not allow Nikki to use her to blackmail Murphy, and Murphy, this time, wasn’t just desperately worried about Emori’s life - but he offered his own life for hers. (He claimed to be the one responsible for Hatch’s death by saying it was his idea to use the prisoners - which is true; the part he left out is that it was Raven’s idea to lie to them.) This is huge - he has been willing to do a lot to save Emori, but has never offered to sacrifice himself for someone before, not even for her. The closest he had come to it before was telling her and Monty to leave him to save themselves in 5x13.
And Murphy's line to Jackson "I'm 150 pounds wet and you can’t fight to save your life” was one of the highlights of the episode.
Another development is that Indra and the others finally know that Clarke, Raven, Gaia, Miller and others are missing - but they still don’t seem to have any idea where they may be.
Sheidheda quoting Casablanca is one of the weirder moments of this season. I suppose he may have know about it from Becca or some of the other early Grounders.
Apart from being kind of boring, this episode’s biggest problem is what Indra does at the end. Of course Indra wants Sheidheda dead, but it would be a lot more in character if she killed him herself. She could have pulled a gun and shot him in the head the moment they had resolved the situation. She should be aware of what a good fighter Shady is, and that everyone in Sanctum sucks at fighting (especially when they’re not high on red toxin).
On rewatch, I realized that, while Knight (the Sangedakru who stans Shady) and another Grounder knelt immediately, Penn (who is Trikru) and another Grounder just stood there - so we’ll see how divided or not the Grounders will be about him in 7x10.
Rating: 4/10
20 notes
·
View notes
Note
Dearest Elly, allow me to identify myself as the thirsty anon who asked about slbp. I want to thank you for answering my ask so quickly and thoroughly. As suggested I went with Shingens route noting to put Saizo on my next list cause again, I am one thirsty virgin. Allow me to jus say that I was moments away from blowing my whole paycheck on pearls. All of it. I had to put the phone down, eat dinner with my mom, take a long cold shower, and ponder my life choices. (Part1)
(Part2) This hasn’t happened since mysme. Not because it was revolutionarily smutty but because I fell hard for Shingen and was hella frustrated that I could read his story in one sitting. Those bastards at voltage know damn well what they’re doing by creating games like these and yeah I can see why teasing smutty content would become a meme. I mean damn. I haven’t wanted to bang a fictional character this bad since Jihyun said “wait for me.”
(Part3final I swear)Anyways thanks for your recommendations and advice. I am now looking for a higher paying job to support my newfound obsession. And as always thank you so much for everything that you post with us. Might I mention again that it was your wonderful writing that made me want to try this game out in the first place. I wanted to know the characters and was hella curios about a Yukimura?
I’m so happy you’re enjoying it, Nonny! Welcome to hell…we have kinky njnjas! Really though, I don’t think there’s a bigger honour as a fic writer to hear your word vomit inspired people to check out the original work, so thank you so much.
In terms of pearls, there are a number of ways to get them for free, though it takes quite some time to do so:
Visit your allies at their castle! You can visit your allies whenever you want and leave messages etc, but it’s definitely worth doing at least once per day as the game gives you a limited number of attempts to claim gold, onigiri and sometimes even pearls.
Speaking of onigiri, make sure you use the tea garden, since you can exchange onigiri for in game items, including story passes, gold and...yes...pearls.
Speaking of gold, the castle lottery is a great way to farm pearls. You can play 10x in a row in exchange for 3000 gold, which doesn’t take too long to gather if you go training/trysting often enough. Bear in mind which events are on, though, since in story events you will need that gold to progress through the event. (The alternative is spending pearls, which goes against the object of the exercise lmao)
Events! More specifically Battle Events (which is the next event!! Yay!!). Battle events are awesome for farming pearls, since all you have to do is hand over the items you automatically collect for playing the game. Story events also have pearls, but you need to be top of your allies to get them, which as a beginner player won’t be so easy at first.
Sometimes the devs have log in events or reading campaigns, but not all of the time. The rest, though, are tried and tested and have saved me so much money, haha.
Also, if it’s smut you’re looking for, I honestly recommend trying Love 365 or Lovestruck on the app store. These are also Voltage apps, but are 17+ rated, compared to SLBP’s 12+. As I’m sure you can imagine, these stories are a good deal raunchier. Love 365 is a paid app, but all in all it isn’t too badly priced. I personally have the VIP pass and get three stories every month. Lovestruck comes from the American branch of Voltage and not only is it steamy and free to play, but it’s also a good deal more...progressive??...than a lot of otome apps. You have multiple POC and LGBTQ love interests (and many who fall into both categories).
Also holY shit Yukimura. I love him so much ;; He’s just so cute. He’s a peach.
I feel like if you enjoy V, you’ll probably like Kenshin. Everything fandom loves about V, like the eccentric, overly romantic artist with a soft heart who loathes himself and will die for those he loves, is true of Kenshin and his route.
I’ll shut up now dgdfgd, but yay for playing SLBP!
2 notes
·
View notes
Text
Welcome to the Jungle
Well, this is weird. We really don’t write things in the public sphere. I started working in Nintendo’s Treehouse in 2000, and the central rule of life was really simple: You never talked about anything outside the office, ever. You often went days without interacting with anyone beyond the windowless Treehouse vault you called home.
And, oh yeah, things would get weird.
And you were blissfully unaware of the masses awaiting Nintendo’s next game because their voices couldn’t reach you—the nascent online community was still muffled by the technological limitations of the age, and unless you had time to open hundreds of envelopes (which I actually did every month, back when I worked for Nintendo Power in the late 90s), you were completely shielded from feedback.
Things have changed in the intervening years. A lot. And while we’ve pulled back the curtain on more and more of the Treehouse over recent years, our day-to-day work on games is still as opaque as it was way back when. Some of that mystery will always need to remain, not only because so much of our work is on unannounced projects, but also because I believe that when it comes to games, it’s often more fun to wonder than to know. That said, we’re going to try to open up just a bit with this log.
Over the coming months and years, we’ll be adding a lot of voices to this spot, and we’ll be asking each of them to contextualize themselves within the greater group so you understand who’s doing the storytelling. For my part, I run the localization group at Nintendo of America, coordinating daily with our parent company in Japan and Nintendo of Europe to bring our games out in English, Latin American Spanish, Quebecois French, and sometimes Brazilian Portuguese. I started as a writer, though, and most of the time, I still think of myself as one—much to the chagrin of my writing staff, I’m sure.
The first game I ever worked on was Paper Mario for the Nintendo 64 system, and while I feel like I got way better at writing that series over the years, back then I had no idea what I was doing. Prep work consisted of flying to Japan to meet with the dev team for a week prior to really digging in—Intelligent Systems was working out of what looked to me like a storage closet in an outbuilding on Nintendo’s Kyoto campus, so Leslie Swan and I crammed ourselves onto folding chairs wedged between shelves full of anonymous, blinking tech and got to work.
In this case, “work” started with me playing the entire game, start to finish, in Japanese (which I didn’t understand) while the developers watched over my shoulder and made occasional noises of amusement when I screwed up. I was weaned on Nintendo games, so over several days I was able to muscle through without any help—this consisted of me talking to every single NPC in an area until I unwittingly triggered whatever flag would let me advance—and I’m sure it was an amazing anthropological study for the devs, who essentially got to watch a multi-day focus test of how well they’d designed their game for someone with no language skills. I still remember their gasps when I died mere moments from glory in the last battle (I had no idea what the hell to do when Bowser used the Star Rod to become invincible—a rudimentary knowledge of Japanese would have really helped then), and when I went back in and beat it on my second try, they were as happy as I was. Among other things, they could tell that I understood and loved the core concept of their game, and as such, I would treat it with care as I worked on it for our market.
That’s a microcosm of how we start with every game. Sometimes it begins years in advance, when we meet with dev teams to review artwork or game concepts, sometimes it begins when we see a near-finished Japanese product, but no matter when we get in the pool, the core tenet of our process remains unchanged—we need to first understand the game and the developer’s vision before we do anything else. Someone from the Treehouse is at HQ in Kyoto practically every three weeks, all year, every year, and every trip bears fruit. Our meetings range from the necessary business of schedules and sell-through numbers to the very personal business of character designs, the nature of fun, and life in general.
Back home, once the projects start, we talk with the development teams every day. In person, over e-mail, through IM, via video conference, on the phone…and increasingly, within the game’s text files themselves. Our translation teams translate each message verbatim, obviously—but they also populate the adjacent columns with developer notes, linguistic nuances that don’t exist in the raw translation, and running conversations with the rest of the localization staff across the world. It’s an exhausting, but immensely fulfilling job—we’ve worked closely with these development teams for the better part of two decades now, and the mutual respect forged by long familiarity is a crucial part of our ability to act as curators for their creations. You’ve got to remember that the vast majority of our group earned their gaming chops unconsciously idolizing the people we now work with, and helping these developers reach the rest of the world is an honor to which we devote ourselves to every day. My earnest hope is that this space will become another window that allows us to shed even more light on their great work.
—Nate B.
389 notes
·
View notes
Text
DD2000 - Research Blog
I believe story’s are a kind of ‘intellectual tennis’ between the writer and its reader. There are unwritten laws that bind the two through respect and honesty.
Key Designers
Kotaro Uchikoshi: Spike Chunsoft. My top choice out of the key designers is Zero Escape Scenario writer, Kotaro Uchikoshi.
Ken Levine: Ghost Story Games (Irrational). Previously worked on the Bioshock series, recently revealed his new studio Ghost Story.
Zoe Quinn: Independent. Activist, artist and award-winning developer.
The Polygon You tube series Devs Make Mario takes various game designers from both AAA and Indie studios to create a playable level in Super Mario Maker. I viewed the ticked videos below due to the variety in these designers skills. It was interesting to see these designers incorporate visual, story or platform philosophies from their own games into the Mario ‘engine’. WayForward Designer James Montagna incorporated the behaviors of the enemies into a puzzle themed level rather than an obstacle. Zero Escape Scenario Writer Kotaro Uchikoshi included metaphors and shortcuts to players to make them think about putting in difficulty for themselves to ‘feel’ reward.
Job Prospects
As a writer usually you would be working with a ‘narrative team’ during the pre-production stages of development. It is the writers responsibility to be able to adapt the narrative, story and quests around the established game and perhaps even art style and tone.
Narrative Designer; How will the story will be told Voice Actor; who would voice your character, personality Environment Artist; create a visualisation of the world Animator; personality, ability and costume Character Artist; visualise character development, condition and animations Quest Designer; how will the game combine the story and characters with reason Mechanic Designer; along with quest designs, what would the characters do/want
In my opinion I see a ‘designer’ as a problem solver whilst a writer as a problem creator. During the development stages the writer does not have free range to create any scenario as they wish as they need to communicate and understand within a team the goals and limitations of the other members. The game must stay consistent through mechanics, flavor text, and style in order to create a coherent and complete game.
Writers don’t just write they piece together dialogue, world, story and characters.
The Importance of Engaging Portfolios
This May I will have finished my second year of the Game Design course, in the first weeks of Summer I have planed to re-work on my first two years of work to a polished condition ready for a portfolio and website which will also be created online using the Weebly tool.
In this portfolio I will go back over my work addressing end of year feedback and critique after allowing to work on other projects, given that I won’t return to university until September I have the opportunity to prepare for the graduation show in June.
After amending my work I will begin a brand new project with Art and Sound students from the other courses at Futureworks. We are hoping to create a demo for a first-person psychedelic/procedurally generated horror game that pushes body and mind-bending horror rather than supernatural and cliche horror tropes seen in low-budget survival games.
Using my website as a finished portfolio and my tumblr as a development blog I can utilise these websites to present my work professionally and informal when necessary.
After the course ends I hope to engage my portfolio with established industry professionals who appreciate and consider the need for a writer with a particular interest in styles of writing and the community.
Key Games - Writing
Virtue's Last Reward: Story Rich, Horror, Visual novel. This game tells the story of nine people imprisoned in a unknown facility and forced to partake in the mysterious experiment; Nonary Game. In particular the game blurs the line between a linear and non-linear story through the use of a mechanic which almost breaks the forth-wall and questions the medium of video-games and illusion of choice.
Bioshock: Deco, First Person Shooter. Built around the fiction and philosophy of Ayn Rand (partial anagram of antagonist Andrew Ryan) and the ideas of utopia/dis-topia societies by George Orwell.
Bioshock is a fascinating game that adapts the mechanics of body modifications into the deeper narrative of perfectionism and greed that runs throughout the combat systems and personality of the enemies in the game; splicers.
Sara is Missing: Found footage style horror mobile game. Developed By Kaigan Games, S.I.M gives players the opportunity to test their voyeuristic pleasures of going through a private personal item of a girl who has gone missing. The re-created Android UI is the extra step of polish to push the immoral feeling of snooping but for a justifiable cause. The relationship between the player and the phone’s AI is interesting as this also questions how players ‘progress’ and what is the point of that ‘progress...
Emily is away: Romance novel. Created by Kyle Seeley. In this game the player is given the option to choose a profile on a AOL like messenger client on Windows XP and begin a non-functioning relationship with a girl called Emily. I particularly like the building of the relationship throughout the course of 4 years in game, the romance between the two never quite kick-off and that creates an interesting but awkward dynamic by the end.
Physical Skills
In order to implement my work into games I must gather an understanding of the software and engines needed such as UE4′s Blueprinting system for dialogue, flavour text and onscreen information. Twine is another piece of software used for creating branched narratives with minimal visuals.
Over the summer I will be working with Art and Sound students. Together we will take the stories and characters that I have written and implement them into the visual and sound design whilst allow putting in world, dialogue and character text.
Further Research
Below I have added short descriptions for other mediums which I love for there unique story telling and satisfaction as a reader/writer. S.S. Van Dine goes into detail about the importance of justifying the set-up and clear rules for the reader so that they can agree with the choices and directions the author takes, in particular with mystery detective novels.
S.S. Van Dine: Mystery story’s are a kind of intellectual tennis between the writer and its reader. There are unwritten laws that bind the two through respect and honesty.
Inside No 9: Anthology + Dark Comedy. Secretive-like writing is used to ‘drip-feed’ information to the reader which keeps them questioning what/why events happen. Characters intent and values are hidden and hinted at throughout and because of the formatting and diversity in characters Inside No 9 keeps you wanting more.
Luther: Previously on my Tumblr I analysed through storyboard the first episode of British crime drama, Luther. I used Luther as an example of research due to the standalone crimes influencing the overall plot between the ‘protagonist/antagonist’ I use those terms loosely as the show depicts a more ‘grey’ morality dilemma, creating truer tension and risk.
Black Mirror: Charlie Brooker’s techno-paranoia series approach’s our use of technology not with blaming phones or advancements but the greed and fragility of the people who abuse them. It introduces almost reachable technology that questions it’s purpose, moral and vulnerabilities .
Get Out: 2017, Jordan Peele. Good, current and socially-aware film that shows a more intelligent side to the horror genre. An inter-racial couple (Chris and Rose) visit the parent’s of Rose’s parents. Chris is black and is anxious to meet them as he doesn’t know what to expect. I don’t want to spoil what happens due to the film only just coming out in cinema but what I can say is that the intelligence of Chris as a character feel’s on par with the viewer at all times and this positions us authentically in the film.
Rear Window: Is a Classic short-story inspired film by Alfred Hitchcock. Again as stated previously I do have an interest in the writer admitting to our voyeuristic ways. This film uses the camera especially to set up the audience into the perfect position to watch all of the characters. We begin to question the action’s of a particular character who could be a threat, but does the truth justice spying?
Fighting Fantasy: A multi-choice RPG book series created by Steve Jackson (Inspired VLR Writer) which I own. These book’s other replay ability and various choices through the luck of dice and combat in written form! Adventure stories like these use game-mechanics to tell various fantasy stories set in castles, mazes that involve arguements, wit and skill.
Dungeon World: With my friends over summer I plan to create a new style of story-telling through the format of the Dungeon World role-playing game. We have decided to configure the options and skill sets of characters into different periods and situations rather than high-fantasy battles.
4 notes
·
View notes
Text
8 of the Best SEO Project Management Tools
New Post has been published on https://britishdigitalmarketingnews.com/8-of-the-best-seo-project-management-tools/
8 of the Best SEO Project Management Tools
True story: My first job out of college was as a junior account executive at a local ad agency.
I managed anywhere from 7-10 clients at a time. From responding to client emails, ghostwriting email responses for my senior account executive, creating and pitching presentations, coordinating efforts between our teams, and the usual coffee runs, I did it all.
Can you guess how I kept this all organized?
A legal pad.
If these project management tools had existed in 2010, I may have spared myself hours of crying in the parking lot fist-pumping to gangster rap and daydreaming about how I’m going to quit my job.
But, how do you know which project management tool is best for managing SEO?
Lucky for you, I’ve got the inside scoop.
I’ve tested, failed, and succeeded with various project management tools.
So, thanks to a little help from my fellow Search Engine Journal writers and readers, here are eight essential project management tools for SEO.
The search ends now.
The 8 Best SEO Project Management Tools
1. Asana
With so many SEO project management tools on the market, how are you supposed to choose just one?
From Google Docs to Slack to Basecamp — heck, even Linkio manages your link building — there is a tool for just about everything.
Your choice of project management tool really depends on what tools you like to use and what you want to accomplish for your clients.
But what happens when you have zero budget?
Enter: Asana.
While Asana isn’t new, it’s completely free with unlimited tasks and to-do lists. Asana is my personal choice for managing SEO projects.
I don’t use Asana because I have to. I use it because I like to.
Features
By allowing users to create lists, set reminders, assign tasks to projects, manage due dates, including team members, and communicate via comments.
Asana is a great one-stop-shop for SEO teams looking to manage their workflow while adhering to deadlines.
Asana integrates with third-party tools, such as Google Drive or Dropbox, which makes integration seamless. Users can also refer back to previously completed tasks and easily adjust due dates while including the additional functionality of creating recurring reminders.
Managers can assign team members to specific projects to ensure that employees are only focused on tasks that pertain to them specifically, which ultimately allows for increased productivity and decreased confusion.
Cost
The Asana app and website is free to use.
The free version allows up to 15 users to create an unlimited number of tasks and projects while having a basic dashboard and search access.
For $6.25 per month, teams can have an unlimited number of users as well as advanced features like additional dashboard and search capabilities and more. For much larger organizations, there is an enterprise version as well.
Why It’s Good for SEO Pros
Asana can be a majorly awesome tool if you’re looking to better organize your processes. In either a large or small team, deadlines and details can get lost resulting in missed deadlines.
Asana’s user-friendly and streamlined approach will help teams to delegate the work, never miss a deadline, and disseminate the necessary support documents to the correct tasks and users.
Dawn Anderson, managing director at Move It Marketing, uses Asana with TeamWork, Basecamp, Trello, and TeamGantt, for multiple uses including, “Collaboration with team members. Timeframe. Scope management. Transparency. Working with client dev teams.”
.@dawnieando uses @Asana, @TeamWork @basecamp & @trello for her SEO project management. http://bit.ly/2stPrwu @sejournal
2. Basecamp
Having been around for over a decade, Basecamp is considered a reliable tool that excels at giving organizations a high-level view of their teams.
Like Asana, Basecamp can help monitor tracking, but also offers additional features like direct messaging chats, centralized document storage, and a scheduling tool.
Basecamp aims to take on Slack, Asana, Google Drive, and Dropbox by melding all of their competitors into one robust management tool.
Features
Designed with the harried business person in mind, Basecamp helps managers and team members stay on top of their professional lives. The app boasts that users will no longer drown in a sea of emails as that feature is already embedded into the app.
Additionally, the scheduling and tracking features help ensure teams never again miss a deadline.
Another interesting component of Basecamp is that managers can eliminate the need for “check-in” meetings by sending an automated message daily to employees that ask for a recap of what they accomplished that day. Then employees can “tag” teammates in their recaps to explain what they need help with or what they finished.
Cost
A unique feature of Basecamp is that the app doesn’t charge for an increase in the number of users or projects. So unlike some of its peers, Basecamp charges a flat-fixed fee of $99 a month for a team, no matter the size.
Why It’s Good for SEO Pros
Managing a client’s SEO consists of many different timelines and action items. Keeping track of client emails, meetings, and central documents is a full-time job.
By offering one of the best all-encompassing software solutions, Basecamp helps busy SEO pros stay on top of their entire business by more efficiently checking in with their team and deadlines in one easy to use the app.
Casie Gillette, senior director of digital marketing at KoMarketing, uses Basecamp mainly for communicating to clients.
“Basecamp is our primary means of communication with clients,” Gillette said. “For any deliverable, it allows an easy way to track the conversation and adjust docs accordingly.”
.@caseig shares how @KoMarketing uses @Basecamp for #SEO project management. http://bit.ly/2stPrwu @sejournal
3. Linkio
Only available since September 2017, Linkio is one of the latest SEO project management tools to hit the market.
This service helps to track link building tasks, which is a cornerstone activity for many SEO professionals.
By allowing users to plan, track, automate, and report on link building campaigns, teams can quickly use the software to help make a major impact.
Features
If you just can’t yet let go of the Google Sheets tracking methods, you will find it refreshing that Linkio doesn’t swear off all spreadsheets.
Instead, the software is linked to Google Sheets, allowing users to still use the technology they are already familiar with while removing some of the user error commonly associated with spreadsheet tracking.
Another benefit of Linkio is its ability to help team members increase productivity by helping them no matter what stage of the cycle they’re currently involved with.
Whether an employee is focused on anchor text planning, campaign setup, delivery management, or another task, Linkio has the ability to help manage no matter where in the process they are.
Cost
Although the app is new, and therefore fewer people can vouch for it, there is no real downside to giving it a try thanks to its affordable price.
Because the app is in its beta phase, it’s free and the company maintains there will always be a free version, even after its beta testing phase.
Why It’s Good for SEO Pros
As it is geared towards link building, the app was created with SEO professionals in mind.
By focusing on a specific aspect of SEO, Linkio was designed to help marketing professionals improve their management of all link building activities, no matter where in the search marketing cycle they occur.
4. Trello
Touted as one of the best collaborative project management tools, Trello helps users to better manage their SEO projects and teams one board at a time.
By making it easy to add tasks, due dates, team members, and comments, users can become more organized while still allowing for a high level of flexibility.
Plus, it won our #SEJSurveySays. Take a look:
Which project management tool do you use to manage #SEO? #SEJSurveySays
— SearchEngineJournal® (@sejournal) February 5, 2018
Features
One of the advantages of Trello is that teams can manage their workflow in an extremely visual way.
Groups can add “Trello Cards” to “Trello Boards” and easily assign team members, due dates, as well as attachments. The interface looks more like a bulletin board, which might be useful if you’re used to writing out tasks by hand.
Another key feature of Trello is the ability to follow a workflow from start to finish by easily advancing a card as it adapts throughout the process.
For example, content creators can benefit hugely by marking a piece of content as done for each step throughout each part of the content creation process.
As an article is written, it can be tracked as it advances from writing, editing, and posting in a visual way by moving the project card through its various stages of completion. You can see how Buffer uses Trello.
Cost
Like some of the previously mentioned apps, there is a free version which is capped at a 10MB limit when it comes to documents and uploads.
For small teams, this free version allows for unlimited boards. For $9.99 a month, Trello gives users an unlimited number of “power-ups,” the option to attach up to 250MB in files and more.
Why It’s Good for SEO Pros
Are you responsible for several different projects all for one customer? If so, the visual management of Trello makes it easy for to see where they are in terms of their progress. And, it’s great for managing your content strategy.
“We use Trello for managing our personal and team tasks, Basecamp for communicating with clients and Slack for communicating internally,” said Julia Shaffer, an SEO associate at Knucklepuck. “The three tools work well together to create an efficient work environment!”
.@juliabshaffer talks about how @KnucklepuckDC uses @Trello for #SEO project management. http://bit.ly/2stPrwu @sejournal
By easily moving Trello cards around, you can copy a similar task for a new project or show the project’s progression while keeping track of client notes.
5. Slack
Imagine, for a second, that a tool existed that allowed you to never have to check your work email – ever again. Would you use it? (Raises hand).
Slack is a communication platform that allows you to chat with other team members, clients, your mom, whoever! It’s an awesome SEO project management tool because Slack integrates with other project management tools like Asana and Trello.
My favorite part about Slack?
🤖 Slackbot.
Slackbot is like your own personal assistant. I can set reminders, create automated responses, and answer questions.
Features
Slackbot isn’t the only project management feature for Slack. With Slack, you can create separate channels to communicate to other marketers or chat with clients. And, many use Slack for community management.
You can also set reminders. Simply type /remind in a channel and Slackbot will send you a reminder at the day and time you specify.
For those of you who enjoy checking things off your list, Slack has a To Do bot that lets you keep your checklist within Slack.
Cost
Good things often come with price tags, but with Slack, it’s free for most businesses. But, if you want to upgrade, Slack offers an $8 per month and $15 per month plan based on your needs.
Why It’s Good for SEO Pros
No matter how much or little money you have to invest in SEO, Slack has helped businesses of all sizes keep their hard-earned cash because the majority of features are available with the free plan.
With Slack, you can create channels to communicate directly with your SEO clients so you can gain back that time you would spend in hour-long meetings and 10+ email threads.
“We use Slack for internal messaging among employees to quickly share links, graphics, and to schedule a meeting,” said Jack Nolan, Digital Marketing Strategist. “We use Flow for project management including project delegation and following up on tasks and processes. Slack and Flow are great because they stress communication, which is the most common hurdle in SEO project management.”
See how @jack_nolan uses @Slack for his #SEO project management http://bit.ly/2stPrwu @sejournal
6. Google Calendar
For most of us, Google Calendar is a necessary evil. Regardless of how much you use your calendar, having ongoing Google calendar date with your clients or bossman is an inevitable part of the marketing game.
If you fall in the anti-Google Calendar camp, there’s always Microsoft Office 365 that offer similar features.
Features
Investing in the right calendar tool can bring your SEO work to life for a client that might not be SEO savvy. It’s a necessity; missing a meeting or deadline doesn’t boast well for client relations.
Many SEO pros prefer Google Calendar because it allows them to give each project its own calendar and name. For example, I use a format “2018-02 Monthly SEO Pow Wow” so my clients can quickly scan their calendar and know that it’s time for our monthly check-in.
Google Calendar also has some pretty awesome sharing functionalities. As part of my onboarding process, I typically ask my clients to share their work calendar with me so I can easily book meetings if needed.
One of my favorite features with Google Calendar is the ability to use hashtags. With hashtags, I can search my calendar database for time/date stamps and export as a PDF.
Cost
The easy-to-use Google Calendar costs absolutely nothing, making them perfect for SEO agencies on a budget.
Why It’s Good for SEO Pros
Half the battle of organizing your SEO projects is finding the right tool for scheduling meetings with clients, reminders, and managing the project schedule.
Sure, I could keep using an excel document, but haphazardly handling deadlines and expectations is no way to keep a client coming back. Instead, I use Google Calendar to get my SEO jobs done.
And, it works great as a marketing calendar.
The majority of my clients use Google Calendar and plus, it integrates nicely with my Asana tasks.
7. TeamWork
Chances are you’ve probably already done a free trial of some of the tools listed above.
But, you’re still reading this for a reason. You want to find The One. Your SEO project management soulmate. The tool you could commit to for life.
And, for me, TeamWork is the one and only project management tool I recommend for SEO agencies. It’s my ride-or-die choice.
Features
Because agencies are going to need flexibility with the number of users, TeamWork allows you to have an unlimited amount of users and multiple people on one task.
The ability to have more than one person on one task is a downfall of my first place, Asana.
TeamWork also integrates with Google Drive, OneDrive Box, and Dropbox for file storage. And, it works well with your accounting software like Harvest, Freshbooks, and Xero, which makes invoicing clients much easier.
The best feature about TeamWork? Repeating tasks.
And, I’m not the only one who uses TeamWork that way.
“Primarily for assigning tasks to both myself as well as key stakeholders and to organize campaign activities and assets,” said Marc Nashaat. “I use milestones to denote high-level initiatives and create associated task lists that detail more granular components of those initiatives. The task lists are also useful for repetitive efforts and on-boarding activities.”
For SEO agencies I’ve worked for in the past, I’ve helped set-up templates within in TeamWork that can be repeated for specific SEO projects.
For example, if you’re writing a blog post that is targeting a featured snippet, you can create subtasks within that blog post for steps you need to take to achieve that coveted position zero.
These templates can be cloned for new clients.
Cost
Affordable with competitive integrations, this TeamWork also wields the power of the free plan.
From 100MB file space with 5 users and 2 active projects, this free plan should be enough for you.
When you’re ready to spread your wings, TeamWork offers a paid plan for $9 a month. This plan comes jam-packed with 100GM of file space, up to 100 users, and unlimited projects making it affordable for most SEO agencies.
Why It’s Good for SEO Pros
At some point, if you’re a baller, your SEO agency is going to outgrow the limitations of an Asana or Basecamp. And, if you’re a remote SEO agency, you need to make sure your project management tools are on point.
Kyle Faber, an SEO consultant in Milwaukee, uses Teamwork mostly for team collaboration.
“Audits, reporting, task management, collaboration. All play different roles in getting things done,” he said. “Teamwork is great for collaboration and communication. Trekking helps keep boards, cards, and tasks organized (teamwork has this also, but isn’t as smooth, IMO), and sheets help keep our data and needs organized beyond how task management works. We also use Google Docs as well.”
See how @regal_kyle uses @TeamWork for his #SEO project management http://bit.ly/2stPrwu @sejournal
TeamWork not only provides a better solution for your employees but for your clients.
8. Google Docs
Working on your SEO projects in Google Docs is the easiest way to to make yourself feel like an Excel genius with knowledge of pivot tables and formulas without actually having to know how to do them.
Easy-to-use interface and shared cheat sheets from other SEO pros, make Google Docs a go-to for project planning. (Tell me you miss those days of the #DIV/0! error and I’ll beat Takeru Kobayashi’s hot dog eating contest numbers.)
Features
With Google Docs, you can do a site audit like Annie Cushing, create an agile SEO project like Distilled, or do some long-tail keyword research like Mitch Monsen.
But, I have to say one of the best features of Google Docs is the Add-Ons.
The Add-Ons allows you to automate the SEO reporting and research process.
For example, Search Analytics for Sheets is my most commonly used tool in Google Docs. It’s a Chrome extension that pulls data from Google Search Console directly into your sheet. So, no more CVS file downloads or manual copy and pasting.
Cost
Surprise, it’s free! No gimmicks, no surprises. If you have a Gmail account, you already have access to Google Docs.
Why It’s Good for SEO Pros
Between the cloud collaboration functionality and the SEO-specific Add-Ons, it’s hard to find anyone who doesn’t use Google Docs.
“We use a super powerful, fully automated, custom Google Sheets tool for project management,” said Lucy Kirkness, director and head of SEO at Pandable. “We have a set of sheets which ‘talk to each other’ to manage all tasks, deliverables, action items, and hands off client campaign reporting. The Google Sheets PM tool also leverages Google Drive for client management, file storage, and reporting.
“Google Sheets is the best tool for our agency as it is fully customizable with endless options for integrating APIs and automation (unlike many project management software). We spend most of our time in Gmail, Gcal, or Gdrive, so this solution enables us to integrate all of our day-to-day processes and communication. Oh, and it’s free!”
See how @lucykirkness uses Google Docs for her #SEO project management @pandable http://bit.ly/2stPrwu @sejournal
Bonus: More SEO Project Management Tools
While I listed the majority of project management tools that I’ve worked with in the past for SEO projects, I did get a chance to connect with a few other SEO pros on their favorite project management tools.
Yoav Rheims, webmaster at TestPrep, is a big advocate for Microsoft Office 365.
“I am using these tools to plan reports, checking audits for some tests I made (A/B, technical, etc.),” Rheims said. “Also, love Office 365 for the one price to get enough tools for my team to work together and how easy it became to connect external tools to Microsoft’s own ones.”
And, Milos Dosen, regional manager at Dejan SEO, uses Freedcamp for his daily project management.
“We now use Freedcamp for task management,” Dosen said. “It gave us a solution to combine the flow we liked in Trello with the task set up that we love in Basecamp.”
I’ve never had experience with Freedcamp, but the tool does offer the same benefits of the other free tools list above.
In case you want to try something new, here are a few honorable mentions:
9. FreedCamp
10. Accelo
11. TeamGantt
12. Office 365
13. Airtable
14. ProofHub
15. Jira
So, What Are the Best SEO Project Management Tools?
If my legal pad was a $1 soft taco after a long work week, any of these project management tools is burrito and margarita on a three-day weekend.
Like a reset button for my daily routine, these project management tools make every second of working on my SEO clients tastier.
Is there a world of difference in each SEO project management tool? Not really.
Are they all efficient and easy-to-use to use leaving you more time to work on what really matters for your SEO clients? Definitely.
Keep in mind that all of these project management tools are not for everyone. While Asana, Basecamp, Linkio, and Trello offer different features, they all strive to make it just a little easier for an SEO marketer to do their job.
However, I’ve found the best SEO project management tools for me are a combination of Slack, Google Calendar, Google Docs, and Asana.
Whether you’re an experienced SEO or you’re new to the business, try out the above project management tools and see how it helps your business.
Source: https://www.searchenginejournal.com/seo-tools/project-management/
0 notes
Text
The Problem with Daybreak
Disclaimer: This was not written by me. However the writer wanted to remain anonymous.
“Most articles written on Everquest 2 (EQ2) are by people that havenʼt truly played the game to its fullest, donʼt understand the core concepts of the stat side of the game, or the math that goes behind & playerʼs decisions of what is best to use in each situation. How each situation is different and how absolutely amazing the combat feels when you know what youʼre doing. How each fight is a competition with other players to see whoʼs better. Who is the best. Different skills being tested, who prepared more, who knows more about the game. I think the way to best explain the annoyance with EQ2, is to explain what it used to be, and then what it is today. The understanding that games like this change over time is there, but what limiters do we set on these changes? How far can a company go from what you love before you no longer want to play? Everquest 2 went from a game with a bustling community to a veritable wasteland not suddenly, but gradually, over many years and many failures. A company struggling to stay afloat, introducing more and more tactics to pull every last penny out of the game as they can. It started slowly, increasing prices for expansion packs that gave less and less, pay to win policies on researching abilities, and now even the ability to, in all reality, buy upgraded stats. This sudden influx of stats to a minor few on top of an already inflated system has made competitive play between players nearly impossible. Unless you buy the upgrades too, you are not going to be on top. Players of similar skill level and same class, doubled, even tripled by the pay to win players that animosity towards them begins to burn with & true rage. Players quitting out of annoyance, out of the feeling that they simply donʼt make enough money to be competitive anymore. There are time-gated mechanics that donʼt allow those that will work more to get rewards sooner, to play the way they want to. “Play your way.” Absolutely not, the slogan has been not but a joke for years now. “Play the way we say or donʼt play at all.” Is how it seems to be now. The company h&s been releasing content that cannot be completed due to an increasing number of bugs, despite beta testers pointing out exactly what is wrong. Itʼs no longer a competitive field, instead it is -whoever plays first on patch day will be the ones in the lead. Communication between the player-base and the development team is seemingly at an all time high, but only if you donʼt have any criticism to offer. Constructive criticism is pushed aside like it was never said. An article on the game was able to have & conversation with Feldon, the man that ran EQ2Wire, a site for news - everything EQ2. He still maintains the EQ2u players site to this day, despite being banned from the forums and discord as well as no longer playing the game. Feldon was the one that introduced the EQ2 developers to discord. Feldon said in that interview, “The idea was that it would augment the forums, add to the community, and allow players and developers to come together and share feedback about the game. This is not what happened. With each developer granted admin access, it quickly became clear that any criticism, no matter how politely phrased, was means for removal. After the devs withdrew from the forums, the Discord channel, the main place for players to ask questions, an exclusive developer-run ‘clubʼ.” This, this is the true state of the game tod&y. A decaying cashcow to the company that owns it, and a bittersweet memory of what it once was to veteran players. Is there any road back to the game we all once so enjoyed?” For me, however, I think this is a symptom of a bigger problem with Daybreak Games. The first problem is that they’re a corporation. What’s worse is they’re a corporation that is owned by a billionaire type Jeffery Epstein. What is the general nature of a corporation but to grow? I had gone through job reviews of the company. It appears that the management can be extremely erratic [1] and they had suffered extreme layoffs after Epstein’s acquisition.[2] As it were, it isn’t difficult to see what is going on. They’re putting all their eggs in a single basket. Its probably very easy to see the stagnation surrounding the MMO market [3]. Even World of Warcraft seems to be fading. And with the advent of PUBG and Fortnite, Daybreak realizes that their older IP: H1Z1 is the goose. Problem is… they neglect the rest. But, they can’t just abandon their other IPs. But those IPs have to turn a profit. And therein lies the Pay2Win. Funny that MatPat through out that point but who’d have thought it’d be put into practice on something that originally scaled far above Runescape, Maplestory and other MMOs. I’m sorry to say that there’s no room in Daybreak for ambitious projects. FACT CHECK: I do want to point out that Daybreak is by no means in dire straights. Last I checked, they were worth 32 billion dollars with a modest profit. I tried to find the current margins but I was thus far unable to. If anyone is able to do so, please comment with the link and I will amend this post accordingly.
1 https://www.glassdoor.com/Overview/Working-at-Daybreak-Game-Company-EI_IE973097.11,32.htm 2 http://www.playstationlifestyle.net/2015/02/11/daybreak-game-company-suffers-layoffs-san-diego-austin-studios/ 3 https://massivelyop.com/2017/10/01/global-chat-whats-going-on-with-daybreak/
#MMORPG#mmo gaming#PC gaming#gaming journalism#Daybreak#Daybreak Gaming Company#Jeffery Epstein#Pay2win#Corporations#Economy#Capitalism#Business
0 notes
Text
MindNode 3 A Solid Update To A Strong Application
Dr. Travis Bradberry Author of # 1 successful publication, Psychological Cleverness 2.0, and also head of state of TalentSmart, globe's leading supplier from mental cleverness. That luxury doesn't exist in the company where all type of political concerns and plan barriers elevate their scalp at various opportunities to intentionally as well as unintentionally irritate also the best well meaning efforts. Brad Bushman, teacher from communication and also psychology at Ohio State University was actually co-author from the study, which said after the exam, That is very important to know the long-term original results of terrible video games, since a lot of youths regularly play these activities. MindNode Pro likewise enables you to develop numerous thoughts maps within a singular document.
Essentially enter the mind from Professor Phluff, a mad scientist with a dolphin head that's consumed along with helping make the world a cuter spot. Lots of systems likewise require that pupils have the standard Grad Report Assessment (GRE) and also some the GRE Psychological science test. A process concentration keeps your attention guided towards what must be done at the moment. I check out that the paid variation Gigaom Pro was actually meant to have additional extensive write-ups. The training course curriculum covers skill-sets in four classifications: Alpine Traveling as well as Mountaineering Abilities, Goal Hazards Examination and also Self-Rescue Capabilities, Leadership Skills, and Environmental management Abilities. Easing stress through hanging out in a Web café to participate in on the internet activities might seem to be safe to some. Similar to I am actually teaching Olympians in Rio, whether you are actually a top professional athlete, an age-group competitor, or even a weekend warrior, as you discover the craft this focused state from awareness, you could come to be entirely soaked up in your activity, to the omission from all various other outside impacts. Even at a meeting like Laid-back Connect, this method became incredibly successful: it took under a min for publishers, freelancers, as well as marketers passing by to come to be as well as watch the trailer involved. I often start these mind-maps days-- also weeks-- just before I need to perform anything concrete on the job. I make certain several do not mind cooking timers and also fixings and other imaginative means the devs have to develop to guarantee you spend loan. Arrange your job and also personal life in to the teams and also individuals that matter to you, as well as Groupedin will certainly perform the rest, making interacting in teams simple, reliable as well as exciting. If they are actually going to possess any kind of results at all, a writer has to have some understanding of inspiration. The cost of an online video visit with a psycho therapist is actually $50 for a 25 minute treatment and $95 for a FIFTY min session. As others have pointed out, having a level will definitely create that less complicated for you to obtain a project generally speaking, yet to actually be actually a psycho therapist you would certainly must head to grad university, as that is a highly-specialized field. My prayer therefore is actually that even more pastors would certainly find out about these dynamics from essential human psychology.http://csakegeszseg.info ='float:left;margin-right:10px;' src="http://3.bp.blogspot.com/-x7G2uU4rvZs/UVBLB6LxgFI/AAAAAAAAC7I/BsSM6tNX1Hc/s640/179021_483095791757821_1690694792_n.jpg" width="279" alt="become definition"/> OpenMind likewise allows you link a multitude from challenge just about anything in your mind chart, consisting of yet certainly not limited to Phrase, Excel, Pages, as well as Numbers papers, Flash documents, hypertext hyperlinks, and sound as well as video documents. When I carried out leave my neighborhood for a brief roadtrip, points acquired definitely exciting, and I found my degree climb and my chart come to be an insane one-legged spider. Smith additionally finds an action to providing involved enjoyment some sort of historic circumstance, as well as feels that this could possibly go some method to clarifying why retro video gaming has come to be therefore popular. Once again, neither of these researches specifically analyzed online mentorship, only on the internet education and learning. Korver states, Breakdown might be actually the best educator, however breakdown in early stage committing comes with a high cost." He realized the unfavorable impacts intellectual biases may carry selections and, after familiarizing the costly influence from predispositions, he generated a concrete process rather than relying on basic heuristic review. For starters, energetic social networkers-- determined in the 2011 National Company Integrities Study, a research study posted recently by the non-profit Ethics Resource Facility (ERC) as folks who spend much more than 30 percent of the day engaging on social media web sites-- are actually much more probably to see their current projects as short-lived. When the analysts after that followed these children via their childhood years or even right into young adulthood, they found that youngsters that acquired distressed during the course of the treatment were actually dramatically more probable to become reluctant, hesitant little ones-- and also there is actually even some evidence that they additionally possessed greater incidences of anxiousness later on in lifestyle.
0 notes
Link
The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
For years we developers had it drummed into our heads to never allow public scrutiny of a game until it was ready for prime time. The (warranted) fear is that negative previews can haunt a game long after it launches, no matter how good it becomes.
Livestreaming has a similar dictum - if you want to build an audience, play the best games, not buggy piles of cow flop. Most game livestreamers are fans of the products we develop. They want to livestream because they enjoy playing these games and want to share the fun with their friends. Why would anyone want to livestream an unfinished game, much less one that might be horribly broken?
We should want this thankless role. By we, I mean the ones making the game – the developers and testers who have to hunt down all those wonderful bugs about which people like to make snarky YouTube videos. After fans began livestreaming their games, developers followed suit, finding this an excellent way to build a community and spread the word. We also began finding other advantages to livestreaming.
One of the newest, and still least recognized, plusses to livestreaming is the role it can have in quality assurance. For those of you who don’t know, quality assurance is the fancy term for hunting down and squashing software bugs. Most developers and playtesters work in quiet environments, focusing on gameplay, creating hypotheses of what should and shouldn’t work, testing these hypotheses, and screaming in frustration when the game refuses to cooperate. Okay, we only rarely scream then. More often, we scramble to pick up pad and pen, jot down some notes, and begin detailing the bugs in our spiffy bug database.
1. Ease in ReCreating and Communicating Bugs
Only half of the job is done when a tester finds a bug. The second phase is communicating that bug to the people who have to fix it – artists, designers and the often-overworked programmer. Testers need to not only describe the bug, but also provide the fastest way to replicate it. The idea is to give the person assigned to fix the bug the fastest route to recreate it, not wasting her time or our company money.
The trouble is, by the time the tester has given the bug a name, assigned it a priority, noted who is responsible for the fix and begun describing it, she may well have forgotten what she was doing in the game to make it go kasplooey. Larger studios often record their playtests, tracking what the tester does on screen (and sometimes offscreen). Unfortunately, indie devs rarely have those resources.
When livestreaming a game, a key component for any streamer is talking through one’s actions and interacting with chat. When I livestream a playtest, I am constantly describing what I am doing. Thus when a bug jumps out of nowhere and scares me, I have a good sense of what brought it about. In addition, people watching in chat weigh in with their own thoughts on the bug. If neither of those works, the livestream has a recording that I can review to see if my description is accurate. If worst comes to worst, I can always pass on the recording to the person assigned the bug so she can recreate it after watching me flail.
I don’t think I’ll ever put away my pad of paper while testing, but livestreaming has made me a lot less reliant on hastily scrawled notes. It provides a series of tools that most indie devs cannot afford and would not have the time to implement if they could.
2. Find More Bugs
Even AAA games get released with typos, bad grammar, and poor writing that should have been easy to fix. Even though most text goes through editors before being incorporated into the game, playtesters are the last line of defense. The problem is, most playtesters are not editors. No developer can rely on them to catch the array of bad writing that can sneak in.
One of the fun things about livestreaming is that it is a common practice for streamers to read all the game text aloud as a way to keep the audience involved. Reading text aloud is a great way to catch typos, bad grammar and worse sentence constructs. It really improves a tester’s ability with the language.
And how many indie devs really have the money to pay an editor anyway?
3. Crowdsourcing QA
We may not be able to pay editors, but we can get our friends and fans to help for free. Most indie devs already do this, bugging anyone they can to play their game. However, unless you are testing a tutorial, your game is exceptionally user friendly, or you only test with fans of that genre, much playtest time gets lost just explaining how to play and what you want tested. By livestreaming, I get the viewers focused immediately on what I need tested. I raise questions and get free answers. Sometimes I just mess around with the game and get viewer input along the way, never knowing what topics might pop up.
Livestreaming will never replace getting other people to playtest your game on their machines. However, it is a useful tool whenever your ability to do so is limited.
4. Play the Game the Way They Want You Too
One of the worst parts of playtesting my own games is how often I play them the way I designed them to be played. I had a specific result in mind during design and production, and that is invariably the way the game works best. Unfortunately, that is NOT the way our players will play. They invariably take the game in directions I would never have considered. They try out actions that are obvious to them but mindbogglingly bizarre to me.
Holed up in my development lair, I can never think of all the things they do. Playtesting on a livestream, however, means I have an entire chat feed of interested parties looking over my shoulder, soundlessly giving me input. In the feed I see their comments, questions and suggestions. All of them should be noted (that is just good stream etiquette), answered, and sometimes even acted out.
Any insight I can get into the players’ mindset is valuable. They help break me free of my designer preconceptions. I have always believed developers should test everything they can, and audience feedback has opened whole new opportunities for just that.
5. Building Better Testers
There are lots of guides available on how to test games. Unfortunately, we cannot rely on our testers to have read any of them. In streaming, we control the parameters for our testers. This allows us to turn the stream into a master class on how we want our games tested.
I like the Scientific Method, encouraging testers to make hypotheses (for example, walls should stop avatar movement), test them (bump into walls or find those areas where collision detection has been poorly defined), and repeat (after rebooting following particularly nasty crashes where the avatar walks through a wall and falls through the Earth) … and repeat … and repeat …
On the stream, potential testers watch me discuss and demo this. Then, if I send them an alpha copy of the game to test, they know my preferred test style. No, I am not building an army of Mini Mes (not yet), but I do like to think I am improving my audience’s QA skill set.
To see one of our livestreamed playtests, go here: https://youtu.be/uIlEW2Wwe4A
To vote for our Greenlight, go here: http://ift.tt/2s7qxPe
This was originally posted at http://ift.tt/2ry7jp5
0 notes
Link
In Release 8.0 the sysinstall process had a major overhaul as well as the kernels USB handling. So this document assumes the reader will be using a 8.0 or newer system when trying things described here. To get everyone on the same page with terminology USB memory stick, flash drive, key, stick, and pen all mean the same thing. I will be using USB stick in this article. Flash Memory Technology: The memory chip, with the controller chip, is the most important element of a memory card. The memory chip is based on the flash memory technology which is solid-state, non-volatile and rewritable. Solid-State means it contains no moving parts and therefore is immune to mechanical failures and damages from movements and vibrations. It also operates completely silent with a zero decibel noise level. Non-Volatile flash memory stores bits of information in memory cells made of silicon wafers which do not require power to retain information when power is turned off. In general flash memory functions like RAM memory and a hard disk drive combined. It stores digital data in memory cells like the RAM memory, and stores information like a hard disk drive when the power is turned off. In comparison to other storage media flash memory offers superior features such small form factor, high degree of durability, high degree of reliability, low power consumption and high transfer speed. Based on that flash memory technology is ideal for use in USB sticks. The only disadvantage is the manufacturing cost, which is higher compared to hard disk drives, CDs and DVDs. There are two different technologies of flash memory, NOR and NAND. NAND flash memory is ideal for memory cards because is less expensive and can accommodate more storage capacity in the same die size. Memory card manufactures are using different NAND technologies for either boasting the memory cards performance or for decreasing the memory cards manufacturing costs. The most common flash memory technologies are the Single-Level Cell, Multi-Level Cell, Multi-Bit Cell and Chip Stacking. The Single-Level Cell technology is used to boast the memory cards performance while the rest are used for decreasing manufacturing costs. The most used technology of them all is the Multi-Level Cell. A Single-Level Cell, SLC, memory card stores one bit in each cell, leading to faster transfer speeds, lower power consumption and higher cell endurance. The only disadvantage of Single-Level Cell is the manufacturing cost per MB. Based on that, the SLC flash technology is used in high-performance memory cards. A Multi-Level Cell, MLC, memory card stores three or more bits in each cell. By storing more bits per cell, a Multi-Level Cell memory card will achieve slower transfer speeds, higher power consumption and lower cell endurance than a Single-Level Cell memory card. The advantage of Multi-Level Cell memory card is the lower manufacturing costs. The MLC flash technology is used mostly in standard memory cards. The Multi-Bit Cell, MBC, is a similar technology to the Multi-Level Cell but stores only two bits per cell. Chip stacking technology is used by many manufactures to double the memory cards capacity at considerable lower manufacturing costs. This is achieved by putting two chips together to form a single chip. For example, by stacking two 256 MB chips together they will form a single 512 MB chip. This technology is far less expensive alternative to the single-die chips or even called monolithic chips. USB sticks are most commonly manufactured using MLC (multi-level cell) or SLC (single-level cell) technology. MLC is a lot less expensive to manufacture, but is a lot slower than SLC. MLC have ‘write’ lifetimes in the 10,000 to 100,000 range. SLC is a bit more expensive, but is very fast, and has ‘write’ lifetimes in the 100,000-millions range. Which chip used in the manufacture of the USB stick is the most important thing that affects throughput and longevity. What really sucks, is how hard it is to find out which type of chips are used in the USB stick before purchasing it. Some USB sticks come packaged with the vendors website listed. Check out their website looking for email address for tech support or sales dept. Email them and ask what chip type is used in the model of USB stick you are interested in purchasing. Another point of interest is does your PC BIOS have option to boot from USB stick or even if the BIOS will recognize the USB stick media as bootable? This is a motherboard BIOS problem not un-common for PCs manufactured before 2008. Testing different vendor USB sticks on your PC maybe the only way to find one that will boot. Size as 2GB, 4GB, 8GB, what ever has no baring on this BIOS problem. Using a USB stick for storage only has never been a problem. Installing FreeBSD on a USB stick to create a bootable USB stick is a lot of work just to test if the USB stick is recognized by your PC BIOS. A quick way is to dd an floppy image to your USB stick and try booting that. Here are some commands that will help: Code: Download the floppy.img from http://www.daemonforums.org/attachment.php?attachmentid=300&d=1267845079 You may have to click the link a second time to get the save download box. Once you have it downloaded, rename it removing the .zip suffix. Another way to do the same thing. Use this windows image writer to write the bootable floppy.img file to the USB stick. You can download your own copy from: https://launchpad.net/win32-image-writer/+download The objective is to purchase a USB stick containing SLC (single-level chip) then you have no need to take special effort to limit writes like you would have to using a USB stick containing MLC (multi-level chip). The 6 Types of USB stick Installs. 1. Putting the disc1.iso on a USB stick so it can be used to install FreeBSD on a target in the same way it’s commonly done from the disc1.iso burned to CD. In this usage the USB stick using MLC or SLC makes no difference as after the original writes to population it, there are only reads from that point on. Assuming you don't have any SCSI disks occupying the dax device range or USB external hard drive your USB stick will show up on /dev/da0. The following fbsdiso2usb script will do this for you. Code: 2. With Release 8.0 an new USB stick livefs/sysinstall image is released. This memstick.img file is three times larger than the disc1.iso. It’s intended you dd this image to your USB stick. You can use it in fixit mode (it’s a complete running system) or in sysinstall mode. In this usage the USB stick using MLC or SLC makes no difference as after the original writes to population it, there are only reads from that point on. Assuming you don’t have any SCSI disks occupying the dax device range or USB external hard drive your USB stick will show up on /dev/da0. Use this command: Code: To write the memstick.img to your USB stick. 3. Installing FreeBSD on a USB stick containing SLC (single-level chip) from a CD burned from the disc1.iso results in a complete base release system which you can configure the way you like and install ports depending on the GB size of your USB stick. Assuming you don't have any SCSI disks occupying the dax device range or USB external hard drive your USB stick will show up on /dev/da0.
Last edited by a moderator: Sep 6, 2015 FreeBSD Install Guide www.a1poweruser.com fbsd1, Feb 27, 2010 #1 jhgorse, tevfik, Solaris and 1 other person thank for this.
dd if=/dev/da0 count=2 | od -c to display the USB stick MBR dd if=/dev/zero of=/dev/da0 count=2 to zero out the USB stick MBR dd if=/path/floppy.img of=/dev/da0 to write the floppy bootable image
#!/bin/sh # Purpose = Use to transfer the FreeBSD install disc1.iso files to # a bootable USB stick drive so it can be used to install from. # First fetch the FreeBSD 8.0-RELEASE-i386-disc1.iso to your # hard drive /usr. Then execute this script from the command line # fbsdiso2usb # NOTE: This script has to be run from root and your USB stick drive # has to be plugged in before running this script. echo ' ' echo '****** Prepare disc1.iso for usage' echo ' ' cd /usr mkdir dis mdconfig -a -f /usr/8.0-RELEASE-i386-disc1.iso md0 mount -v -t cd9660 /dev/md0 /usr/dis echo ' ' echo '****** Prepare target usb stick' echo ' ' dd if=/dev/zero of=/dev/da0 count=2 fdisk -vBI /dev/da0 bsdlabel -B -w da0s1 newfs -O 1 /dev/da0s1a mount -v /dev/da0s1a /mnt echo ' ' echo ' ' echo '****** Copy all the disc1.iso files onto the usb stick' cd /usr/dis find . -print -depth | cpio -dump /mnt echo ' ' echo 'Finished do clean up now' cd /usr umount -v /mnt umount -v /usr/dis mdconfig -d -u md0 rmdir dis echo ' ' echo ' ' echo "### Script finished ###"
dd if=8.0-RELEASE-i386-memstick.img of=/dev/da0 bs=10240
fbsd1 Active Member Messages: 213 Thanks Received: 47 Last edited by a moderator: Sep 6, 2015 FreeBSD Install Guide www.a1poweruser.com fbsd1, Feb 27, 2010 #2 MNIHKLOM and jhgorse thanked for this.
Everything you want to know about Installing FreeBSD on a USB stick (Chapter Two) Everything you want to know about Installing FreeBSD on a USB stick. (Chapter Two) 4. Installing FreeBSD on a USB stick containing SLC (single-level chip) from another USB stick created by method 1 or 2 above, results in a complete base release system which you can configure the way you like and install ports depending on the GB size of your USB stick. Assuming you don't have any SCSI disks occupying the dax device range or USB external hard drive. You do have a USB stick containing the sysinstall world and a USB stick desired to be the target both plugged in before booting. In sysinstall you have option to select the source of the install files and later on what is the device to be used as the target. The secret is you have to know which device points to the USB stick containing the sysinstall World and which device points to the target USB stick. Sysinstall will allow you to fdisk the device pointing to the USB stick containing the sysinstall world when you really want the target device. So be very careful and pay close attention to what device you tell sysinstall to use. One way to know them apart is for the target USB stick to be larger in size. That way in fdisk you will see the size shown on top of the screen. Another way is to only plug in the USB stick containing the sysinstall World and boot. It will be assigned /dev/da0. When you get to the sysinstall main menu. Plug in the target USB stick and choose the standard install/options item. Use the arrow keys to highlight the "re-scan devices (*)" item and hit the space bar to do the re-scan. The re-scan is so fast you will not notice anything. The target will be assigned /dev/da1. Now you should have no problems selecting the correct device of the source install files and later on for the device to be used as the target. Take note: Since the target is assigned da1 that will also be what is auto coded in the /etc/fstab file. After the sysinstall is complete and before rebooting you have to manually edit /etc/fstab file and change all references from da1 to da0. This can be done while the sysinstall main menu is showing. Hit the ALT key and the F4 key at the same time to open the shell console. Issue: ee /etc/fstab and make your changes. Then ALT key and the F1 key at the same time to return to the sysinstall main menu. Select exit and yes to reboot. Unplug the USB stick containing the sysinstall World and the reboot will boot your new target stick. If you try to boot the target USB stick without making the /etc/fstab changes, you will be in a world of hurt. The system will not boot because the target USB stick is now the only one plugged in and will be assigned da0 while it's fstab saying its da1. 5. The 'mfsBSD' USB install from http://mfsbsd.vx.sk/ This is a set of custom scripts that generates a bootable image (and/or ISO file), that creates a minimal installation of FreeBSD that is completely loaded into memory. Documentation on what is happening internally is missing. Documentation on how to use the scripts is present but without much details. This mfsBSD project is based on the ideas from the depenguinator project found here. http://www.daemonology.net/depenguinator/
fbsd1 Active Member Messages: 213 Thanks Received: 47
Everything you want to know about Installing FreeBSD on a USB stick (Chapter Three) Everything you want to know about Installing FreeBSD on a USB stick. (Chapter Three) 6. Custom install of FreeBSD on USB stick containing MLC (multi-level chip). Using this type of USB stick, effort is taken to minimize the amount of writes done to the USB stick while running the operating system from it. This same procedure can also be used on a USB stick containing SLC (single-level chip). Assuming you don't have any SCSI disks occupying the dax device range or USB external hard drive. The install source can come from the disc1.iso file or the source can be ftp downloaded. This custom install procedure uses GEOM disk labels so we don't care where the USB stick appears in the device tree. This custom install will be a (minimal install) just the basic running system, no doc, no man, no info, no root password, no nothing else. There are two ways to obtain the necessary source files. You can download the disc1.iso file, which gives you everything, or just ftp the base and kernel files, which is all that is needed for this minimal install. Both ways are explained. Obtaining the disc1.iso Here is the getnew.iso.release script that will download the sysinstall world disc1.iso. You can download this script from the end of this article. Code: Obtaining the release files using FTP. Here is how to use FTP to download only the base and kernel files needed. Put the follow code into /root/.netrc, that is DOTnetrc. You can download this netrc file from the end of this article. Code: Issue these commands on the user root console command line for the first execution and only the FTP command for all restarts. #cd /usr #mkdir dist #cd dist #ftp -v ftp2.jp.FreeBSD.org Executing ftp while in directory /usr/dist will result in ftp putting the downloaded files in that Directory. When accessing one of the FreeBSD FTP servers it is very common to get timed out before downloading of all the files is completed. The mreget command will cause FTP to check the local host for the file and only download it if it's missing from the local host or it's date or size is different. This way you can use the same .netrc for the first execution and to restart downloading files where your task was forced to end because the remote host timed you out. I am using the mirror ftp2.jp.FreeBSD.org site. I tried a few other mirror FTP sites and was timed out after 3 to 5 minutes. This mirror has very little traffic and I got 80% done before timing out. Only one restart was necessary to complete the download. Recommend you try different mirrors located near your geographical location until you find one with low traffic. FTP defaults to using extended passive mode. I could not get FTP to function through my ipfilter firewall until I forced FTP to use native passive mode by adding the "epsv4 off" which turns off extended passive mode. You can see the commented out statements in the .netrc file. These statements would download the complete release source. Basically the same stuff contained on the disc1.iso.
Last edited by a moderator: Sep 6, 2015 FreeBSD Install Guide www.a1poweruser.com fbsd1, Feb 27, 2010 #3 jhgorse thanks for this.
#! /bin/sh echo ' ' echo 'There is not enough disk space on the FBSD slice to hold the' echo 'disc1.iso-image of the new FBSD version.' echo 'cd /usr before starting this script' echo ' ' path="pub/FreeBSD/releases/i386/ISO-IMAGES" name="8.0/8.0-RELEASE-i386-disc1.iso" name2="8.0/CHECKSUM.MD5" fetch -avrpAFU ftp://ftp.FreeBSD.org/$path/$name fetch -avrpAFU ftp://ftp.FreeBSD.org/$path/$name2 echo ' ' echo ' ' echo 'Run these steps to verify download is good' echo 'ls -l to verify file sizes' echo 'md5 8.0-RELEASE-i386-disc1.iso >> CHECKSUM.MD5' echo ' to create value & append to end of file' echo 'ee CHECKSUM.MD5 last line = download value' echo 'check it to disc1 value in the CHECKSUM.MD5' echo 'if they do not match download again' echo ' ' echo 'Script completed.'
machine ftp2.jp.FreeBSD.org login anonymous password [email protected] macdef init prompt off cd /pub/FreeBSD/releases/i386/8.0-RELEASE epsv4 off #mreget ERRATA.HTM ERRATA.TXT HARDWARE.HTM HARDWARE.TXT README.HTM #mreget README.TXT RELNOTES.HTM RELNOTES.TXT cdrom.inf docbook.css #$ getdir base catpages dict doc games info kernels manpages ports proflibs src $ getdir base kernels quit macdef getdir ! mkdir $i mreget $i/*
fbsd1 Active Member Messages: 213 Thanks Received: 47
Everything you want to know about Installing FreeBSD on a USB stick (Chapter Four) Everything you want to know about Installing FreeBSD on a USB stick. (Chapter Four) Custom process description. You can download this as script fbsdinstall2usb from the end of this article. If using the disc.iso as install source do this: Make a mount point, put the disc1-iso into a memory disk and then mount it in cdrom format. Code: Plug the TARGET USB stick in. They come preformatted from the manufacture with a FAT32 partition on it. This command will destroy all existing data on the USB stick. Zero out the MBR: Code: Do fdisk with a new MBR. Code: The -B means “Reinitialize the boot code contained is sector 0 of the disk.” Default from /boot/mbr The -I means initialize sector 0 slice table for one slice covering the entire disk. You will get a message saying ‘Class not found’ disregard it. Label the USB stick: Code: The -B means bootstrap code will be read from the file /boot/boot and written to the disk. The -w means write a standard label. Allocate the file system. In order to reduce the number of writes to the USB stick, and as common practice, use the -U flag to enable soft updates. Additionally, so that we can find the filesystem easily no matter where the USB stick appears in the device tree, we will label the filesystem as FBSDonUSB: Code: Mount the USB stick: Code: Install the base files the same way sysinstall does by running the same script: Code: The following prompt is shown to you and you have to enter ‘y’: Code: Install the generic kernel: Code: Putting the base and the kernel on the USB stick does not create a fstab file. Create an /etc/fstab file on the USB stick. This one puts the logs on to memory storage (to minimize writes). We also null mount /var/tmp on /tmp, which makes it non-persistent: Code: Since we're using the UFS label to define the root filesystem, we must force the GEOM label class to be loaded early: Code: The vi edit program needs a /var/tmp/vi.recover file. Code: /var/log is now on memory disk. The newsyslog.conf files needs adjustment. All logs now have count of one, they rotate when their size fills 100KB. And the log file should be created if it does not already exit. Code: Set the interfaces to configure themselves over DHCP: Code: Turn off rebuilding locate database: Code: Set the command line prompt format for root Code: End do clean up. Code: All the scripts discussed can be downloaded from here All downloaded files have .zip suffix. Do not try to open, just do save. Remove the suffix to use.
Attached Files: Last edited by a moderator: Sep 6, 2015 FreeBSD Install Guide www.a1poweruser.com fbsd1, Feb 27, 2010 #4 MNIHKLOM, jhgorse, y2s82 and 1 other person thank for this.
# mkdir /dist # mdconfig -a -f /usr/8.0-RELEASE-i386-disc1.iso md0 # mount -t cd9660 /dev/md0 /dist
#dd if=/dev/zero of=/dev/da0 count=2
# fdisk -BI /dev/da0
# bsdlabel -B -w da0s1
# newfs -U -L FBSDonUSB /dev/da0s1a
# mount /dev/da0s1a /mnt
# cd /dist/8.0-RELEASE/base # This command if using the disc1.iso # cd /usr/dist/base # This command if using the Ftp source # env -iv DESTDIR=/mnt ./install.sh
You are about to extract the base distribution into /mnt - are you SURE you want to do this over your installed system (y/n)? y
# cd /8.0-RELEASE /kernels # This command if using the disc1.iso # cd /usr/dist/kernels # This command if using the Ftp source # env -iv DESTDIR=/mnt ./install.sh generic # rmdir /mnt/boot/kernel # mv /mnt/boot/GENERIC /mnt/boot/kernel
# cat >> /etc/fstab << EOF # Device Mountpoint FStype Options Dump Pass# /dev/ufs/FBSDonUSB / ufs rw,noatime 1 1 md /tmp mfs rw,-s16M,nosuid,noatime 0 0 md /var/run mfs rw,-s4M,nosuid,noatime 0 0 md /var/log mfs rw,-s16M,nosuid,noatime 0 0 /tmp /var/tmp nullfs rw 0 0 /dev/acd0 /cdrom cd9660 ro,noauto,nosuid 0 0 EOF
# cat >> /mnt/boot/loader.conf << EOF geom_label_load="YES" EOF
# mkdir -p /mnt/usr/local/etc/rc.d/ # cd /mnt/usr/local/etc/rc.d/ # cat >> mkvirecover << EOF #!/bin/sh # PROVIDE: mkvirecover # REQUIRE: mountcritremote # BEFORE: DAEMON virecover . /etc/rc.subr name="mkvirecover" stop_cmd=":" start_cmd="mkvirecover_start" mkvirecover_start() { [ -d /var/tmp/vi.recover ] || mkdir -m 1777 /var/tmp/vi.recover echo '.' } load_rc_config $name run_rc_command "$1" EOF # chmod 555 mkvirecover
# cat >> /etc/newsyslog.conf << EOF # logfilename mode count size when flags /var/log/all.log 600 1 100 * JC /var/log/amd.log 644 1 100 * JC /var/log/auth.log 600 1 100 * JC /var/log/console.log 600 1 100 * JC /var/log/cron 600 1 100 * JC /var/log/daily.log 640 1 100 * JNC /var/log/debug.log 600 1 100 * JC /var/log/kerberos.log 600 1 100 * JC /var/log/lpd-errs 644 1 100 * JC /var/log/maillog 640 1 100 * JC /var/log/messages 644 1 100 * JC /var/log/monthly.log 640 1 100 * JNC /var/log/security 600 1 100 * JC /var/log/sendmail.st 640 1 100 * BJC /var/log/weekly.log 640 1 100 * JNC /var/log/wtmp 644 1 10 * BC /var/log/xferlog 600 1 100 * JC EOF
# cat >> /etc/rc.conf << EOF ifconfig_DEFAULT="DHCP" EOF
# cat >> /etc/periodic.conf << EOF weekly_locate_enable="NO" weekly_whatis_enable="NO" EOF
#echo 'set prompt = "# %/ >"' >> /mnt/root/.cshrc
#cd /root #umount -v /mnt #umount –v /usr/dis #mdconfig –d –u md0 #rm –vrf /usr/dis
fbsdiso2usb.zip File size: 1.1 KB Views: 305
fbsdinstall2usb.zip File size: 5.3 KB Views: 273
getnew.iso.release.zip File size: 1.5 KB Views: 149
netrc.zip File size: 424 bytes Views: 143
DutchDaemon Administrator Staff Member Administrator Moderator Messages: 11,028 Thanks Received: 2,282 Freedom must be organized in order to persist. FreeBSD Resources: The FreeBSD Handbook | Manuals | FAQ | Wiki FreeBSD Forum Rules and Guidelines DutchDaemon, Feb 27, 2010 #5
[ one chapter per post, not one chapter per thread ]
yvonney New Member Messages: 13 Thanks Received: 0 yvonney, Mar 2, 2010 #6
Extremely kind and helpful. respect to all.
y2s82 Member Messages: 68 Thanks Received: 1 y2s82, Jan 9, 2011 #7
Hmm, from time to time, I get an error booting. It seems the USB stick doesn't get registered quickly enough and gives an error. As soon as the error comes up, I am notified that the da0 is probed and recognized. It works fine from there on once I type in ufs:/dev/ufs/FBSDonUSB, but that sort of defeats the purpose of fstab. So, what might resolve the issue? Is there a way to make sure the USB stick is recognized before the system try to make use of it?
wblock@ Administrator Staff Member Administrator Moderator Developer Messages: 13,816 Thanks Received: 3,446
Add a line to /boot/loader.conf : Code:
wblock@, Jan 9, 2011 #8 miggir and y2s82 thanked for this.
kern.cam.boot_delay=10000
Beastie Daemon Messages: 1,974 Thanks Received: 362
wblock said:
Add a line to /boot/loader.conf : Code:
Some people find that kern.cam.scsi_delay works if the above doesn't. I once tried both, but neither worked.
May the source be with you! Beastie, Jan 9, 2011 #9 y2s82 thanks for this.
kern.cam.boot_delay=10000
y2s82 Member Messages: 68 Thanks Received: 1
Just to ask a bit more questions, to create and setup a user, would it be possible to use pw like such? Code: Would I need to encrypt the *password*, or put it into a separate file and point it there? If so, how would I issue such command?
y2s82, Jan 14, 2011 #10
# setting root password pw -V /mnt/etc/ usermod root -h *password* # creating user *username* with the password *password* pw -V /mnt/etc/ useradd *username* -m -g wheel -h *password*
Carpetsmoker Daemon Messages: 1,004 Thanks Received: 172 UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. Carpetsmoker, Jan 17, 2011 #11
As a general comment / constructive criticism: Try to keep your howto shorter and more to the point. IMHO it is not the right place to go into detail about MLC vs SLC etc. If you really *do* want to keep this, make it a footnote or appendix rather than "inline". Try to write like a manpage: concise and to the point. In addition, maybe it's a good idea to add an index/table of contents? You can just use a piece of text, but if you really want to make it fancy you can use two special tags http://forums.freebsd.org/showthread.php?p=119592) In general, I find it very difficult to see if this post is useful to me or not — I already make bootable USB drives with FreeBSD, perhaps this post offers some new (better) method or some other trick... Right now I have to read the entire post from "cover to cover" ... Something that doesn't work well on the interwbz (“tl;drâ€). Just my 2 cents to get more people to actually use your howto ...">
von_Gaden Active Member Messages: 113 Thanks Received: 9
Thank you very much for this howto! I think extra details for SD cards are not unnecessary since you can't use effectively some device if you don't know how it works. If you know or don't care you can just skip the paragraph. I'm trying to use shorter method for mfs, in /etc/rc.conf Code: but neither pkg or freebsd-update work properly. pkg says that there is not enough space on /tmp, and freebsd-update denies to work because /var is not persistent filesystem. I can override /var problem by not using Code: but is there some more elegant way?
tmpmfs="yes" tmpsize="20m" varmfs="yes" varsize="32m"
varmfs="yes"
0 notes
Link
via thenewstack.io
The very idea of documentation often invokes yawns followed by images of old-school, top-down Waterfall project management. Documentation is often seen an albatross to an agile project management process built with rapid iterations, learning from customers, and pivoting.
Yet, particularly with the API space, the most important thing that developers are considering is the documentation.
But how can the all-important documentation be integrated into the agile world without slowing it down? I’ll share some wisdom from pro-documentation agilists that I spoke to in the process of writing “The State of API Documentation” white paper for the APIDays conference series, in order to help understand what’s holding us back and how to move forward with agile documentation.
For the sake of this article, we are focusing specifically on API documentation in an agile environment, but the lessons can be applied to just about any agile team.
Why Can’t Documentation Be a Part of Agile?
Some would say that this is the consequence of culture or perhaps of a lack of ownership.
“API design-first is inherently not agile. We design the whole thing and then throw the whole thing over [declaring] ‘Be the recipients of our wisdom’,” quipped Emmanuel Paraskakis, head of product development at APIary (currently being acquired by Oracle).
Even though DevOps are fighting to break down these silos, there’s no doubt that documentation, like testing, continues to be a hot potato thrown around IT departments. It’s not something that’s deemed fun and, despite all evidence to the contrary, it’s not something deemed important.
“In the end, if it’s done without control, we will have many many microservices that don’t speak the same language and it will cost a bunch of money.” — Arnaud Lauret, API Handyman
Andrew Davis, founder of tech writer agency SynergisTech, said, “The piece about it being ‘the number-one thing people want’ isn’t registering at most companies I serve. Not all of them are in the open-source space, where documentation truly sells the product, but most of my clients think about documentation too late and resist paying respectable rates when they find the rare combination of developer skills and technical writing talent.”
There’s no doubt that while time and time again documentation is lauded as a huge factor in decision-making, it’s brushed off as unimportant, particularly on agile teams.
One problem may be that, in most agile situations, project milestones have just been replaced by story point estimations, that still have devs and teams blocking off time limits, further restricting the development process in a way that then creates new excuses to pass on the documentation.
As Arnaud Lauret from API Handyman put it, “This is the good and bad side of agile autonomy.” You are faster, more efficient, and have a greater capability to meet customer expectations, “but, in the end, if it’s done without control, we will have many many microservices that don’t speak the same language and it will cost a bunch of money.”
Nonetheless, API documentation should fit perfectly in the agile world “because you have the ability to modify the thing that drives the whole process at almost every stage of development. And the modifications can affect in a controlled way all of the artifacts that are downstream of it,” said Tony Tam, creator of the Swagger’s API framework.
Tam explained that successful API documentation is “not a Waterfall process at all because it’s not a serial thing. The client, the documentation, and the server all happen in parallel in the design changes.”
As Davis alluded to, documentation is only seen as useful in some open source situations, where you want to cut down on preventable tech support calls. But certainly, as we give developers more independence to work with microservices, containers and other smaller pieces of code in varying languages, we have a greater demand for documentation on internal teams too.
In fact, since agile sees internal teams processing code so quickly, it might be even more important for them to document as they go.
As an API consultant, Rich Visotcky found that the documentation he needed to create for his clients in the construction industry would be substantial. There could be six or seven application teams plus two other service teams that had to consume it all.
“Updated, useful and concise documentation was very important for these teams to consume our services, especially as they changed sprint after sprint after sprint,” each of which lasted between two and three weeks, he said.
This meant they couldn’t just have a wiki or an API manual that needed constant updating, so they went ahead and worked to create an API that was as self-described as possible.
Like all things in the agile space, automation plays a crucial role in keeping documentation up to date.
Can Definition Languages Make Documentation Agile?
Or perhaps a better question is: Can API definition languages, such as Swagger, sell documentation to agilists?
“One of the things that we quickly realized we couldn’t do was create documentation that lived apart from our code. It had to live directly alongside our code or it’d be immediately out of date,” Visotcky said.
To accomplish this, he used a combination of XML comments that got generated by the actual method signature, a Visual Studio extension for documentation called GhostDocs, and then they used the XML documentation to generate Swagger API documentation, which he says kept the documentation and code intrinsically linked.
“Swagger was awesome,” he said. “That gave us some short blurbs that people could pull up on our website released internally.”
Paraskakis echoes this need for automation, adding that it gets the consumers involved early and often.
With APIary’s definition language API Blueprint “Not only are we going to involve you as a consumer, we’ll give you a live prototype in the form of a code server. You don’t have to wait for the sprint to be up or the release.”
Prototyping is, of course, a way to test things out in the agile development process without having to build too much in advance. In addition, this process allows for automatically driven tests, “so we assure this contract [between API provider and consumer] won’t be broken.”
Paraskakis continued, “A lot of people talk about the lifecycle where you create it, then the documentation, etcetera. Then we want to go back and do more things once we get feedback. Maybe it’s microservices, use cases or partner APIs, but you reach a point when you need a lot of APIs.”
That’s when Paraskakis advocates for a style guide, a lot of it expressed as a document. “You need to have tooling that takes the style guides, introspects it, and advises you at the point when you are straying from the style — not that prevents you from deviating but alerts you.”
“You also need integration with your version control system so you can manage changes, branching, pull requests, merging, especially when you bring in collaborators from the outside,” allowing them to make a suggestion in a different branch.
Uri Sarid, Chief Technology Officer of Mulesoft and co-creator of the RAML API description language, described agile as “the ability to go fast and then change.”
It’s for this that Spotify uses RAML for front-end and Mulesoft for backend integration. What’s the secret to the music giant’s agile success?
“If you want to go fast, you actually need to specify just the API — it’s about just tight enough coupling and to know what doesn’t change. APIs tell you exactly what you rely on. Good fences make good neighbors. The API economy has evolved on loose coupling.”
Sarid offered Docker as another example because they have a well-defined API that is very specific about what you can do with it.
“If you don’t do it, it doesn’t work. To be fast you need that exact contract. Because all containers on a freight ship are exactly same, they all need that contract.”
Basically, Sarid is putting up documentation as a very important part of that contract between API exposers and API consumers.
We never allow something to be shipped that hasn’t been documented, making sure the documentation iterates along the way as the product develops” –Romain Huet, Stripe.
“The more microservices you have, the more agility you need, the more important it is to define the contract so you know what won’t change and what will change.”
Netflix, famous for its so-called Chaos Engineering, actually uses automation and documentation to create harmony for its mostly internal APIs.
Sarid pointed to how their code embodies their APIs in both human and machine-readable terms. And when a bug has been discovered, it’s because someone had miscoded, showing a need for some more auto-generation.
No Excuses
There’s a strong argument for an internal or external tech writer to join the agile team and take charge of the API documentation. And yes that’s useful for curating it all. But perhaps it’s more important to have each developer be responsible to document her or his own piece, before allowing for its curation.
As long-time technical writer James Neiman argues, documentation efforts should be aligned with product release cycles.
“If you are embedded with a product and engineering team, in the agile environment, the definition of ‘Done’ is that the docs are updated. It can’t be Done without.”
Of course, this is harder when a project progresses. The Scrum Master or Product Owner needs to help the team outline an agreed upon definition of “Done” from the start, which should, just like testing, include documenting.
“What’s critical is to start documentation early on in the process and make sure it is continually updated,” said Romain Huet, from Stripe’s developer relations team. “We never allow something to be shipped that hasn’t been documented, making sure the documentation iterates along the way as the product develops.”
He went on to say that this is a really great way to see how the developer experience will look like before it’s even published because, even when you are interacting on shorter, more agile development cycles, you want to make sure that developer experience is paramount.”
Huet also reminds us that the easiest way to create simple documentation that’s kept up to date is by keeping your code simple. Stripe recently realized that when integrating the payment tool via Apple Pay, where they reduced down to a simple line of code. This isn’t new either. Stripe was created in 2010 around the simple principle that “It should be easy to set up and accept payments,” which is why the Stripe API enables this with only 14 lines of code.
By writing the documentation spec up front, you can be more agile by planning out the “ideal code” ahead, which in turn has us thinking about what the developers would like to write and, as Huet said, a delightful way for them to integrate.
On Visotcky’s agile team, they too found success when documentation was incorporated into the process.
“Whoever wrote the code updated our documentation. It was part of our definition of Done.” Visotcky went on to explain that “We checked it as the team. The person who was updating the API or updating the endpoints or changing the way it behaves probably had the most to update the documentation, but we checked it as a team to update the behavior of what’s actually going on in the API.”
In the end, Visotcky said they had two types of documentation, what he calls “collaborative” or what their customers were asking for and Swagger which was generated for their own use. They continued to write and maintain the docs for their own needs, constantly trying to minimize it all.
What matters is that you have API documentation, but, like all things agile, how you do it should be customized per customer, per product and per need.
Feature image via Pixabay.
The post Automation Is the Key for Agile API Documentation appeared first on The New Stack.
0 notes
Link
The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
Hi! My name is Coray Seifert, I’m the Director of Production here at Experiment 7. I’ve been working on VR games in various capacities for the past 4 years, first with Impeller Studios, then with Autodesk’s AR/VR Interactive Group, but most meaningfully with the fine folks here at Experiment 7. Over that time, I’ve made a number of horrific mistakes that haunt my dreams to this day. I’d like to share some of them with you!
If the beer is virtual, are the calories real?
Below you’ll find 7 lessons I learned working on VR strategy games at Experiment 7. I wanted to put this list together so others who are just getting into VR development can avoid some of the same challenges.
Why spend the time to share key learnings with potential competition? The bottom line for our corner of the industry is that the more teams there are making great VR games, the more consumers we’ll see adopting VR platforms, and the better the market will be for all of us. Just like how Tesla shares their best practices with their competition to help drive their industry forward, we hope that creating a marketplace of shared ideas will help the VR game creation space move forward as well.
In traditional game development, we have experiences, best practices, and cautionary tales that effectively guide our efforts. Platform migrations have happened in the past and we’ve tweaked our best practices accordingly. What works on PC might not work on console due to input differences, processing power or consumer expectations, so we modify our approach slightly to adapt for the new medium.
VR, on the other hand, is a complete paradigm shift. Not only do our best practices need to be refreshed, but some of the core tenants of what we believe about game development need to be unlearned. Moving the player’s first person camera may make them sick. 2D planes for VFX can be invalidated due to stereoscopic rendering. UI and UX design has to be completely rethought from the ground up. This is a complete phase shift from the old way of doing things.
That's no UI object...
I find myself annoyed by long-form lists where you have to scroll forever to see if the pillars of the article are worth investing your time in, so here are the 7 lessons, in brief:
Double down on engineering – More tech needs, less asset budget. Trade artists for engineers.
Make sure someone on your team has shipped something in VR – Ideally your tech lead.
Don’t skimp on preproduction – Prototype aggressively, define hardware/QA/pipelines first.
Respect the minspec – Pick your platforms, identify your minspec, and stick to it.
Realism is important, but comfort is king – Use realistic proportions, but framerate/comfort is priority.
Start small – Maintain vision, but start with a fraction of what you’re eventually trying to build.
Expect the unexpected – Prepare for rapidly evolving hardware, dev tools and marketplace.
If you just came for the pillars, I hope they’re helpful in your adventures. If you’re here for context, let’s dive into the details!
Let’s start at the beginning.
When you’re building your team for your VR project, you’ll want to staff heavier on the engineering side than you would for a traditional game project. Further, it's optimal to populate your team with a greater percentage of experienced developers than normal.
While more engineers doesn’t perfectly equate to increased velocity, the simple fact is that every problem you face will require new solutions, a risk that can be meaningfully mitigated with people power. Even if you’re using a proven commercial game engine, everything from feature development to optimization takes a long time on VR and involves a significant learning curve. These are new knots to untangle and for the most part, very few people across the industry have meaningful experience in VR.
Here’s how I would recommend adjusting your engineering team size:
>10 total headcount: 3x
11-50 total headcount: 2x
50+ total headcount: 1.5x
If you’re working with a fixed budget on your game, this may mean scaling down your art headcount, which isn’t great in and of itself. One mitigating factor is that stereoscopic rendering means you're basically rendering everything twice. A game of comparable scope simply has fewer pixels it can push through the renderer.
Accordingly, the content requirements for VR are lower than other platforms. If you think back to past generations of console games and the scope of art created for those games – both in terms of the raw asset density and in terms of the amount of polish per asset – you can get a good sense of where VR is in its current (2017) iteration.
In an ideal world, I recommend a small VR art team laden with senior artists who enjoy new technology challenges and plenty of technical artists who are passionate about the medium.
The good news on this front is that great engineers are frequently drawn to new technology problems, just as great artists can be drawn to new mediums of expression. You can harness that excitement to bring fantastic people into your organization.
It’s one thing to read about the technical limitations of VR or talk to someone who has shipped a game in VR, but don’t talk yourself into thinking you can make it without significant input from someone who released a commercial product on the platform. You need someone who has directly worked on solving the unique problems of the medium. It can be a freelancer, consultant, or advisor, but ideally that person is someone who is a core member of your team.
The best case is if this person works in the engineering vertical of your company, even more so if your VR expert is the head of your engineering team. This allows that person to translate those experiences working on the platform directly through their team, providing that intrinsic, internalized knowledge of VR-specific challenges to everyone working on the technology that drives your game.
Experiment 7 is lucky in that our Technical Director, Mario Grimani, has been working in VR since the days of duct tape and bailing wire. One of our engineers worked on open source VR solutions. I worked on some of the very early (and very rough around the eyeballs) VR prototypes internally at Autodesk. Those experiences – often in figuring out what doesn’t work on the platform – have been crucial to the success of our team, even more profoundly than in traditional game platform transitions, because of the transformative nature of VR.
Baby steps from the Autodesk days...
New tech is exciting and none more so than VR. Which is why it’s vitally important that you take the time during preproduction to plan, prototype and test. Don’t get too excited and run straight into the teeth of your project!
Stick to your phase gate plan. Build and iterate through your concept, look & feel, and early prototype in preproduction (which will take longer than you expect, especially for your first project). Getting a new asset pipeline for VR set up is no small task - do it early. If you wait until the production phase to finalize your content and feature workflow, you’ll spend your production cycle firefighting and redoing key systems, rather than delivering great features and content.
Make sure that you’re aggressively prototyping at every phase, even with proven mechanics. We made the decision to go with a relatively low-scope chess game for our first title, so we could easily integrate a Chess engine and use Unity store assets to test the concept of table games in VR early. That process, as rudimentary as it was, revealed tons of issues and opportunities in our core design and in our technology expectations. Issues that would have been hugely problematic (or significant missed opportunities) if we had left them to the end of the project.
"Okay, so imagine you've got a table...and it's magic..." - Geoff, probably
Finally, during preproduction, budget more time than you think for infrastructure. You can’t just buy a few machines and desks and be off to the races. Depending on the platforms you’re targeting, the various combinations of hardware and software can take significant time to track down, given the wide range of headsets currently in use (with new ones coming online every quarter). QA infrastructure can be especially difficult to get going on new VR projects given the specific physical device requirements at the scale of a full QA team.
In VR, more than any platform, framerate is more important than fidelity.
As you may or may not know, framerate in VR has an outsized impact on the overall experience. High framerates (90+ fps) lead to a smooth experience, while lower framerates can lead to a profound sense of discomfort and render your application unusable to a significant portion of your audience.
No matter how aggressively you scope for memory and processing power, content has a tendency to come in over budget – make sure your asset budget has lots of buffer room; more than you think you need. Things will get broken by new platforms that are dynamic and constantly evolving – make sure you’re accounting for this so that when something does break, it doesn’t completely nuke your game. Users will do horrible, horrible things to their hardware – make sure to account for your end users installing tons of CPU and memory-hogging applications on the target platform.
If you’re multi-platform, set goals based on your lowest possible performing platforms…and stick to them! This is a non-trivial task, as it requires business, technology, and creative buy-in. Push this to the top of the priority list.
Realistic proportions, movement, and physical relationships are critical to creating a VR experience that makes use of presence. Content that is out of scale with the world around it risks appearing "spooky" and unsettling, leading to subtle but meaningful feelings of cognitive dissonance in your users. Unrealistic or unfamiliar gravity, viscosity, or friction can have the same effect.
Door frames, windows, tables, chairs and other common real-world physical objects in game space are especially susceptible to this phenomenon. For games grounded in reality, there is a pretty simple solution. Measure things and stick to those sizes. This constraint can certainly be a limiting factor, but can also be a creative challenge that leads to dynamic and innovative solutions to problems both complex and mundane.
Preproduction proportions testing
During preproduction, try starting with realistic proportions and aggressively test with white-rooms to avoid having to rework assets down the road. Working from a regimented, realistic base of assets goes a long way towards making the user comfortable in your environment.
All that said, the one guiding principle for VR – especially in these relatively early days of mass market consumer VR – is that comfort is king. It’s imperative to ensure your experience is palatable to your target audience.
If you’re making a card game for a wide audience, make sure that your framerate is extremely high, your contrast is relatively low, and you’re never accelerating or moving the character outside of motion-tracked head and body movements. If you’re making a hardcore flight simulator with 6 degrees of freedom and non-stop flak explosions, you have a different bar to hit, but core tenants (always high framerates, try to never move the player’s camera unless they’re controlling it, use slower acceleration where appropriate, etc.) are always good to keep top of mind.
Be cognizant that with every increment you push your experience past your target comfort point, you’re losing and alienating another large cohort of users, potentially damaging your reputation and your brand.
Find a spark and build from that. There are so many unknowns in VR – especially right at this moment in time – that it requires an entirely new pipeline, process, and technology outlook to bring anything to market, let alone something of notable scope.
This is VR. You should dream big. However, the best advice I could give at this moment in time is to create a small chunk of that dream with your first VR release. Get that product to the market – to any market – and get into preproduction on your second title with everything you’ve learned. Use that experience to help your team execute more efficiently and at a vastly higher level than the first go round.
This is one thing we nailed at E7. We started off with a relatively small game in Magic Table Chess, moved on to something marginally bigger for our second game, with exponentially larger projects on the horizon. Each step along the way has enabled us to work faster, focus more on experiences than infrastructure, and push our quality bar higher and higher.
Starting to come together...
This is the agile mantra, but especially so for new, rapidly evolving platforms like VR. It might sound cliché, but the pain is real. These are incredibly dynamic software and hardware products that are constantly evolving in meaningful ways. Platform updates right before VC meetings, cables getting imperceptibly loose and taking someone offline for hours, system background processes triggering and running the game at one frame every other second are all real possibilities that many of you will encounter.
While there’s little you can do to truly mitigate for these challenges, knowing that something along the way will conspire to foul up your perfectly-planned software project can help you reduce the impact of these issues when they do happen.
In addition to unexpected critical fails, if you’re working with a commercial game engine or platform back end suite, plan to be rolling over to new versions far more frequently than on traditional platforms. The dynamic nature of these platforms means that new updates address critical issues and can introduce new version mismatches more frequently than stable technology platforms.
In Conclusion Making games in VR is awesome. I frequently find myself losing myself in our games when I should be doing work, just because the experiences are still so profoundly magical. VR is a new and massively exciting frontier. A stereoscopic wild west.
It all comes together
However, like the American wild west of old, it’s full of danger and adventure. Being cognizant of the perils of the medium can’t help you to avoid these challenges altogether, but hopefully it can help mitigate the impact of them when you hit them.
I’d love to hear similar experiences folks have had working on early projects in VR. Horror stories are always great, or if you disagree with anything I’ve said here I’ll keep an oculus out for comments posted to this article.
Yes, I just ended this 2500-word VR article with an eyeball pun.
This post originally appears on the Experiment 7 Blog.
Coray Seifert is the Director of Production for Experiment 7, a VR strategy game developer based in New York City and San Diego. For more than 15 years, Coray has developed games as a producer, game designer, and writer for organizations like Autodesk, THQ's Kaos Studios, and the US Department of Defense. A Lifetime Member of the International Game Developers Association, Coray was elected to the IGDA’s Board of directors in 2007 at the age of 27; the youngest board member in IGDA history.
0 notes
Link
The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
Hi! My name is Coray Seifert, I’m the Director of Production here at Experiment 7. I’ve been working on VR games in various capacities for the past 4 years, first with Impeller Studios, then with Autodesk’s AR/VR Interactive Group, but most meaningfully with the fine folks here at Experiment 7. Over that time, I’ve made a number of horrific mistakes that haunt my dreams to this day. I’d like to share some of them with you!
If the beer is virtual, are the calories real?
Below you’ll find 7 lessons I learned working on VR strategy games at Experiment 7. I wanted to put this list together so others who are just getting into VR development can avoid some of the same challenges.
Why spend the time to share key learnings with potential competition? The bottom line for our corner of the industry is that the more teams there are making great VR games, the more consumers we’ll see adopting VR platforms, and the better the market will be for all of us. Just like how Tesla shares their best practices with their competition to help drive their industry forward, we hope that creating a marketplace of shared ideas will help the VR game creation space move forward as well.
In traditional game development, we have experiences, best practices, and cautionary tales that effectively guide our efforts. Platform migrations have happened in the past and we’ve tweaked our best practices accordingly. What works on PC might not work on console due to input differences, processing power or consumer expectations, so we modify our approach slightly to adapt for the new medium.
VR, on the other hand, is a complete paradigm shift. Not only do our best practices need to be refreshed, but some of the core tenants of what we believe about game development need to be unlearned. Moving the player’s first person camera may make them sick. 2D planes for VFX can be invalidated due to stereoscopic rendering. UI and UX design has to be completely rethought from the ground up. This is a complete phase shift from the old way of doing things.
That's no UI object...
I find myself annoyed by long-form lists where you have to scroll forever to see if the pillars of the article are worth investing your time in, so here are the 7 lessons, in brief:
Double down on engineering – More tech needs, less asset budget. Trade artists for engineers.
Make sure someone on your team has shipped something in VR – Ideally your tech lead.
Don’t skimp on preproduction – Prototype aggressively, define hardware/QA/pipelines first.
Respect the minspec – Pick your platforms, identify your minspec, and stick to it.
Realism is important, but comfort is king – Use realistic proportions, but framerate/comfort is priority.
Start small – Maintain vision, but start with a fraction of what you’re eventually trying to build.
Expect the unexpected – Prepare for rapidly evolving hardware, dev tools and marketplace.
If you just came for the pillars, I hope they’re helpful in your adventures. If you’re here for context, let’s dive into the details!
Let’s start at the beginning.
When you’re building your team for your VR project, you’ll want to staff heavier on the engineering side than you would for a traditional game project. Further, it's optimal to populate your team with a greater percentage of experienced developers than normal.
While more engineers doesn’t perfectly equate to increased velocity, the simple fact is that every problem you face will require new solutions, a risk that can be meaningfully mitigated with people power. Even if you’re using a proven commercial game engine, everything from feature development to optimization takes a long time on VR and involves a significant learning curve. These are new knots to untangle and for the most part, very few people across the industry have meaningful experience in VR.
Here’s how I would recommend adjusting your engineering team size:
>10 total headcount: 3x
11-50 total headcount: 2x
50+ total headcount: 1.5x
If you’re working with a fixed budget on your game, this may mean scaling down your art headcount, which isn’t great in and of itself. One mitigating factor is that stereoscopic rendering means you're basically rendering everything twice. A game of comparable scope simply has fewer pixels it can push through the renderer.
Accordingly, the content requirements for VR are lower than other platforms. If you think back to past generations of console games and the scope of art created for those games – both in terms of the raw asset density and in terms of the amount of polish per asset – you can get a good sense of where VR is in its current (2017) iteration.
In an ideal world, I recommend a small VR art team laden with senior artists who enjoy new technology challenges and plenty of technical artists who are passionate about the medium.
The good news on this front is that great engineers are frequently drawn to new technology problems, just as great artists can be drawn to new mediums of expression. You can harness that excitement to bring fantastic people into your organization.
It’s one thing to read about the technical limitations of VR or talk to someone who has shipped a game in VR, but don’t talk yourself into thinking you can make it without significant input from someone who released a commercial product on the platform. You need someone who has directly worked on solving the unique problems of the medium. It can be a freelancer, consultant, or advisor, but ideally that person is someone who is a core member of your team.
The best case is if this person works in the engineering vertical of your company, even more so if your VR expert is the head of your engineering team. This allows that person to translate those experiences working on the platform directly through their team, providing that intrinsic, internalized knowledge of VR-specific challenges to everyone working on the technology that drives your game.
Experiment 7 is lucky in that our Technical Director, Mario Grimani, has been working in VR since the days of duct tape and bailing wire. One of our engineers worked on open source VR solutions. I worked on some of the very early (and very rough around the eyeballs) VR prototypes internally at Autodesk. Those experiences – often in figuring out what doesn’t work on the platform – have been crucial to the success of our team, even more profoundly than in traditional game platform transitions, because of the transformative nature of VR.
Baby steps from the Autodesk days...
New tech is exciting and none more so than VR. Which is why it’s vitally important that you take the time during preproduction to plan, prototype and test. Don’t get too excited and run straight into the teeth of your project!
Stick to your phase gate plan. Build and iterate through your concept, look & feel, and early prototype in preproduction (which will take longer than you expect, especially for your first project). Getting a new asset pipeline for VR set up is no small task - do it early. If you wait until the production phase to finalize your content and feature workflow, you’ll spend your production cycle firefighting and redoing key systems, rather than delivering great features and content.
Make sure that you’re aggressively prototyping at every phase, even with proven mechanics. We made the decision to go with a relatively low-scope chess game for our first title, so we could easily integrate a Chess engine and use Unity store assets to test the concept of table games in VR early. That process, as rudimentary as it was, revealed tons of issues and opportunities in our core design and in our technology expectations. Issues that would have been hugely problematic (or significant missed opportunities) if we had left them to the end of the project.
"Okay, so imagine you've got a table...and it's magic..." - Geoff, probably
Finally, during preproduction, budget more time than you think for infrastructure. You can’t just buy a few machines and desks and be off to the races. Depending on the platforms you’re targeting, the various combinations of hardware and software can take significant time to track down, given the wide range of headsets currently in use (with new ones coming online every quarter). QA infrastructure can be especially difficult to get going on new VR projects given the specific physical device requirements at the scale of a full QA team.
In VR, more than any platform, framerate is more important than fidelity.
As you may or may not know, framerate in VR has an outsized impact on the overall experience. High framerates (90+ fps) lead to a smooth experience, while lower framerates can lead to a profound sense of discomfort and render your application unusable to a significant portion of your audience.
No matter how aggressively you scope for memory and processing power, content has a tendency to come in over budget – make sure your asset budget has lots of buffer room; more than you think you need. Things will get broken by new platforms that are dynamic and constantly evolving – make sure you’re accounting for this so that when something does break, it doesn’t completely nuke your game. Users will do horrible, horrible things to their hardware – make sure to account for your end users installing tons of CPU and memory-hogging applications on the target platform.
If you’re multi-platform, set goals based on your lowest possible performing platforms…and stick to them! This is a non-trivial task, as it requires business, technology, and creative buy-in. Push this to the top of the priority list.
Realistic proportions, movement, and physical relationships are critical to creating a VR experience that makes use of presence. Content that is out of scale with the world around it risks appearing "spooky" and unsettling, leading to subtle but meaningful feelings of cognitive dissonance in your users. Unrealistic or unfamiliar gravity, viscosity, or friction can have the same effect.
Door frames, windows, tables, chairs and other common real-world physical objects in game space are especially susceptible to this phenomenon. For games grounded in reality, there is a pretty simple solution. Measure things and stick to those sizes. This constraint can certainly be a limiting factor, but can also be a creative challenge that leads to dynamic and innovative solutions to problems both complex and mundane.
Preproduction proportions testing
During preproduction, try starting with realistic proportions and aggressively test with white-rooms to avoid having to rework assets down the road. Working from a regimented, realistic base of assets goes a long way towards making the user comfortable in your environment.
All that said, the one guiding principle for VR – especially in these relatively early days of mass market consumer VR – is that comfort is king. It’s imperative to ensure your experience is palatable to your target audience.
If you’re making a card game for a wide audience, make sure that your framerate is extremely high, your contrast is relatively low, and you’re never accelerating or moving the character outside of motion-tracked head and body movements. If you’re making a hardcore flight simulator with 6 degrees of freedom and non-stop flak explosions, you have a different bar to hit, but core tenants (always high framerates, try to never move the player’s camera unless they’re controlling it, use slower acceleration where appropriate, etc.) are always good to keep top of mind.
Be cognizant that with every increment you push your experience past your target comfort point, you’re losing and alienating another large cohort of users, potentially damaging your reputation and your brand.
Find a spark and build from that. There are so many unknowns in VR – especially right at this moment in time – that it requires an entirely new pipeline, process, and technology outlook to bring anything to market, let alone something of notable scope.
This is VR. You should dream big. However, the best advice I could give at this moment in time is to create a small chunk of that dream with your first VR release. Get that product to the market – to any market – and get into preproduction on your second title with everything you’ve learned. Use that experience to help your team execute more efficiently and at a vastly higher level than the first go round.
This is one thing we nailed at E7. We started off with a relatively small game in Magic Table Chess, moved on to something marginally bigger for our second game, with exponentially larger projects on the horizon. Each step along the way has enabled us to work faster, focus more on experiences than infrastructure, and push our quality bar higher and higher.
Starting to come together...
This is the agile mantra, but especially so for new, rapidly evolving platforms like VR. It might sound cliché, but the pain is real. These are incredibly dynamic software and hardware products that are constantly evolving in meaningful ways. Platform updates right before VC meetings, cables getting imperceptibly loose and taking someone offline for hours, system background processes triggering and running the game at one frame every other second are all real possibilities that many of you will encounter.
While there’s little you can do to truly mitigate for these challenges, knowing that something along the way will conspire to foul up your perfectly-planned software project can help you reduce the impact of these issues when they do happen.
In addition to unexpected critical fails, if you’re working with a commercial game engine or platform back end suite, plan to be rolling over to new versions far more frequently than on traditional platforms. The dynamic nature of these platforms means that new updates address critical issues and can introduce new version mismatches more frequently than stable technology platforms.
In Conclusion Making games in VR is awesome. I frequently find myself losing myself in our games when I should be doing work, just because the experiences are still so profoundly magical. VR is a new and massively exciting frontier. A stereoscopic wild west.
It all comes together
However, like the American wild west of old, it’s full of danger and adventure. Being cognizant of the perils of the medium can’t help you to avoid these challenges altogether, but hopefully it can help mitigate the impact of them when you hit them.
I’d love to hear similar experiences folks have had working on early projects in VR. Horror stories are always great, or if you disagree with anything I’ve said here I’ll keep an oculus out for comments posted to this article.
Yes, I just ended this 2500-word VR article with an eyeball pun.
This post originally appears on the Experiment 7 Blog.
Coray Seifert is the Director of Production for Experiment 7, a VR strategy game developer based in New York City and San Diego. For more than 15 years, Coray has developed games as a producer, game designer, and writer for organizations like Autodesk, THQ's Kaos Studios, and the US Department of Defense. A Lifetime Member of the International Game Developers Association, Coray was elected to the IGDA’s Board of directors in 2007 at the age of 27; the youngest board member in IGDA history.
0 notes