Tag: open source

Posted on by — Leave a comment

Drag[en]gine Hands-On

The Drag[en]gine is a highly modular, open source (C++) game engine that has been under active development for several years. The Drag[en]gine’s modular approach is built around the GLEM concept breaking your game project into the Game Script, Launcher, Engine and Modules layers. The Game Script is implemented by default in Dragonscript, another open source project available here. Drag[en]gine is open source under the LGPL license on GitHub.

If you want to get started with Drag[en]gine you can download binaries for Linux and Windows available here, it’s most likely the IGDE file you want to start with. There are a number of samples to get you started available here. You can learn more about Drag[en]gine in the video below.

[youtube https://www.youtube.com/watch?v=ZyW22zRk6A8?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Unity Launch Open Projects

The Creator and Developer Advocacy group over at Unity have just launched a new initiative called Open Projects, a Unity lead effort to develop a vertical slice of a game that is open source and community driven. If you are looking to get experience at working with a team, or perhaps are a student looking to build up your resume, contributing to an Open Project could be a good fit. The intention is to create open projects for multiple genres, but initially they are starting with an action-adventure style game. The final results will be published (assumedly for free) on Steam, with all contributors credited for their efforts.

There is a bare-bones project in place now you can download from GitHub. In fact GitHub is central to the entire process, as this is where the project will be housed and where all code and asset collaboration will occur. In addition to GitHub they are coordinating the project in a dedicated Open Projects forum, as well there is a Contribution Guide on Google Docs available here. Project management tasks are managed here powered by Codedecks, an online PM tool specifically for game developers.

You can learn more about Unity Open Projects in the video below (or on Odysee here).

[youtube https://www.youtube.com/watch?v=3R45KmvfIZc?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Miniaudio — Open Source Single File C Audio Library

Miniaudio is a cross platform open source C library for implementing low level audio functionality including playback and capture. MiniAudio is released under either public domain or MIT No Attribution licenses and amazingly enough is implemented as a single .H file with no external dependencies (except optionally stb_orbis if Ogg Vorbis format support is desired).

Miniaudio features include:

  • Your choice of either public domain or MIT No Attribution.
  • Entirely contained within a single file for easy integration into your source tree.
  • No external dependencies except for the C standard library and backend libraries.
  • Written in C and compilable as C++, enabling miniaudio to work on almost all compilers.
  • Supports all major desktop and mobile platforms, with multiple backends for maximum compatibility.
  • Supports playback, capture, full-duplex and loopback (WASAPI only).
  • Device enumeration for connecting to specific devices, not just defaults.
  • Connect to multiple devices at once.
  • Shared and exclusive mode on supported backends.
  • Backend-specific configuration options.
  • Device capability querying.
  • Automatic data conversion between your application and the internal device.
  • Sample format conversion with optional dithering.
  • Channel conversion and channel mapping.
  • Resampling with support for multiple algorithms.
    • Simple linear resampling with anti-aliasing.
    • Optional Speex resampling (must opt-in).
  • Filters.
    • Biquad
    • Low-pass (first, second and high order)
    • High-pass (first, second and high order)
    • Second order band-pass
    • Second order notch
    • Second order peaking
    • Second order low shelf
    • Second order high shelf
  • Waveform generation.
    • Sine
    • Square
    • Triangle
    • Sawtooth
  • Noise generation.
    • White
    • Pink
    • Brownian
  • Decoding
    • WAV
    • FLAC
    • MP3
    • Vorbis via stb_vorbis (not built in – must be included separately).
  • Encoding
  • Lock free ring buffer (single producer, single consumer).

Miniaudio is available on GitHub and has solid documentation available here and several examples available here. Installation consists of downloading and #include’ing the header and that is it, making this a remarkably simple library to get started using. There are also unofficial language bindings for Go, Rust and Python available as well. You can learn more about the Miniaudio library in the video below (or view here on Odysee).

[youtube https://www.youtube.com/watch?v=XIye2LeLLUc?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

LEd — Awesome New Level Editor From Dead Cells Creator

LEd is a new open source level editor written in the Haxe language by a developer at Motion Twin, using lessons learned creating games such as Dead Cells. LEd is designed to be user friendly and from my experiences it succeeds.

Key details of LEd:

  • Easy to use: modern UI with a strong focus on ease-of-use and quality-of-life features.
  • Universal and agnostic: compatible with all languages (not only Haxe) and game frameworks in the world
  • JSON: easy to parse file format for any game-engine out there (I promise it’s actually really easy). Haxe isn’t required.
  • Customizable layers: Integer grid layers, Tile layers and Entity layers support
  • Auto-layers: paint your collision map and see the grass, textures and all the small details being drawn automatically!
  • Entities: fully customizable Entity with custom properties (ex: you can have a “Mob” entity, with a “hitPoints” field, which is an Integer limited to [0,10] bounds).
  • Enums: you can define an enumeration (ex: an “ItemType” enum with “Money”, “Ammo”, “Gun” values) and use this enum in your entity custom fields.
  • External enums: enums can be imported and synced directly from Haxe source code files (HX file)!
  • HTML5: LEd is built around modern web standards.
  • Auto update: you get notified as soon as a stable update is released and it’s up to you to install it when you’re ready, with a single click.
  • LEd loves Haxe: a powerful Haxe API which gives you access to fully typed values from your levels. It avoids mistakes like mistyping, renaming or removals: you see errors during compilation, not at runtime.

You can see LEd in action in the video below. The project is open source under the MIT license and hosted on GitHub.

[youtube https://www.youtube.com/watch?v=pYBWGt8wbsU?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Wick Editor Hands-On Review

The Wick Editor is a surprisingly capable free and open source tool that defies categorisation. At it’s core it’s a 2D graphic and animation tool, but it also has programmability features making it capable of creating simple games. It supports publishing animated GIFs, movies, soundtracks, sprite sequences and even single click html applications.

Wick Editor is described as:

The Wick Editor is a free and open-source tool for creating games, animations, and everything in-between. It’s designed to be the most accessible tool for creating multimedia projects on the web.

The Wick Editor is a hybrid of an animation tool and a coding environment, heavily inspired by similar tools such as Flash, HyperCard, and Scratch. It was developed in response to a growing need for such a tool for the modern web.

As mentioned the project is open source with the code hosted on GitHub under the GPL v3 license. The Wick Editor runs entirely in the browser and can be run by visiting https://editor.wickeditor.com/. You can also install locally and run using node and npm. You can learn more about Wick Editor and see it in action in the video below (or watch on Odysee).

[youtube https://www.youtube.com/watch?v=7xy_J9ZgJ3Y?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Castle Game Engine Hands-On

The Castle Game Engine is a pretty unique option. It’s a long running open source 2D/3D game engine for Pascal and Delphi developers with a recent emphasis on improving the editing experience. Hand and hand with the Castle engine is the Lazarus IDE and the open source Pascal implementation Free Pascal, which are required for Castle game development.

Top features of Castle include:

  • Use any 3D or 2D software to create your models in various formats: glTF, X3D, VRML, Spine JSON, Collada…
  • Develop cross-platform applications, for desktop (Windows, Linux, macOS, FreeBSD…), mobile (Android, iOS), consoles (Nintendo Switch) and other devices (Raspberry Pi).
  • Visual editor to design games UI and to build applications, powerful command-line build tool under the hood.
  • Optimized rendering with a lot of graphic effects (physically-based rendering, shadows, mirrors, bump mapping, shader effects, gamma correction…).
  • Build and edit the scene graph (X3D) at runtime. Create 3D processing, visualization tools and CAD applications.
  • Extensible system for game objects, with physics, creatures with AI and navmesh, and more.
  • Access numerous services, like in-app purchases and game services on mobile devices.
  • Create cross-platform user-interface with anchors and automatic scaling.
  • Code in modern Object Pascal, an efficient OOP language with cross-platform open-source compiler (FPC), compiled to a native optimized code.

If you are interested in learning more about the Castle game engine be sure to check out the video below (or watch it here on Odysee). The Castle developers have also recently released a document making it easier for Unity developers to get up to speed with key concepts in Castle, which is available here. If you are interested in getting started with Castle and Lazarus, step by step instructions are available here.

[youtube https://www.youtube.com/watch?v=GqTgbRa5Bq0?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Echo Engine Hands-On

Today we are taking a look at the open source cross platform 2D/3D C++ based Lua-powered game engine Echo. While Echo is very much it’s own engine, it has a very Godot vibe in the way your game scene is organised, taking a node based approach to game development. The engine is released under the very permissive MIT open source license.

From the project GitHub page, Echo is described as:

Echo is a new game engine, which used more industry-standard of nowadays for game development. The new design concept makes the engine simplicity to use. but more powerful. Scene manager is easy, No Entiy, No GameObject, No Component, No Prefab. Only Node and NodeTree.

In the video below we go hands-on with this active open source project. In the later half of the video we show how you can build the engine on Windows, before you begin however you will need to have Visual Studio 2019 with C++ support and CMake installed on your machine.

[youtube https://www.youtube.com/watch?v=UFlUkzqf030?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Microsoft joins Open Source Security Foundation

Microsoft has invested in the security of open-source software for many years and today I’m excited to share that Microsoft is joining industry partners to create the Open Source Security Foundation (OpenSSF), a new cross-industry collaboration hosted at the Linux Foundation. The OpenSSF brings together work from the Linux Foundation-initiated Core Infrastructure Initiative (CII), the GitHub-initiated Open Source Security Coalition (OSSC), and other open-source security efforts to improve the security of open-source software by building a broader community, targeted initiatives, and best practices. Microsoft is proud to be a founding member alongside GitHub, Google, IBM, JPMC, NCC Group, OWASP Foundation, and Red Hat.

Open-source software is core to nearly every company’s technology strategy and securing it is an essential part of securing the supply chain for all, including our own. With the ubiquity of open source software, attackers are currently exploiting vulnerabilities across a wide range of critical services and infrastructure, including utilities, medical equipment, transportation, government systems, traditional software, cloud services, hardware, and IoT.

Open-source software is inherently community-driven and as such, there is no central authority responsible for quality and maintenance.  Because source code can be copied and cloned, versioning and dependencies are particularly complex. Open-source software is also vulnerable to attacks against the very nature of the community, such as attackers becoming maintainers of projects and introducing malware. Given the complexity and communal nature of open source software, building better security must also be a community-driven process.

Microsoft has been involved in several open-source security initiatives over the years and we are looking forward to bringing these together under the umbrella of the OpenSSF. For example, we have been actively working with OSSC in four primary areas:

Identifying Security Threats to Open Source Projects

Helping developers to better understand the security threats that exist in the open-source software ecosystem and how those threats impact specific open source projects.

Security Tooling

Providing the best security tools for open source developers, making them universally accessible and creating a space where members can collaborate to improve upon existing security tooling and develop new ones to suit the needs of the broader open source community.

Security Best Practices

Providing open-source developers with best practice recommendations, and with an easy way to learn and apply them. Additionally, we have been focused on ensuring best practices to be widely distributed to open source developers and will leverage an effective learning platform to do so.

Vulnerability Disclosure

Creating an open-source software ecosystem where the time to fix a vulnerability and deploy that fix across the ecosystem is measured in minutes, not months.

We are looking forward to participating in future OpenSSF efforts including securing critical open source projects (assurance, response), developer identity, and bounty programs for open-source security bugs.

We are excited and honored to be advancing the work with the OSSC into the OpenSSF and we look forward to the many improvements that will be developed as a part of this foundation with the open-source community.

To learn more and to participate, please join us at: https://openssf.org and on GitHub at https://github.com/ossf.

To learn more about Microsoft Security solutions visit our website.  Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

Posted on by — Leave a comment

Announcing OAM, an open standard for developing and operating applications on Kubernetes and other platforms

Kubernetes has become the leading container orchestration environment. Its success has driven the remarkable growth of Kubernetes services on every public cloud. However, the core resources in Kubernetes like Services and Deployments represent disparate pieces of an overall application. They do not represent the application itself. Likewise, objects like Helm charts represent a potentially deployable application, but once deployed there’s no application-centric model of the running application. This need to have a well-defined and coherent model that represents the complete application, not just its template and/or its constituent pieces, is why Microsoft and Alibaba Cloud have created the Open Application Model (OAM) project under the Open Web Foundation.

OAM is a specification for describing applications so that the application description is separated from the details of how the application is deployed onto and managed by the infrastructure. This separation of concerns is helpful for multiple reasons. In the real world, every Kubernetes cluster is different, from ingress to CNI to service mesh. Separating the application definition from the operational details of the cluster enables application developers to focus on the key elements of their application rather than the operational details of where it deploys. Furthermore, the separation of concerns also allows for platform architects to develop re-usable components and for application developers to focus on integrating those components with their code to quickly and easily build reliable applications. In all of this, the goal of the Open Application Model is to make simple applications easy and complex applications manageable.

In OAM, an Application is made from several concepts. The first is the Components that make up an application. These components might be services like a MySQL database or a replicated PHP server with a corresponding load balancer. Developers can author code that they package as a component and then author manifests that describe the relationships between that component and other microservices. Components enable platform architects and others to build re-usable modules which are known to encapsulate best practices around security and scalable deployment. They also enable the separation of the implementation of the component from the description of how those components come together in a complete distributed application architecture.

To transform these components into a concrete application, application operators use a configuration of these components to form a specific instance of an application that should be deployed. The configuration resource is what enables an application operator to run a real application out of the components provided by developers and platforms.

The final concept is a collection of Traits which describe the characteristics of the application environment including capabilities like auto-scaling and ingress which are important to the operation of applications but may be implemented in different ways in different environments. An easy example of such differences might be a hyperscale cloud-provided load balancer versus an on-premises hardware load-balancer. From an application developer’s perspective they are entirely identical, while from the operator’s perspective they are completely different. Traits enable this separation of concerns whereby the application can run anywhere its necessary traits are deployed. Those traits can then be configured by infrastructure operators to satisfy the unique operating requirements of their environment (e.g. compliance and security).

In contrast to a more traditional PaaS application model, OAM has some unique characteristics. Most importantly, it is platform agnostic. While our initial open implementation of OAM, named Rudr, is built on top of Kubernetes, the Open Application Model itself is not tightly bound to Kubernetes. It is possible to develop implementations for numerous other environments including small-device form factors, like edge deployments and elsewhere, where Kubernetes may not be the right choice. Or serverless environments where users don’t want or need the complexity of Kubernetes.

Equally important, the specification is extensible by design – rather than the walled garden of a PaaS, or an application environment that hides the unique characteristics of where it is running. Likewise, OAM enables platform providers to expose the unique characteristics of their platform through the trait system in a way that enables application developers to build cross-platform apps wherever the necessary traits are supported. Hardware providers can similarly expose the unique characteristics of their hardware platforms via traits. The entirety of OAM was designed to prevent the “lowest common denominator” problem that can occur in portable platforms. Instead OAM is designed to make portability possible while ensuring that each platform can still surface the capabilities that make them unique and useful. OAM provides developers the freedom to balance between portability and capability among platforms in a standard way.

We’re excited about the initial work we have done to develop this application-oriented open model and the implementation for Kubernetes. The specification is currently being developed under the Open Web Foundation agreement, and our goal is to bring the Open Application Model to a vendor-neutral foundation to enable open governance and collaboration. If you want to learn more, please have a look at the OAM specification, and Rudr – the open implementation for Kubernetes – over on Github. This is really just a start. We look forward to hearing your feedback and partnering closely to bring an easy, portable, and re-usable application model to Kubernetes and the cloud.

Questions or feedback? Please let us know in the comments.

Posted on by — Leave a comment

How to contribute to Fedora

One of the great things about open source software projects is that users can make meaningful contributions. With a large project like Fedora, there’s somewhere for almost everyone to contribute. The hard part is finding the thing that appeals to you. This article covers a few of the ways people participate in the Fedora community every day.

The first step for contributing is to create an account in the Fedora Account System. After that, you can start finding areas to contribute. This article is not comprehensive. If you don’t see something you’re interested in, check out What Can I Do For Fedora or contact the Join Special Interest Group (SIG).

Software development

This seems like an obvious place to get started, but Fedora has an “upstream first” philosophy. That means most of the software that ends up on your computer doesn’t originate in the Fedora Project, but with other open source communities. Even when Fedora package maintainers write code to add a feature or fix a bug, they work with the community to get those patches into the upstream project.

Of course, there are some applications that are specific to Fedora. These are generally more about building and shipping operating systems than the applications that get shipped to the end users. The Fedora Infrastructure project on GitHub has several applications that help make Fedora happen.

Packaging applications

Once software is written, it doesn’t just magically end up in Fedora. Package maintainers are the ones who make that happen. Fundamentally, the job of the package maintainer is to make sure the application successfully builds into an RPM package and to generally keep up-to-date with upstream releases. Sometimes, that’s as simple as editing a line in the RPM spec file and uploading the new source code. Other times, it involves diagnosing build problems or adding patches to fix bugs or apply configuration settings.

Packagers are also often the first point of contact for user support. When something goes wrong with an application, the user (or ABRT) will file a bug in Red Hat Bugzilla. The Fedora package maintainer can help the user diagnose the problem and either fix it in the Fedora package or help file a bug in the upstream project’s issue tracker.

Writing

Documentation is a key part of the success of any open source project. Without documentation, users don’t know how to use the software, contributors don’t know how to submit code or run test suites, and administrators don’t know how to install and run the application. The Fedora Documentation team writes release notes, in-depth guides, and short “quick docs” that provide task-specific information. Multi-lingual contributors can also help with translation and localization of both the documentation and software strings by joining the localization (L10n) team.

Of course, Fedora Magazine is always looking for contributors to write articles. The Contributing page has more information. [We’re partial to this way of contributing! — ed.]

Testing

Fedora users have come to rely on our releases working well. While we emphasize being on the leading edge, we want to make sure releases are usable, too. The Fedora Quality Assurance team runs a broad set of test cases and ensures all of the release criteria are met before anything ships. Before each release, the team arranges test days for various components.

Once the release is out, testing continues. Each package update first goes to the updates-testing repository before being published to the main testing repository. This gives people who are willing to test the opportunity to try updates before they go to the wider community. 

Graphic design

One of the first things that people notice when they install a new Fedora release is the desktop background. In fact, using a new desktop background is one of our release criteria. The Fedora Design team produces several backgrounds for each release. In addition, they design stickers, logos, infographics, and many other visual elements for teams within Fedora. As you contribute, you may notice that you get awarded badges; the Badges team produces the art for those.

Helping others

Cooperative effort is a hallmark of open source communities. One of the best ways to contribute to any project is to help other users. In Fedora, that can mean answering questions on the Ask Fedora forum, the users mailing list, or in the #fedora IRC channel. Many third-party social media and news aggregator sites have discussion related to Fedora where you can help out as well.

Spreading the word

Why put so much effort into making something that no one knows about? Spreading the word helps our user and contributor communities grow. You can host a release party, speak at a conference, or share how you use Fedora on your blog or social media sites. The Fedora Mindshare committee has funds available to help with the costs of parties and other events.

Other contributions

This article only shared a few of the areas where you can contribute to Fedora. What Can I Do For Fedora has more options. If there’s something you don’t see, you can just start doing it. If others see the value, they can join in and help you. We look forward to your contributions!

Photo by Anunay Mahajan on Unsplash.