DEV Community: XANOZOID

Introducing Burger! A Game Programming Language

XANOZOID — Sun, 10 Sep 2023 16:05:59 +0000

Hello! I'm Xanozoid, and I'm excited to introduce the idea behind my language "Burger" (BGL: Burger Game Language). I'm writing this post today to provide a taste of Burger and ideas of what future BGL posts may contain.

Why Another Language?

I've been programming for a while. It was a year or so before Game Maker 8 was released (released Dec 2009), and I used that program almost daily for as much time as possible each day. So, by that, you can guess I got into programming because I liked making games - and you'd be right. Skip a couple of years, and Game Maker Studio comes out, and I'm still using it every day until it becomes unusable on my laptop. Not much longer, GM:S2 comes out, and I buy that too . . . well, something happened, and I felt like I had to move on.

So, what does this have to do with another language? Well, during the last few years I was using GM, I started moving on to new languages. It was a considerable difference from programming in GML - but in a good way (mostly). I found a LOT of programming languages I liked and a few I didn't. I've since dabbled with around 40 languages, just trying to familiarize myself with the options and the programming landscape. There were problems, though, and I was looking for something that didn't exist.

So, sorry to cut a long story short, but here comes BGL. What BGL does is solve a personal problem of mine. I'm looking for a free and open-source experience that captures much of my experience working with Game Maker (not the exact same, though). That's to say, Burger is an attempt at molding my experiences working in other languages, specifically GML, into something I can use to make games in a fashion I'm used to. In any case, hopefully, I can interest you in the project in this post: I'll go over (for now) a small detail of how it looks and some core ideas that further explain why I "want" "burger".

What does it look like?

🍔! No just joking . . . It's mostly a blend of my three most experienced languages. Without saying all three, I'll mention just two: JavaScript and Haxe. Do be fooled! If you're comfortable with either of those languages, you should only have to make a few small adjustments to take a bite at Burger!

So, what about the syntax and semantics? Like I said - it's a lot like JavaScript and Haxe, but since JavaScript is more widely known, here's a small example that exposes a lot of similarities to JS but a lot of differences.

method object(this.x, this.y) {
    return this;
}

method move_north_east(amt_right = 0, amt_up = 0) {
    x += amt_right;
    y -= amt_up;
}

function create_and_move_object(move_x, move_y) {
    var obj = new object(0, 0);

    for(var i = 0; i < 10; i ++) {
        obj:move_north_east(i * move_x, i * move_y);
    }

    // silly destructure
    var {x, y} = obj;

    return x - y;
}

So this is a small but silly example. If you're comfortable with JS you should be able to tell what's going on with a slight correction to your JS-lenses. That being said, the first thing that probably jumped out to you is there are two notations for functions. One is for methods, and one is for . . . functions. The simple explanation is methods have access to this, and implicitly so, while functions have no concept of a this.

Is this in BGL different from this in JS? I won't bore you with the details, but let's say it is somewhat different. The main difference is that this carries through method calls implicitly via some context. If that doesn't make sense, we'll review it in more detail in later posts!

While I still have your attention, though, you may have noticed a few more small things. Firstly, this in the arguments. That's a small trick I picked up from Dart (check it out!) - it just means "apply those arguments to this object". The last thing you may have noticed is the colon (:) in obj:move_north_east.... This is a reflection of a core idea in BGL that we'll discuss next - but it essentially means "apply this method to obj".

Core Ideas

There isn't necessarily a ton to Burger as a language. In fact, it probably "feels" like any other "game language", perhaps as one person put it: "Lua in JS clothes". There are things that separate it from other languages, however, and it doesn't just have "inspired" syntax/semantics. Though, it should mostly seem this way.

As a whole, this is a scripting language that will be embedded in another language made to be used for writing games (for BGE: Burger Game Engine). This is all intentional because it's pretty much how I imagine a game scripting language should work. There are other reasons for this, but mostly because I see Burger as something other than for game-specific things. That does not mean you can only use Burger in an engine, though - as this is the #1 thing that bothered me about GML. Also, If you have been wondering about the name up to this point, it's because Burger is a scripting language that will be written in Beef (A lower-level language also made for game development. Check it out!). Lastly, I am going with Beef because of its many targets - I want to target as many platforms as possible (for me).

