LCA 2018 Day 1

· 4050 words · 20 minute read
Conferences · Technology
lca · lca2018 · games · twine

This year LCA comes to Sydney, marking the first time I’ve been here since I was maybe 8 or 9. The locals are shocked; apparently the idea one has not come to Sydney is inconceivable. So far I’ve been enjoying the well-integrated public transport with fast, quiet high-speed trains (20 minutes from the airport to Redfern), been freaked out by the cost of rent (Redfern, a location where there are signs asking people not to shoot up in front of children, has apartments renting north of $1200 a week), and oppressed by the weather. Sydney is vast, full of Things and Stuff, and I doubt I’ll see more than the tiniest fraction of it this week.

This year I’m offering many thanks to OSS for sponsoring my ticket.

Conference Opening

The traditional “have you bothered showing up?” prize is announced; the first recipient misses out by virtue of not being here.

One nice new idea: the team can produce temporary passes if you forget one. This is pain I have experienced, and doubling back to distant accommodation is a pain in the arse. Good thinking, LCA team.

You can finding rolling announcements of Stuff are at https://linux.con.au/gday

LWN

This marks 20 years of LWN; originally set up as a newsletter while waiting for Red Hat to sort out their partner program, Jonathan notes drily that linux-kernel “was 100 messages a day! No-one could keep up with that!” After a good start, an aquisition in 2000, a demerger in early 2002, they found themselves running out of cash in August of 2002 and announced a shutdown - and readers responded with money; since then, LWN has been supported by subscriptions.

This is LWN’s 13th time at LWN, and the whole LWN team are here this year.

OSI

It’s 20 years of the OSI (the good Open Source Initiative, not the moldy old 7 layer stack); Molly de Blanc and Josh Simmons are here representing them. Molly notes it is also the 20th anniversay of Netscape releasing their code base, one of the events for both coining the term and setting up the OSI body. OSI itself manages accreditation of open source licenses, but also acts as an incubator for open source software, and will offer organisations advice on how to be good open source citizens, as well as lobby governments.

Josh and Molly both note that OSI is a relatively small organisation, sustained by members and with a member-elected board, and would like to encourage people to get involved.

I’m Tomu

This is the USB board included in every swag board.

Raffle

This year’s raffle is supporting Code Club Australia; there are about 1,000 clubs in schools and another 1,000 in libraries. Scratch and Python are the main learning languages, and classes happen all over Australia; the clubs are focused on 8-12 year olds.

LCA Games Miniconf Opening

Your hosts are @the_mcjones and @ducky_tape and they’d like you to tweet under the tag #lcagm

Open Sourcing History: Using History to Make Your Game Better

Claire Manning @Clazzaranius

Claire is a Consulting Archeologist, who is working on an as-yet unannounced game.

As more games have been nominally based in history, it’s become painfully obvious when developers haven’t bothered doing any meaningful research. You should care about this because:

You can build a better environment, faster.

History can complement games, not just because you get get a pre-built setting, but also one you don’t have to explain as much to your players; they bring a certain level of knowledge about a context (Victorian England; medieval Europe; Shogun Japan; Ancient Greece), and you can focus on the points of your setting and story which are unique.

Claire is impressed by Assassin’s Creed: Origins; Ptolemic Egypt is one of Claire’s specialist areas of study, and she’s impressed by the breadth of the work the developers have done; they have done a job, not just of large scale monuments and buildings, but carefully using small text snippests, hairstyles, clothing, and other small details that create a more immersive environment.

All of this creates a better game.

History Inspires Great Characters and Settings

Skimming over Google or “what everyone knows” is much less interesting than the actual historical record; were people aware of the presence of women in Viking raiding parties, or that Viking York was an industrial hub? Probably not. Using real history can be much better than what “everyone knows” (as an aside, I’ll note that this is the core of Moana: Moana’s story arc in the film is moving to understanding the actual history of Pasifka journeying, so it can be the core of the story, not just setting or scaffolding).

If you don’t rely on actual research, you’re probably relying on stereotypes. And there are problems with this:

  • Stereotypes are often inaccurate.
  • You can end up alienating people. People are not going to want to help with or play your game; the former is particularly important if you work in open source.
  • Stereotypes skim the surface; they are rarely as interesting as you can achieve by making a little more effort.

