Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

What Language & Engine are You Using?

A topic by NorthStateGames created Feb 12, 2023 Views: 832 Replies: 24
Viewing posts 1 to 23

Curious to see what language and engines people are using this year?  Last year I used GMS2, as that's what I had the most experience with. I've since gone down a rabbit hole of coding in Lua and Javascript and I'm leaning toward an engine-less Javascript framework for the jam. Been experimenting with expanding the scope of the Broughlike JS tutorial to see if it might work for a more traditional styled RL. Love2D or Pico-8 are my backup plans as I sketch out scope for the 7DRL, hoping to do something with a western theme. 


Would love to hear what others are planning to use!

I'm thinking of either using JSRL (if I go with turn-based) or Unity (if I go with real-time).

If I end up using JSRL I might migrate it to TypeScript the week before the challenge.

I'm not sure i'll take part in the challenge this year, but if i do i'll use vanilla js with my "old time friend" ezjsrl [basically my version of rotjs coded during past 7drls] or plain c.

(2 edits)

Maybe i'll go with  !!!!!PLOT TWIST!!!!! pen, paper and dices! This year i've not found a good coding idea ... we'll see what comes to mind.

(1 edit)

I'll be using the Python3 libtcod tutorial tuned with enhancements learned from other tutorials (mainly Trystan's AsciiPanel and Rust RLTK tutorial).

I don't like this tutorial a lot, but as me and my children will be making their own 7DRL, I built a "standard" engine and then each one of us will "customize" as our needs. It seems cheating and an easy task, but for the 7DRL I'll be working as a project manager with my son and daughter, building my game, helping them to build theirs, and also with regular job... It can be fun! :D

P.S.: Actually we are designing our games: getting ideas, themes, choosing enemies... But all over paper, no coding is allowed! And when the 7DRL starts, straight to implement and test the games :)

(+1)

This sounds awesome!

(1 edit) (+1)

I've completely moved over to Godot for most of my game development, so I'll be using that.  In the past I used C, Love2D, or Pico8.

Linux, C, ncurses.  Old-school. :)

C++ and sfml

(+1)

If i join the jam I'll be using GODOT

C + SDL2

I only have ever used Unity/C# so that's what I'll be using.

This is going to be my first game jam and I'm going to try Unity

C++/libtcod

I'll be using C++ with TileGameLib

I'll be using Godot. Before I've used Labels and TextEdits to make entirely text based roguelikes (all unfinished), but now I wanna make it with pixels. I'll likely be reusing some proc gen scripts and sprites I've made well before the jam.

I enjoyed using PixiJS for the last 2 years, and will be using it again this year.

I'll be using either Unity or GDevelop. 

GDscript in Godot

Deleted post
(+1)

C# and Unity - it's all I know =D

Leadwerks- c++ for the procedural plotting and LUA  for the game scripting.

I'll be using Unity and C#. I believe I have the best change to get something finished with Unity. I try to stick to what I know, so that I could concentrate on making the actual game, but my Unity skills are also lacking a bit. 馃槉

I'm researching writing a cross-platform, text-rendering engine using GLFW + Vulkan in C.
It should support building, running, and cross-compiling on Linux, Windows, and MacOS. 

I've prototyped a cross-platform, monorepo build tool for the project which parses linker flags from modules and calls gcc\clang\msvc + cmake. It is implemented in a single file which the developer compiles then calls to build everything else.

I've got pixels on screen and keyboard support, but no text rendering or layout yet.

Researching stb_truetype, freetype, harfbuzz.

(1 edit)

To draw pixels with vulkan, I am using vkCmdCopyBufferToImage to copy the data  from the current frame's memory mapped pixel buffer  to the internal swapchain image, without setting up a graphics pipeline \ rasterizer. For whatever reason this is faster than using SDL_Renderer.

I might setup a rasterizer anyway in order upload a texture atlas ( sprite sheet for baked font characters), in order to render text using a textured quad per character.

Another idea is to possibly use FreeType to write pixel data on CPU directly to my memory mapped pixel buffer, if it can support the right output format.

A third idea is to render text on CPU using an extra internal pixel buffer saved between frames, then blend pixels from multiple frames at an offset when copying from the state buffer to memory mapped buffer, to implement temporal anti-aliasing and possible pixel format conversion.