# The Game Dev Thread



## TedEH (Aug 29, 2017)

I know lots of people on here play games, but does anyone else here _make _games? I think I've talked on here before about wanting to make some music-based games, but never got any of those ideas off the ground. I'm starting a new project, not music related at all, but I'm actually making some progress this time, and I figure having some game-dev-centric conversation will keep me motivated to continue. Unfortunately, forums for game-dev tend to be not even close to as active as this forum is soooo... here I am. 

For anyone who's interested, I've decided to go the long way around this time- no Unity or Unreal or anything- just OpenGL and WinAPI. I haven't decided on what to use for audio, but I'd like to come up with a way to at least partially generate the audio on the fly- or at least modify/mix the audio in game depending on context.

Gonna make a weird game that basically amounts to "just the side-quests". Basically it would all take place in a small town where there are a whole bunch of side-quest-style story lines you can follow, but a bunch of them conflict with eachother in terms of goals and timeline, so committing to certain stories means you won't be able to complete others in that playthrough. I have some ideas of how to tie each story/sidequest to a particular goal or need the player might have, so the collection of quests sort of ends up representing the players attempt at living in a balanced way. No idea if I can make that "fun", but we'll see what happens.

Anyone else here make some games? Would like to hear what people are working on, or what cool ideas people might think would make for a good game.


----------



## bostjan (Aug 29, 2017)