So now that we got an idea of the "whole", what about core ideas of the language? We might say there isn't much to the language because it's like many other C-like languages, but that's not entirely true. At least there are a few things that stick out or even separate it.

All calls are (mostly) statically resolvable
Language designed for game dev
Portable and embeddable
capable of server-side programming
has a decent concurrency story via workers and coroutines

A few of these ideas we'll discuss over the course of the BGL posts but one thing that might catch your attention at first glance is the first point. Like mentioned earlier, we have a special syntax object:method. There's also object: { block }. Like said before, it's related to point 1 and means "object :(applied to) logic" - we pretty much don't have callbacks in this language, or other ways of storing methods/functions inside of data that moves around (I'm slightly lying), but that's the gist of it. There is a reason for this, but we will talk about this in more detail as more posts come out.

Timeline and future posts

Burger has yet to have an entirely clear timeline (I only work on it during the weekends), but I want to use it sooner rather than later. That being said, a lot of the front work has been done already, and it's mostly a matter of implementation at this point. There's a lot to cover about the design and work that's been done so far, and I intend on writing some posts down the line about the design decisions and overall language - as well as where the implementation is heading these coming weeks.

The next few posts I write will expose even more central ideas around Burger and the challenges/experiences of writing a language. So be on the lookout!

If Burger has captured your interest, please feel free to look at the repository! There, you may find a complete outline of the intended syntax/semantics and a working ANTLR4 grammar. Have further comments or questions? Continue them here or on the repo!

Thanks for reading 🍔😁

Hello! From: HaxePunk and me 😄

XANOZOID — Fri, 02 Aug 2019 22:12:32 +0000

Welcome;

Unless you're from the future, we haven't met; nice to meet you! I'm X.A.N.O.Z.O.I.D. (or xanozoid, xano, or xanoid, etc . . .) a programmer . For now, I'll skip the whole "about me" and leave that for another day.

Blogging

This is my attempt to bring you a weekly(or more frequent) digest of updates on projects I'm working on. As of this post, it will be primarily focused on the development of HaxePunk and then maybe a few posts here and there on a data-centric game editor, or the technologies involved (Haxe, Kha, Gui, rendering, cross-platform stuff).

So if you're interested in HaxePunk news, updates on an ambitious editor, or learning about the tech involved I'd appreciate a follow: dev.to / github 🙂

The state of HaxePunk

It's probably no secret that HaxePunk has been lacking when it comes to updates. The time of the original maintainers have passed, but HaxePunk lives on; maybe they'll come back in the future. Don't worry, HaxePunk's not dead; it has been getting a lot of care recently, as you'll see.

If you have been thinking about trying HaxePunk recently, you'll probably have a few questions. I'll be frank, HaxePunk is in a legacy state right now. The last published version was released on Haxelib and relies on old versions of Lime and OpenFl. That version was posted just before previous project maintainers retired from HaxePunk, so it has been a while since any fixes were published. On the other hand, I simply recommend using HaxePunk's dev-branch, the dev branch was brought back to life in May. While the dev branch for HaxePunk has been updated and now works with the latest Lime and OpenFl, there is a bug in Lime that prevents us from rendering with WebGL. Just keep that in mind; if you need HTML5 use the Haxelib version with the compatible Lime/OpenFL.

So, should you pick up HaxePunk? Well . . . a few things need to be clarified on the website, but HaxePunk has always had solid documentation, a simple to use workflow, and is still a well-tested engine. You can develop and publish games using the dev branch or the past version, so that's all fine. Right now, we're in a critical transition period, trying to pump life back into the project, which leads me to the next part. . .

The state of the transition

If you haven't heard, there's been a recent initiative to make HaxePunk relevant again. We've taken the task to utilize Kha, instead of Lime, while keeping the same API you know and love. We are doing this to simplify HXP's workflow and obtain the several benefits Kha has to offer: support for desktop, web, mobile, consoles, and native graphics abstractions . . . a compiled cross-platform shader-language, platform-consistent input, and more.

We started this ambitious transition back in June and, while there have been some bumps along the way, we're still making progress. We presently have standard input working and a project that compiles. This may not seem like much, but it's the perfect starting point for us to proceed with our next steps.

The features that aren't fully-operational yet are: rendering, audio, the asset and config pipeline, and a few things we've yet to see. It is technically possible to use about half or more of the features available in HaxePunk, but a videogame isn't much without video. Put simply, the core of HaxePunk has been left untouched and we're rewiring the lower-level stuff that's hidden from the core API.

There's a surprisingly small number of tasks to finish before we can start beta-testing this upcoming version. This isn't to say it won't be a couple of weeks or months until it's in a beta-state, but there's a straight-enough path for us to pursue(a huge thanks to Matrefeytontias). This may not be a completely accurate picture, because the majority of work left to be done is with rendering. Matrefeytontias is our rendering-guy, so it's up to him to dig into that. It's just that there's a lot of details to consider moving from the Lime version that causes quite a headache. No need to worry though! Matrefeytontias is confident about this and has already shown promising results, so a few weeks or months is still in the picture. Maybe we'll have a gift for everyone before the New year.

I would have loved to introduce this blog in an experience-focused way, instead of a summary of our work, but that's what happens when you get busy. My next post will have more trial-error/experience content; this was just my best attempt to brief you all of what happened and what is being pursued immediately.

HaxePunk's Future

We have a lot of ambitions going forward! Yeah, we could have just kept working on the Lime version. Yeah, we also could have supported both Lime and Kha. But we didn't, so why? We chose Kha for the future, we dropped Lime because it won't be necessary after Kha. It's blunt like that, and for a good reason, but above all else, Kha is portable. Thanks to Kha being an "Ultra portable multimedia framework", HaxePunk will have all of the power it did before with much, much, more reach. Picture it like HaxePunk was a train conductor, but later decided to become an airplane pilot - just as capable but with unlimited destinations. Thus our primary goal with HaxePunk is making it future-proof, giving it a new foundation for it to expand on our terms to be powerful and native across several existing platforms - and those yet to be known.

We're focusing on making the #KhaHaxePunk version usable right now, so you may be wondering if any other things are coming out for HaxePunk. I should bring attention to the fact that there is a slight difference between Matrefeytontias and me as far as goals are. We are both focused on making sure HaxePunk is usable, stable, and powerful. We both agree that any changes done in the transition should be minimal. Where I start to verge is on features and the future after the KHA-port. Many ideas sprung during at the start of our journey, as all big initiatives create some sort of hype, but those have been taken out of the main picture and we'll come back to consider their appropriateness.

I'm still going to give you a taste of my ideas though, so here's a list of things I want to bring to HaxePunk (none of these are expected to be officially supported, or even done - they're just "cool" ideas that are fun to share)

There's a lot more to talk about in the future, especially over the process; so, stay tuned because I'll be covering the weekly experiences we have going forward!

Fin

Thanks for reading! This took more time to get up and running than I'm willing to admit. From the writing, formatting, revisions, and figuring out how I want to distribute/publish this article it's taken nearly a week to finally choose something and that something was dev.to. As you probably guessed, that does mean this post is a week old; so I might publish yet another article this weekend depending on how busy I am.

This was my first ever blog post or anything of this nature, so I'm hopeful it serves its purpose! If you have any questions, comments, or criticisms or anything at all feel free to do so! I'm really looking forward to your responses 😄.

Since I'm hoping to reach out to you guys in the Haxe community, this may be a good place for us all to discuss and write about our developer experiences (if you're into that sort of thing). I decided to come to dev.to instead of my-own-site/medium/WordPress because it seemed to be the most fitting/friendly for this kind of material. I'd love to see some more writing from the Haxe community so let me know if you do!

For those who have no idea about any of this, I encourage you to visit https://www.haxe.org. Haxe is a unique and mature programming language that transpiles to other languages like JavaScript, Java, C++, and more; it has a number of use-cases like for web-development, game development, making cross-platform apps and so much more. Have a look around, we're all happy to see some new faces and say hi!