JRPG Atelier Lulua: The Scion of Arland is seeing the light of day on Tuesday 21st May according to Koei Tecmo. A sequel to the PS3 Arland trilogy – available individually or in a Deluxe Pack on Switch – sees you controlling a young woman named Elmerulia Lulua Fryxel, an apprentice alchemist.

The official announcement offers more details:

Lulua studies diligently to fulfill her dream of becoming a great alchemist just like her mother, Rorolina Frixell; but during her training Lulua discovers a mysterious Codex, awakening an ancient power within her that enables Lulua to decrypt but a single page with many more riddles for her to unravel. Players will be tasked with performing actions focused around the core Atelier series gameplay Gathering, Battle, and Synthesis to allow them to decipher more of the text, as well as learn exciting new types of alchemy.

There are a few sparse details on Koei Tecmo America’s website along with the pretty pictures we’ve reproduced here. No word on pricing yet, though.

Are you a fan of the series? Does this trailer get you in the mood to return to that world? Share your impressions below.

If there’s one thing we’ve been clamouring for over the last few years (“we” meaning “at least one of us”), it’s a direct sequel to Pokémon Snap. The 3DS seemed like a perfect opportunity with its camera functionality, but nothing, and the Wii U’s GamePad seemed even more suited as you’d be able to line it up with the TV, but nope. We’d argue that it’d be just as great on Switch, or even as a mobile game, but it just isn’t happening, is it?

Well, Niantic is now offering the next best thing with its world-dominating Pokémon GO. A new feature called GO Snapshot is on the way to the game, giving players a much more robust photo system using the game’s AR+ feature. Billed as an easy way to take photos of any of your Pokémon, the new option will become available when looking at a Pokémon or when accessing the camera in your bag.

An update from Niantic’s official blog sheds more light on exactly how the feature will work:

“It’s simple to use. Select a Pokémon and tap on the screen to throw its Poké Ball to that spot. Once your Pokémon is situated in the ideal spot, you can then move around it to find the best angle for your photo. Is your Pokémon distracted or looking the wrong way? Brush across it to get its attention, and it will be sure to face you.

Take as many photos as you like during your session. Once you’re finished, all photos are saved to your device automatically! It’s also easier than ever to share your favorite photo via social media. Just select the linked social channel you want to share with, and you can show your friends your masterpiece with a couple of quick taps.”

It does sound like a nice little extra for fans of the game and it could be a great way to get creative, finding clever ways to show off your collection.

Will you be using the feature? Would you be up for a Pokémon Snap feature, too? Please tell us we’re not alone in the comments.

In our quest to examine all the clutter (&, |, ;, >, <, {, [, (, ), ], }, etc.) that is peppered throughout most chained Bash commands, we have been taking a closer look at the ampersand symbol (&).

Last time, we saw how you can use & to push processes that may take a long time to complete into the background. But, the &, in combination with angle brackets, can also be used to pipe output and input elsewhere.

In the previous tutorials on angle brackets, you saw how to use > like this:

ls > list.txt

to pipe the output from ls to the list.txt file.

Now we see that this is really shorthand for

ls 1> list.txt

And that 1, in this context, is a file descriptor that points to the standard output (stdout).

In a similar fashion 2 points to standard error (stderr), and in the following command:

ls 2> error.log

all error messages are piped to the error.log file.

To recap: 1> is the standard output (stdout) and 2> the standard error output (stderr).

There is a third standard file descriptor, 0<, the standard input (stdin). You can see it is an input because the arrow (<) is pointing into the 0, while for 1 and 2, the arrows (>) are pointing outwards.

What are the standard file descriptors good for?

If you are following this series in order, you have already used the standard output (1>) several times in its shorthand form: >.

Things like stderr (2) are also handy when, for example, you know that your command is going to throw an error, but what Bash informs you of is not useful and you don’t need to see it. If you want to make a directory in your home/ directory, for example:

mkdir newdir

and if newdir/ already exists, mkdir will show an error. But why would you care? (Ok, there some circumstances in which you may care, but not always.) At the end of the day, newdir will be there one way or another for you to fill up with stuff. You can supress the error message by pushing it into the void, which is /dev/null:

mkdir newdir 2> /dev/null