Don’t rely on simpified, watered-down tropes. While you don’t have to make everything perfectly accurate, the best lies are drawn from a kernel truth.

Claire offers as an example of this Horizon: Zero Dawn. While its setting is a post-apocalyptic world, it does a great job of drawing on real-world anthropology; the cultures in the game are drawn on what we know about existing historical cultures, used to synthesise the cultures of the game; anthropologists helped consult on the future cultures, which has created a more truly immersive environment.

History is Cool

Claire did a personal project translating a promotional image for Assassin’s Creed promotional image, and found they’d hired Egyptologists to translate the game motto into hieroglyphs. When Claire published her reverse translation, people were fascinated - which generated buzz for the game.

So how do you find people? Reach out: you can find and contact people online. You’ll quickly find historians who care about this, and may be interested in helping out. There are consulting groups, universities, or the authors of books and articles.

More academics are becoming interested in how games represent history, archaeology and culture: for example Archaeogaming and The Intereactive Past are concerned with this area.

Q&A

  • What are the low-hanging fruit? Run away from Wikipedia and many privately owned sites. Google scholar is really good, but be careful about the age of the material - work is regularly superceeded.
  • Claire clarifies that Wikipedia is an OK starting point, but it should never be the end of your research.

This was a really interesting talk; it could easily have filled twice the time, I suspect, and just been all the richer for it.

Digitising History and Culture with FOSS

Torres Straight Virtual Reality

It’s a game intended to present Torres Straight Islander knowledge - ranging from family knowledge, through to literature and academic articles. While there is a bit of Aboriginal Australian work in this area, there is pretty much no Torres Straight Islander knowledge.

VR is a great fit for this - tranditional knowledge has been passed down as an oral culture, so presenting this information with visual and audio is very much in line with traditional teaching. As VR has become more affordable, it seems like a great idea.

The game is at the stage of being a prototype, which has been used university classwork, as a demonstration of what is terchnically possible, to provide knowledge for areas like a policy class, to help teach the topic of traditional title, and to encourage indigenous interest in STEM.

Game Elements

  • Cultural practises in the Torres Straight.
  • Torres Straight environmental knowledge.
  • Torres Straight astronomical knowledge.
  • Torres Straight myths and supernatural beings.

Software

  • A mix of non-free but open source software, such as Unreal Engine 4.
  • The game and content itself, however, is consistent with FOSS values.

Source Code Generation: How I Learned to Stop Worrying and Love the Boilerplate

Daniel Phillips

The problem:

  • You want to implement or consume an interface.
  • You have to have a lot of boilerplate.
  • Things change a lot.

Solutions:

  • Write the boilerplate: painful.
  • Get someone else to write the boilerplate: painful for them.
  • Get the machine to write the boilerplate.
  • Consistent.
  • You can use your favourite idioms or patterns for your whole project.
  • Laziness-driven mistakes can be avoided.
  • Automatically generated structure is useful.
  • Tests can be generated at the same time.
  • Allows ease of multi-lingual support.

Some History

WSDL:

  • 2000 - present.
  • XML based, used with SOAP.
  • Not really human readible.
  • The workflow sees a developer fetch the WSDL, and their tooling autogenerates code.

OpenAPI/Swagger

  • 2010 - present.
  • More human readible.
  • Easier to write, too.

autogen, Apache Thrift, Scrooge, protobufs, and many others. People cooking up their own thing in this space is a recurring theme.

Design Principles

  • Generated code must be stateless.
  • It must never be comitted - it exists only in the build.
  • Treat it like a binary.
  • Schema versions must be adequately versioned.
  • It doesn’t need to be hugely readible: performance and critical is more important.
  • Limit your scope. You don’t need to build an LLVM front end.
  • Recursive descent parsers > regexps.
  • The generator code must be maintainable.
  • Be clear about the semantics of the DSL - is creating an index part of a schema?

doobie-codegen

  • A thin layer over SQL and JDBC for functional programming in Scala.
  • Built to provide a pleasant, idiomatic way for Scala programmers to interact with Postgresql.
  • Doobie itself is great, it it was becoming harder and harder to maintain the code.
  • doobie-codegen is the answer to that.

Mistakes:

  • Overuse of types.
  • Not leveraging Postgresql to parse things like migration scripts on your behalf, rather than building your own parser.