I made a PC game a few years ago that never got past beta (https://sites.google.com/site/petethepenguingame/download). Just flat out no one was interested in trying it, even though it was completely free. Prior to that, I had never publicly released anything. These days, everything has to run on Android and iOSmobile, which I know nothing about.


----------



## TedEH (Aug 29, 2017)

^ Can't download it immediately cause I'm at the office, but I can give that a shot once I get home. Made with Allegro I guess? (Based on the .dll listed on the site)


----------



## bostjan (Aug 29, 2017)

Yeah, this is going back to ~2012 or 2013, made only using free programs and utilities. My programming background in secondary school was in Zenith Pascal, and then at the university, we all used Fortran 77, so it's all very old object-oriented code. The very first version of the game that I made had all of the game data and so forth wrapped into the executable file. I never added much in terms of save games nor settings.


----------



## TedEH (Aug 29, 2017)

bostjan said:


> it's all very old object-oriented code


I think that's pretty standard for games now. I know I've been seeing lots of youtube videos pop up about how "object oriented is bad!" and "encapsulation is bad!" and "all of these things I don't like about this language is bad!" etc., and while I get where some of it is coming from, I'm not sure I'm convinced that object-oriented code is bad. Realistically, if it gets the job done, if it works for you, then it's good.


----------



## Dayviewer (Sep 3, 2017)

I work at a company focused on making mobile F2P games, we're with 40 people working on multiple games at once. We're not doing match 3 ripoffs though  we really try to focus on quality with a twist here and there.
We have something new that's launching in about 3 weeks so I'll be sure to post that when it hits 
As for the work I do I'm a 3D artist but I do some FX and 2D ocassionally as well, and do a lot of in-engine work too, we work exclusively with Unity.

Quite awesome that you guys are straight up building something without an existing engine, you don't see that a lot these days so thumbs up 
The side quest idea sounds cool, but it might help to still have something centric going on to connect everything together. Maybe like something that happened in the town or something that's still going on.


----------



## TedEH (Sep 5, 2017)

Dayviewer said:


> The side quest idea sounds cool, but it might help to still have something centric going on to connect everything together. Maybe like something that happened in the town or something that's still going on.


Yeah I'm definitely messing with some sort of central event that starts the game, but I'm not married to the idea yet. There's definitely a theme that ties the stories together, but it doesn't have to be a specific event per-se. It would be more like something that happens to the player, and each side story reflect on a different aspect of how that affects the player. I'm arguably not a good writer by any stretch- I'm more of a technical person, so I'm hoping to build the world/story very slowly as the technical parts of the game come together. Like instead of saying "here's the world, lets put some stories in it", I want to just start building the stories/missions/quests/whatever and have the world build itself around that.


----------



## TedEH (Sep 5, 2017)

I tried the penguin game - a little rough around the edges, but still pretty entertaining. I like how you seem to have infinite bombs, the count just keeps going into the negative .


----------



## bostjan (Sep 5, 2017)

TedEH said:


> I tried the penguin game - a little rough around the edges, but still pretty entertaining. I like how you seem to have infinite bombs, the count just keeps going into the negative .


The bomb counter is easy to fix. The "rough around the edges" part is a lot less easy to fix, and I really don't know if it's worth it.  Ages ago, I posted it on a site where people post in-development indie games to review each other's work and, while people were reviewing everybody else's stuff (which I thought was on par with what I had done), not a word was posted on mine until something like 6 months later, and even then, it was something nebulously negative, like "too dumb and too hard" or something like that. By then, I already had none of my friends nor coworkers having the time or interest to try it, so my motivation to do anything with it had diminished.
I'm sure another couple dozen hours cleaning it up and adding on-screen instructions and cut scenes would make a noticeable different in the quality of it, but I've got so many other things to work on that seem to be more important right now.
Thanks a thousand times for giving it a go, though!


----------



## ferret (Sep 6, 2017)

I used to make MUDs, and later, CS and CSS mods. For a while, I was lead developer of one of the WC3 mods for CS. I was a developer for SourceMod as well. Most recently I made a couple of Fallout 4 mods. I tend to have pretty big issues with motivation and inspiration though.


----------



## bostjan (Sep 6, 2017)

I made some Doom mods and Doom maps, going way back. Maybe some of the older forum users might have even tried one of my mods. I made one that replaced the rocket launcher with a gun that threw live Nazis into the room, and another that replaced the plasma gun with a flamethrower. Those were good times. I also made the mod in Heretic, where the golem's spirit sprite was replaced with another golem, so every time you killed the golem, instead of a moaning ghost floating away and vanishing, another golem burst out of the skin of the defeated golem. That was my favourite of my own mods...

I never dreamt of working for a video game developer, because I always preferred jobs working with hardware. I have a lot of respect for you guys who do. Software changes so fast, it can be blinding. My own programs in college were almost always clones of something else - Space Invaders, Combat, Pac Man, Dragon Warrior, Crystalis, Number Munchers...partly because I've always been terrible at artwork, so it was just so much easier to rip off other people's sprites. I would never publish any of that work, of course, for fear of the legal consequences. Some of the Star Wars games I made in high school got distributed around by the kids at school, but when I put the extra work into developing my own ships and weapons and stuff, and used the same game engine, I only got negative feedback about things looking weird (which, truthfully, it did), but that's a very good thing, since I wouldn't have wanted to pursue that as a career, knowing that my code is only about 80% as good as a professional's, and my artwork not anywhere near up to snuff. At least I'm fairly proud of the music I put in my own games. 

When you are developing a game by yourself, how many man-hours does it typically take you? That's the part of this that seems most daunting to me. For me, throwing 100 man-hours into a very simple game's development is typically just enough to decide whether it might be worth throwing another 100 into it or not.


----------



## TedEH (Sep 6, 2017)

^ Honestly, 100 hours might not even be close to enough for a polished game, but it really depends. I've probably put about 100 hours into my current project and there's not a ton of "game" to show for it. There's an animated character who can walk around, run into some poorly drawn houses and trees, and interact with identical looking characters. Lots of underlying systems that will eventually support something cool, hopefully, but it all comes down to scope, level of polish, what tools you're starting with, etc. You can arguably throw together a functioning game in Unity in a day, but you'll likely have an un-maintainable mess of a project with very little depth to anything in it. I spend a good full day not super long ago just coming up with a solution for preventing certain things from getting loaded redundantly. A couple of short days went to implementing text rendering. A few days went into an async task system. I spent over a week building the system I'd use for character animations, and it's only in a very early state where it's juuuuust usable. Granted, I knowingly took the long way around, not starting with an engine, but a solid game of any real depth or scope is a huge time investment- even if you're starting with an engine. Being a personal project grants me the freedom to take the long way around and dive into every tiny details because I want to, so I can learn and challenge myself, and without worrying if I ever finish it, but in a professional setting, you'd not approach things this way.

Depending on some context, I've put together some decent games (for work, not as personal projects) in as short as 3-4 months of full time work, not including creation of the artwork and sound assets. But these shorter-time-frame games were done either in Unity or an existing framework/engine/etc., and usually browser games. They were limited in scope to just a handful of mechanics, usually no concept of different levels or maps, and the artwork and audio was provided for me.

The biggest setback for me is usually that I'm a terrible artist. My temp art looks terrible.


----------



## bostjan (Sep 6, 2017)

My eldest son made a game in Unity with two friends. He kept the character graphics extremely simple, but wholly workable, and kept the game to four short levels, and I was blown away that it only took three teenagers a week of class time to develop it.

The Penguin game took me about a year and a half to get it to the point you saw. Of course, I would work on it in spurts, but I probably had 400-500 hours into it. All of the graphics were done pixel-by-pixel in MS Paint and done completely from scratch, which honestly was the lion's share of the time I spent. Next was coming up with AI. The initial enemies were very easy (walk left or right, or walk toward the character), but later on, once there were different enemy attacks, it got reasonably complicated. I did level design by a lot of trial and error, and the overall story of a cutesy penguin who runs off to save his penguin-girl-friend and gradually works his way through colourful worlds, then grayer icy levels, and ends up in a lovecraftian horror setting took me five minutes to think up. I'm sure there are much better thought-out story lines. The controls and physics seemed like a huge task, at first, but really were nothing in the grand scheme of time spent on the entire thing.

Just before that one, I worked a lot on a game where you played as a chimpanzee in a sort of "Legend of Zelda" action-RPG thing. I made the world map huge, and made it wraparound, to mimic a sort of globe-shaped Earth. The major pitfall I found was that adding enough detail into every screen to make it consistently interesting for the player was a monumental task, so I gave up on it, but I did recycle the world map for another abandoned project later. Anyway, easily over 100 hours went into that, just to kill it with no remorse.

I guess I'm glad I'm not the only one who struggles with the artwork aspect. Actually, that's giving myself way too much credit. I am totally clueless when it comes to artwork. The penguin game looks okay-ish, I think, but it is, by far, my best artwork.


----------



## TedEH (Sep 6, 2017)

The Penguin art definitely made me think of the kind of games you'd run into on like a Windows 95 shareware collection or something like that. Art really strikes me as the sticking point for a lot of indie/one-person dev projects. Audio unfortunately often ends up as an afterthought.


----------



## TedEH (Sep 6, 2017)

bostjan said:


> it only took three teenagers a week of class time to develop it


I'm usually pretty impressed by stuff that comes out of game jams. I've never been to one of those, but I did a couple of jam-style overnight sessions for school where we'd basically just pull an all nighter to get something working that we needed the next day. There's always sacrifices being made for the speed though- be it code quality, scope or depth, personal health, etc.


----------



## mikernaut (Sep 24, 2017)

I'm a game dev artist with 10+ years experience, but I keep getting laid off every 1-4 years .  Upper management seems to not care about quality and only about making a quick buck sadly.


----------



## TedEH (Sep 25, 2017)

^ I hear stories like that pretty often. People who will work one place for a year or two, get laid off, work another place for a bit until that contract runs out, try to do the indie thing for a while, become broke, go back to working at a place that only needs them for a year, etc., repeating for basically forever. I arguably got lucky to find a place that values their people- they do whatever is in their power to keep their employees as long as possible, and keep them relatively happy, avoiding things like crunch and overtime, allowing us to do side projects, etc.

I've been making a lot of progress on this side-project game I'm working on. Last year I was too focused on recording to do any at-home game dev, but this year I've put the personal music stuff aside a bit and instead have been working on putting together a game I've had in my head for a while. Over the last couple of months I've built up a little game engine while just sort of passively thinking about (and occasionally documenting) the kind of story the game is going to try to tell. A lot of the little pieces are coming together to where I can start making content soon - I've got a little keyframe animator, a layout/level/etc. editor, this past week I put together a setup that lets me use Javascript/Ecmascript to do some of the scripting, since I was already defining a lot of the game data as json anyway.

Eventually, once I've got some audio in, I like the idea that I can combine this whole world of things with the music production side of things- I don't often get to create the music for games, and I feel like it gets overlooked pretty often.


----------



## Quaker763 (Oct 20, 2017)

I've been working on a complete engine remake of SILENT HILL 3 with a guy in Germany for the past year. Currently it can load (most of) the assets from the game, but there is still a _long_ way to go before we actually get any gameplay going. I'm currently reverse engineering the actual binary, but stepping through code in IDA is really inefficient haha. So far I've found code that executes during an attack, but my god, it is an absolute cluster of shit. KONAMI should feel bad.

If anyone's interested (or dabbles in cpp14 and OGL3/4) check it out here!

https://github.com/Palm-Studios/sh3redux


----------



## Quaker763 (Oct 20, 2017)

mikernaut said:


> I'm a game dev artist with 10+ years experience, but I keep getting laid off every 1-4 years .  Upper management seems to not care about quality and only about making a quick buck sadly.



It really sucks that it's come to this tbh, even companies like VALVe don't care anymore...


----------



## TedEH (Oct 20, 2017)

Quaker763 said:


> So far I've found code that executes during an attack, but my god, it is an absolute cluster of shit. KONAMI should feel bad.


Are you judging the original code quality from disassembled code...?


----------



## Quaker763 (Oct 23, 2017)

TedEH said:


> Are you judging the original code quality from disassembled code...?



Algorithmically, yes. The HEXRAYS decompiler is rather good at showing _how_ the original code was structured (in C), not the actual code quality itself. Though obviously the compiler they used has probably mangled a lot of what the original code looked like, a lot of the subroutines that have been reconstructed look pretty hacked together. Probably explains why the PC port has a heap of performance issues.


----------



## TedEH (Oct 23, 2017)

Quaker763 said:


> a lot of the subroutines that have been reconstructed look pretty hacked together. Probably explains why the PC port has a heap of performance issues.


Wasn't the original game for the PS2 or something like that? PC and Playstation are very different beasts to make games for.


----------



## bostjan (Oct 23, 2017)

A PS2 game would have been developed on [email protected] using a specific software development kit. The PS2's structure is based off of a form of assembly language with built-in vertex-based 3D graphics. Games like that sometimes translate okay into C, but often times the translation is messy and doesn't run very well. Assembly language on a PC is a lot less forgiving, since there are a lot more addresses that have nothing to do with gameplay, and poking them carelessly can be very destructive. On gaming consoles, especially older ones (PS2 was kind of a turning point for that, though), assembly language is a lot more forgiving in the long term.

Anyway, disassembled and decompiled code in general can be overly frustrating to figure out. And to think that a game on the level of Silent Hill 3 was developed by roughly a dozen experienced people over the course of almost two years, it's not a trivial task to piece that all together. Good luck!

I tried to make my own 3D game once, from scratch, just for my own personal torture use. What I had hoped to turn out to be a real learning experience just turned out to be a huge waste of time. It did give me a completely new level of respect for whomever figured out how to make the Doom engine, since they started with virtually nothing and ended up with something that, at the time, was a quantum leap in 3D graphics.


----------



## Quaker763 (Oct 24, 2017)

TedEH said:


> Wasn't the original game for the PS2 or something like that? PC and Playstation are very different beasts to make games for.


Yes it was! They ported the renderer etc to Direct3D (DX8) sometime after the original PS2 version came out. It's a pretty good port, however it seems very rushed, and from what I've gathered from the disassembly, they (the 5 or 6 people porting it) were under the pump. It's interesting to note that a lot of the test assets are still included in the game files. 



bostjan said:


> A PS2 game would have been developed on [email protected] using a specific software development kit. The PS2's structure is based off of a form of assembly language with built-in vertex-based 3D graphics. Games like that sometimes translate okay into C, but often times the translation is messy and doesn't run very well. Assembly language on a PC is a lot less forgiving, since there are a lot more addresses that have nothing to do with gameplay, and poking them carelessly can be very destructive. On gaming consoles, especially older ones (PS2 was kind of a turning point for that, though), assembly language is a lot more forgiving in the long term.
> 
> Anyway, disassembled and decompiled code in general can be overly frustrating to figure out. And to think that a game on the level of Silent Hill 3 was developed by roughly a dozen experienced people over the course of almost two years, it's not a trivial task to piece that all together. Good luck!
> 
> I tried to make my own 3D game once, from scratch, just for my own personal torture use. What I had hoped to turn out to be a real learning experience just turned out to be a huge waste of time. It did give me a completely new level of respect for whomever figured out how to make the Doom engine, since they started with virtually nothing and ended up with something that, at the time, was a quantum leap in 3D graphics.



Interesting, I was under the assumption that SONY provided a heap of C libraries for the PS2? There's no way in hell this was programmed in assembly though, but I'll eat my shoe if I'm wrong. And thanks! I'm working on it in my spare time, but I'm learning a lot so far! Hopefully we'll have some 3D stuff real soon. All we really need from the disassembly is how they determine what level to load when, and how certain things like cutscenes and model head rotation (when Heather/James looks at something 'of interest') works!

Have you tried making some 2D stuff? I tried leaping into 3D a few years ago and I had the same problem until I made a few really dodgy 2D games haha. It is a very discouraging experience though, especially with the volume of stuff (including math) you need to learn.


----------



## bostjan (Oct 24, 2017)

Sony used their own proprietary development kit. If you paid the licensing fees , they'd send a copy of it. It's not like programming a game in assembly...

Although older game systems were done in something like assembly language. The SNES, for example, used a lot of hardcoding for almost every game. The PS1, if you recall, started out as an add-on for the SNES, then spun off on its own when Nintendo tried to fuck Sony over and Sony wouldn't have. So, Sony, trying to stand out from Nintendo, shook things up a bit, which is why PS2 game development started to revolutionize workflow, and game developers started coding in their own game engines with the PS1 and reusing much of the code to save a lot of time by not reinventing the wheel for every game. By the time XBox rolled around, consoles were essentially using C# with tons of powerful library elements. PS2 was really an inflection point in that evolutionary curve. A lot of developers complained about how cumbersome GameCube was compared to PS2, in terms of development.

Anyway...

In a 2D game, you have to make the game physics a certain weird way. If you make things realistic, the game is a lot more frustrating, so there is an art to conceiving how objects react to gravity and collisions in a 2D game - I think that if you take the mathematical aspects seriously, you run the risk of icky gameplay. Of course, there are tasteful ways to incorporate some real physics.

The game I posted earlier uses a pretty nice wrapper, which has all of the mundane stuff pre-coded for you, ostensibly with bits of it optimized in assembly. I've done such coding myself, and it's a tedious process, and it's not very "sexy" working for weeks on a library of subroutines that play music and sound effects in the background of someone else's game or whatever. The very first 2D games I made had sprites painted pixel by pixel by the game itself, which worked okay if the action was slow paced or if the background was black or the sprites were very simple. Once I figured out that I had to build something that would handle the graphics by painting in layers, using the extra non-display graphics memory to draw sprites off screen, etc., it made things look a lot better. Even so, my homebrewed graphics subroutines still took a second or two to load a new screen, which made it difficult to move the viewing area fluidly in both the x and y directions without a noticeable seam.

I think that remaking another game is a huge experience to go through. The first games I programmed were things like naughts and crosses and hangman, then I moved on to Space Invaders, Breakout, Combat, etc., and then finally tried coming up with my own stuff (which was laughable). My first game to use the wrapper was a clone of the first overworld area in Crystalis. It was trying to improve the sprites to look more 16bit than 8bit that got me making the graphics in the penguin game I referenced in an earlier post. If I had come up with the penguin game in the 1980s or early 1990s instead, it would have been a thousand times more difficult to make it, even though the look and feel of it is really based off games from that era.

I'd imagine that taking on something like a Silent Hill remake at an early stage, you'll either build up enough experience and confidence to make your own original 3D game afterward, or else you'll just get frustrated and run out of interest. I'm only saying that because I know I would not have the patience to take on something of that magnitude right off. But then, having a bunch of disassembled code to port into another language or whatever probably fast forwards you a couple years worth of grunt work.


----------



## TedEH (Oct 24, 2017)

Quaker763 said:


> however it seems very rushed, and from what I've gathered from the disassembly, they (the 5 or 6 people porting it) were under the pump.


When you're talking commercial games, everyone is always 'under the pump'. (I dunno that expression very well, but I think I get what you mean.) I'd like to say that games have time to do everything in the ideal/correct way, but they never do. Everyone working on them certainly tries, but there's always compromise.

I've never worked on a PS2, but I'd assume they had C or C++ kits for partners to work with. I don't think you can even get a dev kit (hardware) without significant cost. Not like the XBone where you can do indie work on a retail model. I have worked with the PS3 and 360 kits though - and never had to write any assembly, but they certainly come with their own sets of challenges.

I've got a friend who, for fun, make home-brew Genesis games- I don't think I have the patience to code that way for fun. 



bostjan said:


> In a 2D game, you have to make the game physics a certain weird way.


I've been using Box2D in the current project I've got going- basically just to provide collision detection, and to provide a bit of a sense of momentum when you stop moving (there's no jumping, it's top down-ish). Years ago, when I first started learning I though "bah, using a physics package is cheating! Unity is cheating! I'm going to do this from scratch!" I've since learned to embrace the idea of not reinventing the wheel. I still do more from scratch than I need to in personal projects (much more than I would if I had time constraints), but I think I have the wisdom now to know when being stubborn about things like that amounts to just shooting myself in the foot.


----------



## TedEH (Oct 24, 2017)

I just picked up a copy of Blood Sweat and Pixels, which is supposed to be a collection of stories and interviews that shed some light on commercial game dev process and the troubles involved. I haven't started it yet, so I can't confirm, but I've heard it illustrates the "every game's development is troubled, not just the ones you hear about" idea pretty well.


----------



## bostjan (Oct 24, 2017)

PS2 uses a VCL-(vector command line) oriented programming language. The PS2 could play PS1 games, so there were still artifacts from that era, which meant that certain things could only be addressed in assembly, but most of the programming was done in a compiler language. PS3 didn't have the PS1 compatibility mainly in order to work around those limitations for developers.


----------



## bpprox22 (Oct 24, 2017)

For anyone interested, this video talks about a TON of different topics within the commercial game lifecycle:


----------



## bostjan (Oct 24, 2017)

Diablo was such an influential game. Seeing him play that rough demo was awesome, but I was shocked that, even with the graphics, music, voice acting, and everything like that being so smooth, the gameplay itself was completely broken. 

Wait, Battlenet ran on one computer?! Holy smokes!


----------



## Nyx Erebos (Oct 29, 2017)

I'm a game dev in Tokyo in a company where we mostly do mobile/web games for bigger companies. And right now as I'm typing that, I'm setting up the unreal engine on ubuntu to do some personal game dev. I mostly want to teach myself the art side of games (models, animations, textures...) and hopefully make a prototype that's worth expanding upon. I lost the drive to do my own stuff for the longest time since it's quite comfortable to just dev at work and play games at home. But I just bought a brand new blade 14 to force myself to get back to it .


----------



## Nyx Erebos (Oct 30, 2017)

And I'm surprised on how smooth everything's working. I installed ubuntu on a usb drive and then compiled UE4 on my main drive (with windows so it's a different file system). I haven't tried to load the same project files from both linux and windows but after reading about it, it seems that they're os agnostic so I am hopeful.


----------



## TedEH (Oct 30, 2017)

^ I've been doing the work on my game in Ubuntu for the last few weeks, and then going back to windows every once in a while to make sure stuff still works. I don't know if Linux has gotten more user-friendly or if I just know what I'm doing this time, but it's been a less painful experience than the last few times I tried to make the jump to anything non-Windows. Porting stuff back and forth has been surprisingly easy, even without the advantage of starting with an engine that does most of that work for you. VSCode being a thing now has helped a lot.


----------



## TedEH (Aug 31, 2018)

I saw some other posts talking about game jams and things, which I figured might make a good opportunity to bump this thread with some progress on the thing I was working on before. I could talk a bunch about intended design-y things I want to do with this project, but it's mostly turned into a "I have a free weekend and want to noodle with the fun sides of making games" project, so there's no real "game play" to speak of.... but I did recently spent a weekend to make a whole time-of-day system with lights and shadows and things, and I was pretty proud of that, so I've been showing it off when I can:



There's a bunch of stuff "under the hood" that isn't interesting to talk about, but that drives the timing of the whole thing (there's a date/calendar/schedule/etc system, so every time the day flips over, the game has registered on some level that a day has passed, and you can look up what day of the week it is, whether or not your player has scheduled appointments that day, etc.), and I tried to time it so that the sun would come up at vaguely the right in game time and set around the right time, etc. I want to do another pass at some point to make the colours shift to something a bit more accurate to what a sunrise/sunset should look like.

But, all that to say- I made vaguely cool looking thing, I think.


----------



## mlp187 (Sep 2, 2018)

Hey man, good work!!! Stoked to see your progress. The transition from light to dark and back is super smooth. 
You’ve inspired me to finish my project!


----------



## ixlramp (Jul 13, 2019)

I'm part of a team developing a free, open-source, easily-moddable Minecraft-like voxel game engine and games that run on it.
The game engine has a silly name, 'Minetest', that stuck very early on when it was an experiment by the the initial single developer. It's such a bad name it's almost good. Minetest is possibly the most popular Minecraft-like free open-source voxel game (engine).

It's written in C++ and runs faster and smoother than MC, ideal for lower powered machines.
It has very easy but powerful modding, using a friendly scripting language called Lua, children are able to create mods. The games for the engine are completely written in Lua. It's much more like 'electronic Lego' than MC is.
There's a large community and 1000s of mods and games available at the forum.

One big advantage is the world dimensions are 62000 cubes (metres) in all 3 axes, whereas MC has a vertical limit of only 256 cubes. It's perfect for experimenting in a large cubic space, for example, one of the world generators (written by me) creates crazy landscapes using various 3D fractals.

Sorry this sounds a little like an advertisement.

Developing a free open source game is very hard work in terms of dealing with the huge number of people (potentially everyone on the web) who is involved in development. Also dealing with the unrealistically high expectations (expectations equal to that of a commercial game) of a game maintained by a very few unpaid developers in their very limited free time.
Just a warning, think twice before making a game open-source, it creates 'people hell', and i'm not a 'people person' =)


----------