This is not just a matter of “let’s not show ugly and irrelevant error messages because they are annoying,” as there may be circumstances in which an error message may cause a cascade of errors elsewhere. Say, for exapmple, you want to find all the .service files under /etc. You could do this:

find /etc -iname "*.service"

But it turns out that on most systems, many of the lines spat out by find show errors because a regular user does not have read access rights to some of the folders under /etc. It makes reading the correct output cumbersome and, if find is part of a larger script, it could cause the next command in line to bork.

Instead, you can do this:

find /etc -iname "*.service" 2> /dev/null

And you get only the results you are looking for.

A Primer on File Descriptors

There are some caveats to having separate file descriptors for stdout and stderr, though. If you want to store the output in a file, doing this:

find /etc -iname "*.service" 1> services.txt

would work fine because 1> means “send standard output, and only standard output (NOT standard error) somewhere“.

But herein lies a problem: what if you *do* want to keep a record within the file of the errors along with the non-erroneous results? The instruction above won’t do that because it ONLY writes the correct results from find, and

find /etc -iname "*.service" 2> services.txt

will ONLY write the errors.

How do we get both? Try the following command:

find /etc -iname "*.service" &> services.txt

… and say hello to & again!

We have been saying all along that stdin (0), stdout (1), and stderr (2) are file descriptors. A file descriptor is a special construct that points to a channel to file, either for reading, or writing, or both. This comes from the old UNIX philosophy of treating everything as a file. Want to write to a device? Treat it as a file. Want to write to a socket and send data over a network? Treat it as a file. Want to read from and write to a file? Well, obviously, treat it as a file.

So, when managing where the output and errors from a command goes, treat the destination as a file. Hence, when you open them to read and write to them, they all get file descriptors.

This has interesting effects. You can, for example, pipe contents from one file descriptor to another:

find /etc -iname "*.service" 1> services.txt 2>&1

This pipes stderr to stdout and stdout is piped to a file, services.txt.

And there it is again: the &, signaling to Bash that 1 is the destination file descriptor.

Another thing with the standard file descriptors is that, when you pipe from one to another, the order in which you do this is a bit counterintuitive. Take the command above, for example. It looks like it has been written the wrong way around. You may be reading it like this: “pipe the output to a file and then pipe errors to the output.” It would seem the error output comes to late and is sent when 1 is already done.

But that is not how file descriptors work. A file descriptor is not a placeholder for the file, but for the input and/or output channel to the file. In this case, when you do 1> services.txt, you are saying “open a write channel to services.txt and leave it open“. 1 is the name of the channel you are going to use, and it remains open until the end the line.

If you still think it is the wrong way around, try this:

find /etc -iname "*.service" 2&>1 1>services.txt

And notice how it doesn’t work, notice how errors get piped to the terminal and only the non-erroneous output (that is stdout) gets pushed to services.txt.

That is because Bash processes every result from find from left to right. Think about it like this: when Bash gets to 2&>1, stdout (1) is still a channel that points to the terminal. If the result that find feeds Bash contains an error, it is popped into 2, transferred to 1, and, away it goes, off to the terminal!

Then at the end of the command, Bash sees you want to open stdout as a channel to the services.txt file. If no error has occurred, the result goes through 1 into the file.

By contrast, in

find /etc -iname "*.service" 1>services.txt 2>&1

1 is pointing at services.txt right from the beginning, so anything that pops into 2 gets piped through 1, which is already pointing to the final resting place in services.txt, and that is why it works.

In any case, as mentioned above &> is shorthand for “both standard output and standard error“, that is, 2>&1.

This is probably all a bit much, but don’t worry about it. Re-routing file descriptors here and there is commonplace in Bash command lines and scripts. And, you’ll be learning more about file descriptors as we progress through this series. See you next week!

Hey devs, just a quick heads-up today that if you’re thinking of bringing children with you while you attend GDC 2019 next month, the advance deadline to register for the program is next Monday, February 18th!

Registration is handled on a first-come, first-served basis, so it’s a really good idea to register as soon as you can. It’s of course possible to register on-site, but we can’t guarantee KiddieCorp will be able to accommodate on-site registrations and doing so is not recommended.