Q&A

  • How do you debug generated code - because it’s great until it’s not? In our case, Postgresql has great logging and deugging; make sure you have good debugging and logging, and generate test cases.
  • Is this just for SQL because generated code isn’t that great? No, for many use cases, and it generally works well.

In from the cold: Finally making Linux and .NET get along

Alistair Chapman @agc93

“Welcome to what may be the most contentious talk of the conf.”

History

  • .NET announced in 2001. Lots of talk about openness, but not much from Microsoft.
  • GNU.net and Mono were announced shortly thereafter.
  • Rotor was released in 2002 and was nominally open source. But it was locked away behind NDAs and suchlike.
  • Mono 1.0, .NET 2 and Rotor 2 were all released in a similar timeframe. Rotor was then killed.
  • Mono still continued, but trailed .NET.
  • rms in 2010 launched a blistering attack on .NET and mono. This didn’t help.
  • .NET Core was released - and was open sourced. For real this time.
  • Versioning in this world has not been terribly clear. (This is, if anything, a remarkably polite understatement by the speaker.)
  • Mono was spurred into new releases with Microsoft code in it.
  • And beat Microsoft to release a runtime conforming to the .NET Core 2 spec. This is the first time Mono has been ahead of Microsoft on an implementation, rather than a couple of years behind.

Note that Mono is not, in fact, dead. Even if Google autocomplete thinks so. For one, Mono includes the whole .NET platform, not just Core; you should be able to build big, 10 year old code bases on Mono, which you definitely can’t in Core.

Building .NET Apps for Linux

  • All much the same as any language:
  • Prepare your environment: an editor (VSC, JetBrains, MonoDevelop, PowerShell).
  • or just use a Docker image like a hipster.
  • You can build much like you would on Windows or Linux.
  • Command line or e.g. Visual Studio Code (which is easy and good).
  • Test, package, and bundle your app.
  • Deployment and Operations:
  • Build requires SDK.
  • FDD requires the runtime.
  • SCD - self-contained development - creates a deployable executable which contains the runtime.
  • The deployables are generally distro neutral.
  • Kestral is built-in.
  • Apps can be managed and monitored with systemd easily.
  • (And you should.)

Bridging the Platform Gap

  • There have been a lot of third party contributions to leverage the underlying platform, not just emulate windows.
  • DBus connectivity is a core part of .NET core now as a standardised way of interacting with the underlying Linux system - essentially distro-neutral.
  • There’s a lot that can be pulled out, including all sorts of quite low-level detail; the demo showed for example an enumeration of battery levels on a laptop.
  • Always target netstandard!
  • Test on multiple distributions.
  • Be aware of logging and config assumptions.
  • Set up cross platform CI/CD.
  • BE GENTLE WITH COLLABORATORS.
  • Do not be a jerk about Windowsisms in cross-platform code.
  • There are a lot of great examples in the code.
  • The .NET Core team are on slack and github.

This is real

This mostly works, and Microsoft seem really genuinely committed to making this work, and work well. And he says that as someone who lives and breathes Linux, and only does development on .NET.

Turning stories into software

Donna Benjamin

“Stories are what make us human.”

What is a user story?

“As a user… I require… so I can…”

But why? And where do user stories come from? Donna sees five ways user stories are generated:

  1. Workshops:
  • A great way to bring people together and brainstorm.
  • A generator of sticky notes.
  1. Interviews:
  • A one-on-one with someone who really knows what they need.
  • “The five whys.” - keep asking why until you find out what people really need.
  • A chance to work out whether what someone is asking for is what they need.
  1. Surveys.
  • The first two are qualitative. This is a chance to go wider and get quantitive data.
  1. Competitive analysis.
  • Less time consuming.
  • Pull from external sources - similar companies, competitors, etc.
  • Other experts in the field.
  1. Prototype and iterate.
  • Sometimes people don’t know what they want until they have something to play with.

These many stories add up to what Scrum people call an “epic”. Which is far too big to implement. So how to you winnow this down to work out what you do?

Think about INVEST:

  • Independent: can it be built without dependencies.
  • Negotiable.
  • Valuable: is this story valuable in and of itself?
  • Estimable: can you work out what you need to do - time, cost?
  • Small, achievable tasks that can be implemented on a human scale. Does it fit?
  • Testable: how will you test it? Does it work? Did it make people happy.

Have a look at Mike Cohn’s User Stories Applied; it’s a really good book. But one problem with focusing on small stories is that you can get so drawn into the detail of implementing those stories that you lose sight of the big picture. User Story Mapping by Jeff Patton and Peter Economy gives some ways to avoid that.

Teamwork

This is critical. Because building a thing requires a team; everyone works in teams to implement things. This is where understanding group dynamics is useful. Understanding how your team works (or doesn’t) is critical to how you tell your stories and how you implement.

Because the cards aren’t important; it’s the conversations that matter. The cards are ceremony.

Estimation

Estimation isn’t about getting a number; it’s about building a shared understanding of the task at hand; the estimated time and cost is a happy side-effect of building that understanding (I have to say that’s not what far too many project managers think, but they’re the bad PMs, and best ignored, anyway).

Cynefin (The habitat) is a coining from Welsh, by Dave Snowden: it encourages you to think about estimation in terms of whether tasks are Obvious, Complicated, Chaotic, or Complex.

  • Obvious
  • Well-known, well-understoof problems.
  • You can probably estimate in isolation.
  • You can be confident that your estimates will be very accurate, because you’ve done this so many times.
  • Complicated
  • May require external assistance with understanding the problem.
  • Ditto the solution.
  • The shared understanding becomes important here.
  • Complex
  • Requires a significant effort to understand.
  • Goes beyond a simple check with an SME or external to get everyone the common understanding.
  • The estimation may be a story in and of itself.
  • Chaotic
  • Everything’s on fire. Doing things takes priority over working out exactly what needs to be done.
  • Reserved for situations when everything’s on fire.

Go find this talk on YouTube and watch it. I have working in nominally Agile workplaces for nearly a decade and I picked up some new ideas and ways to attack problems from this session.

Augmenting Reality with Open Source

Eloise Ducky @ducky_tape

So what is augmented reality? NOT VIRTUL REALITY! It’s adding virtual elements to reality; this is a key difference to virtual reality, which is creating a synthetic world.

Consider: Snapchat filters, Pokémon Go, JAL’s training programs for jet engines, drone piloting.

Opinions

  • Ducky prefers open source. She can see what is happening, the age and viability of the tools, and they are affordable.
  • There’s two types of tools: native, and browser-based. Ducky tends to browser-based versions, because it’s more accessible to her users; however, native is optimal for performance.
  • Some tools: JSAR, tracking.js, three.js.

How do we use these things?

  • We need a camera to capture reality.
  • We need 3D objects to augment reality.
  • We need a tracking system to track the real world.
  • We need a view for the user to interact with.

“Tracking is the coolest part of AR for me - it’s where the cool algorithms come in.”

  • AR markers - a bit old school. Requires an image which is asymmetric (unique from all angles).
  • Geotrackers.
  • Face tracking.

The Future

There is a huge amount of cool stuff happing - new kits, the cost is coming down, there’s a huge amount going on in the world now. Ducky thinks it’s at the bottom of the “Slope of Enlightenment"on the hype cycle. Ducky says we need to create more things so we can work out what works.

Ducky pleads with us not to make poor gimmicks: you could easily make chess, but what’s the point? Consider what the purpose of augmenting reality is, ask what you’re doing that requires AR.

Making Games with Electron

Inga Pflaumer

Inga’s day job is working with Unity for games development, and mostly doesn’t give her the chance to do things the way she would in an ideal world; for fun, she likes to do game development in a way that lets her do things The Right Way.

Architecture

Space Head Hunters is a simple version of the board game CROWS, substituting space pilots for crows.

The Space Head Hunters team had 12 weeks to implement the game, starting with a team who had limited experience with the roles and technologies. One early challenge was to get work done while using good architecural practise. They started with a state machine describing the game flow; impleenting a GSO - a game state object - that describes all the state that will be in the game.

Electron

  • Uses common, familiar technologies; JS, HTML, CSS, node.js.
  • Electron forces you into good architectural practise; it has two main threads, a render thread and a compute thread. This pushes you into seperating your logic cleanly into a back and front end.
  • Encourages a unidirectional flow.

Delivery