If you’ve never taken advantage of it before, know that the KiddieCorp children’s program is for children ages 6 months through 12 years old and will be situated within the Moscone Center in San Francisco, California.

The KiddieCorp team charges an affordable hourly rate for their services and snacks and beverages will be provided, but meals do need to be supplied by parents each day.

Also, the KiddieCorp team will engage your children with activities they want to attend, providing you with that critical peace of mind so you can attend your sessions and events worry-free. Activities include exciting themes, arts & crafts, group games, music & movement, board games, story time, dramatic play, etc.

KiddieCorp provides activities appropriate for each age group, using safe and sturdy equipment. Plus, children can make their own choices within KiddieCorp’s program.

To learn more about the service and register your child as a participant, head over to the KiddieCorp GDC 2019 children’s program registration page. Again, make sure to register early as availability is limited and handled on a first-come, first-served basis.

For more details on GDC 2019 visit the show’s official website, or subscribe to regular updates via Facebook, Twitter, or RSS.

Gamasutra and GDC are sibling organizations under parent company Informa

This interview is part of our Road to the IGF series. You can find the rest by clicking here.

Just Shapes & Beats is a bullet hell in a music visualizer – and dizzying dance of light, color, and song as players struggle to survive while moving and dodging to the beat. 

Gamasutra had a talk with Simon Lachance, designer of the Excellence in Visual Arts-nominated title, to learn about the ideas that went behind creating the game’s visual spectacle, building stages out of a music visualizer, and how he chose music that inspired him to create audio battle zones.

Beginning of the beat

I’m Simon “Lachhh” Lachance and I’m the game designer for Just Shapes & Beats.

Unofficially, I started making games as a dare in exchange for burritos back in college. Officially, I’ve been a game dev for 14 years now? Started off in a local studio as a coder, then left to create Berzerk Studio with my two associates, Etienne and Marc, ten years ago. Been indies full time ever since.

We started by making super small games for a few bucks, and over the years ended up making over 25 Flash and mobile games, with the end goal of someday making games for consoles, and now here we are!

Visions of play through music

Just Shapes & Beats was inspired by the music itself. Six years ago, I went to a concert at GDC, bought a CD from one of the artists playing (Parallel Processing by Danimal Cannon), and forgot about it. Months later I found it and put it in my car, then instantly started seeing gameplay.

A few months later, I went to a local game jam in Quebec City and decided to do that music game I had a fever dream about in the car, but being a coder I couldn’t draw for shit, so I made it about shapes.

The tools of making musical mayhem

I used Flash (lol Flash is dead) for most of the prototyping phase, then moved to Unity for shipping.

On creating the visual appeal of Just Shapes & Beats

A lot of flashing colors and a big old seizure warning. All kidding aside, it’s basically a gamified Winamp visualizer, and funky visualizers are awesome to watch. Have you wasted hours looking at them back in the ’90s? I sure did.

On creating stages from songs

It’s mostly trying to create something that looks how it sounds – something that’s inspired by what the music makes you feel. The music is not just playing in the background. You are playing the music.

Feeling their way through choosing music for the game

There’s no single way to look at it. It’s like when you fall in love; it just feels right. We’d just listen to gallons of chiptunes and isolate those that would inspire us with gameplay. No metrics, just feels.

‘Accidental’ co-op

Honestly, the co-op part is mostly a happy accident. The initial game was a super-hard single player mouse-based Flash game. We added the multiplayer because we had an opportunity to go to a game show and felt we needed to have it just so more people could play the game over the weekend. The reception was amazing, so we decided that it’s how we had envisioned it all along. Geniuses, we are.

Challenges of designing a game that’s both single- and multiplayer

I wouldn’t say difficult, but it was stressful wondering if we were just another novelty indie multiplayer game. Adding the story mode helped a ton in relieving some of that anxiety, but only created a new problem where we didn’t know if players were going to like the story we had to tell. We’re not storytellers here, and putting something out there that’s way outside your comfort zone is scary, dude. 

Letting everyone jam

We wanted everyone to be able to experience our game. Just Shapes & Beats is about jamming out to music, not about having the APM of a StarCraft player and the reflexes of a cyborg tiger on steroids. Adding a mode that you can just have playing in the background that anyone can just mess around with to liven up a family shindig took nothing out of the global experience.

At long last, Salt and Sanctuary is coming to Xbox One! Our 2D souls-like of deadly monsters, labyrinthine dungeons, and shattered heroes may be our studio’s fourth big game, but it’s our first title to grace Xbox One.

Over a decade ago, when the studio was just me, I was lucky enough to get my big break when I was awarded a publishing contract to bring The Dishwasher: Dead Samurai to Xbox Live Arcade. Since then, Ska Studios has doubled in size! Over the next 6 years, we’d release The Dishwasher: Vampire Smile, Charlie Murder, I MAED A GAM3 W1TH Z0MB1ES 1N IT!!!1, ZP2KX, and who knows what else on Xbox 360; sometimes on XBLA, sometimes on XBLIG.

And today, the great folks at Blitworks have done a fine job of bringing the game in all its gloomy glory to Xbox One. But now that we’ve returned at last to Xbox, I thought I’d share a tale of the game Salt and Sanctuary might have been.

I started writing what would become Salt and Sanctuary as far back as 2012, while finishing up Charlie Murder, which we would launch on Xbox 360 in 2013. At some point I envisioned it as a procedurally generated roguelike, and as I look at my codebase now, I see the game still has some commented-out code and some excluded classes to enable that functionality (no one’s ever accused me of being a tidy programmer). One idea that I was considering was for the game’s protagonists to be drawn from a procedurally generated shipwrecked crew of a Nordic-style viking longship exploring the procedurally generated world. Your crew might have 2 mages, 3 archers, 1 fighter, and so on; how would you tackle the world?

I ended up totally walking away from procedural generation. The expression I like to talk myself out of the appeal of limitless procedural generation is, “when everything is random, nothing is.” We’re pattern recognizing mammals, and without realizing it, we’re probably as good at cataloguing procedural generation algorithms as we are at remembering the layout of a fixed map. And the procedural crew idea was problematic: does the crew replenish, or is it a fixed pool to keep the tension high? Would it be overly frustrating to arrive at the end with only the “worst” crew available? How do you solve the narrative problem of sending out the crew one by one like a horror movie trope?

This was around when our Dark Souls obsession flew into full swing. I had been a huge fan of Castlevania: Symphony of the Night, but like many gamers, I had begun to notice a trend in the ensuing years toward tutorials, checkpoints, objective markers; form over function, all of it focus tested into palatable mush. And when Dark Souls came out, I’ll admit I didn’t “get it” initially. But it clicked in time: the solitude, the agency, the layers of depth concealed by obscurity, the relentless difficulty — these were things once integral to games, driven away by years of simplification in the name of minimizing frustration. Minimizing frustration is a good thing! But at some point, it became doctrine. Dark Souls bucked the trend, and gamers rejoiced.

I hadn’t been won over by the procedural prototype yet, and I had begun to wonder, “would a Dark Souls style game work in 2D?” And thus, the procedural stuff was scrapped, and a big new experiment commenced! The combat took after The Dishwasher (no one ever comments on this!), but with a more deliberate pace. The loot system from Charlie Murder was heavily adapted. Some more ambitious systems were scrapped, like a weapon upgrade system that would unlock super moves at higher tiers. The sanctuary system was probably more ambitious than its final form, but I’m still really happy with it: I like populating my cozy little hubs!

I know it’s a cliché way to close out, but I really did have a blast making Salt and Sanctuary. If this is your first time playing it, I only hope enjoy it half as much as I did making it. The Salt that Nearly Was may have been relegated to the recycling bin of game development history, but if you’d like to turn my Viking longship idea into reality, go for it!

Salt and Sanctuary is available now for Xbox One on the Microsoft Store. Click here for purchase details.

* New Bloom ended a few hours earlier than intended, the event has now been extended to be active through Feb 12th.
* Fixed an issue that caused the New Bloom Nian Courier to drop at lower than expected rates. This has been corrected, and items have been granted to reflect the proper drop rate.
* Fixed a bug that allowed pressing quickbuy in rapid succession to purchase the same item twice.
* Several Ranked Emoticons have been increased in size, and all emoticons used during in-game chat are now larger and closer to center on the chat line.