Inga’s requirements:

  • Rapid prototyping.
  • Show something at week 2.

Developer requirements:

  • Network gameplay.
  • Animations.
  • Sound effects.
  • Settings menu.
  • Play!

Inga likes to show things early to keep people motivated. The longer something stays in planning, the less likely it is to ever be finished.

Inga notes the developers had no experience on how to do network gaming: but she loves a trier. “Master Yoda was wrong”; people who try will accomplish things - as long as they can see results and outcomes.

Lessons learn

  • Electron is very good for prototyping, because you don’t need to worry about browsers, versions, or platforms.
  • Architecture is more important than framework or language.
  • The more planning you do the easier it will be later on.

Q&A

  • What are the gotchas? If your game is big, Electron will probably run poorly. If your game is small, Electron is your friend.
  • What was the hardest part of the project? Accepting that network play might be achievable, and trusting that the developers could do it. Let the devs run wild if they can complete the core features.

Building Indie Games through Open Source

Jon Manning

Jon is one of the creators of Night in the Woods as part of the company Secret Labs.

Open sourcing chunks of a game, without interfering with your game development process. Night in the Woods is a very story-heavy game, and uses the Yarn programming engine.

Yarn cribs from Twine because Twine is so wonderful; Yarn is smart enough to parse the story dialogue and link the nodes together automagically. The Yarn language allows for branching dialogue without having to manually join things; by using markup inline with the text, it renders branching narrative more readable.

Yarn also allows state to be managed: the way characters feel, for example. It can then use conditional logic for setting up and triggering events in levels. The rest of the game engine is essentially scaffolding to support Yarn.

Yarn Spinner is developed in public, and features have been added as the game required them.

Open Source in Gaming

More generally, there are two kinds of open source communities in gaming:

  • Modders.
  • Game developers.

The former means there are a lot of people working on reverse engineering games. They have some common features:

  • Usually no licenses, with no thought about why that might be a problem through a lack of understanding of how licensing works.
  • In fact, modders usually think of licenses, even permissive ones, as making it harder to share, rather than easier.
  • Usually not a lot of code sharing, and what there is happens via, say, pastebin.
  • “No commercial use!”
  • “No redistributing!” - a really deep personal sense of ownership.

All of these are reasonable feelings from people who aren’t used to working in large teams, or development communities. They tend to stem from people who haven’t encountered free software.

Developers, on the other hand:

  • Rarely build generic libraries that could be released in a useful way. If games are released, it tends to be as a big, whole-engine code drop once the engine has been milked dry.
  • Indie developers are usually time-starved.
  • Indies are usually jacks-of-all-trades.
  • Indies, therefore, don’t have time to run an open source community. Companies usually aren’t interested in doing so.

What to expect:

  • Patches are usually tightly focused on a particular feature or problem.
  • Big company devs are rarely familiar with contributing code through, say Git, and if they use source control, it’s SVN or Perforce.
  • Indies may be familiar with Github.

Releasing code for busy developers:

  • Have a quick start tutorial.
  • Have screenshots.
  • Have reference code, which people will copy and paste everywhere. So make it good.
  • No-one will do version updates, in case it breaks something.
  • Have a contributers guide.
  • Have a code of conduct.
  • Make it clear you want contributions.
  • Accept the first contribution, even if it’s bad.
  • Fix it first, sure.
  • But if people have success the first time, they’ll keep trying.
  • Give people permission. LET THEM HELP YOU!
  • You want to write a game, not an engine.
  • You want people to help with the engine. Let them!

Q&A

  • Accepting the first commit is great, but how do you help people get better? Use github’s code review feature to help people understand how to get better; this is about mentoring.
  • How much text is in Night in the Woods? About 440,000 words, not counting flow control.

Twine and Tracery both have big source code and community repos of examples to help people learn.

Games Miniconf Closing and Lightening Talks

Kris Howard

  • Kris is organising the Art miniconf!
  • Kris is, along with some other local women, is doing the Harvard CS50 self-taught course, and the first assignment is writing a game in scratch.
  • Scratch is talked about as a language for kids. Kris found Scratch utterly compelling.
  • Not only compelling enough to work on the course, but to create a James and the Giant Peach game for her Roald Dahl fan site that she’s been running for a couple of decades.
Share