Game Developers of Kiwi Farms

[DumbDude43]

Fuck it, I'm downloading UE. Probably going to give up learning it in a couple weeks but it's something to do at least.

depending on what kind of game you are thinking about making, it might unironically be faster to just do it yourself rather than learn unreal from scratch (if you have good programming knowledge in an appropriate language)

 

[SSj_Ness (Yiffed)]

Easier said than done, but if more pixel art games were ambitious the complaints would dry up. A good art style and solid presentation go a long way, NES's Ninja Gaiden had like 20 minutes of quality pixel art cut scenes and an epic story nearly 40 years ago:

And then you have...whatever this is:



Maybe it's really fun but I don't wanna even try it.

 

[UERISIMILITUDO]

One of the worst things about programming is dealing with the interfaces designed by idiots. Video games, however, can free themselves from most of this nonsense by virtue of having little or no need to interact with the underlying system. I highly recommend targeting old systems to write video games, rather than dealing with tens of millions of lines of shit that doesn't work worth a fuck.

I've greatly enjoyed writing CHIP-8 games. CHIP-8 is a virtual machine from the 1970s, and very simple. It's easier to write a graphical program in this little machine code, than to deal with X11 and other nonsense. I wrote the development tool I use by myself, not an assembler, and the smallest working game I've written is a mere forty octets, nineteen instructions and two data octets; I could've reduced it to thirty octets and no explicit data octets, but there was little point, and it greatly reduced the flexibility of customization.

Here's a WWW implementation that's easy to use:

http://johnearnest.github.io/Octo/

Unfortunately, this reference is only available on MicroSoft GitHub now, but it looks decent enough at a glance:

https://github.com/mattmikolay/chip-8/wiki/CHIP%E2%80%908-Technical-Reference

Regardless, I'll be here to answer any questions.

One of my struggles as an indie dev has been a perpetual loop of people going "I don't care about graphics, I only care about gameplay. I'm not playing that, the graphics are shit." What's more, the styles themselves are considered a problem.

CHIP-8 and similarly old systems are an extreme here. The monochromatic screen is sixty-four-by-thirty-two, or one-hundred-and-twenty-eight-by-sixty-four with Super CHIP-8, which also adds scrolling instructions and a few other things. Oft-times, the player will be represented by a single pixel, and some kinds of games simply can't be made under these constraints. Regardless, this is extreme distillation of gameplay.

Lately, I've been looking into 6502 programming for the Atari VCS, but have yet to start. I'll be writing a targeting of my machine code development tool for the purpose soon enough.

I'll also link to this very large collection of very simple games:

https://www.asahi-net.or.jp/~cs8k-cyu/browser.html

I find reading and writing files in general to be the most tedious and annoying parts of programming things. I always get hung up on the best way to structure my data and format my data files. I find it's something you should try and plan at least a little bit near the beginning.

Don't think in terms of files. So, the easiest thing to do is to store nothing. The second easiest thing to do is to store a score and nothing else. After that, one can be well served by structuring the game into well-specified sections to massively trim down the state space; or taking the easiest way out nowadays and storing the entire dynamic game state, if the underlying system permits that approach. It's funny, how so many classic characteristics of video games were caused by these kinds of constraints; it's easiest to only track a few details and require the player to always start in the same spot, or designated save rooms.

Data management in general is something you should plan early because most games have a ton data that you're manipulating and if you haven't figured out how you're going to store and access that shit before you need to start storing and accessing that shit it can get out of control pretty quickly.

Using a machine code like CHIP-8 will teach this very early on, because it's impossible to do much of anything interesting without understanding it.

 

[Judge Dredd]

Sorry for the wall of text.

What do you guys dislike about the Godot UI famework? Seems like a pretty good system to make scalable GUI but idk.

In tutorials, it makes a simple menu fine. For anything more complex it falls apart and is prone to bugs.

I'm going to give a fictional simple example to explain what I mean. To make a row of 5 buttons, you put a container, put a horizontal divider node, then any button you drop in will automatically be sized sorted. Great! But when I apply it to a game, suddenly one button expands to cover most of the screen with the other 4 squished into the corner. "Just uncheck expand to fill." Now that button is squished and the rest are fine. "That's easy to fix, just check expand to fill."

In a more realistic example. Making start-options-quit buttons on a title screen works fine, but trying to make a Resident Evil style inventory system starts to fall apart any time the resolution is different. Or I can just lock the games aspect ratio, which would result in black bars on anything that's not 16:9 but at least the inventory doesn't break. I wanted an ammo counter on a gun (like in Halo) and the solution was "just use canvas layer, and then use that canvas as a texture". Of course, this didn't work.

Just recently, I fell down a rabbit hole of trying to get screen effects and transitions to work. All these fancy wipes, but the tutorials and docs are just drawing a big rectangle on the screen, and change the alpha value to get a fade in or fade out effect. But how do I do a wipe or a Zelda like screen scroll effect? "Just have a black rectangle and animate the alpha." That brings me neatly to-

Also, asking for help in Unity is obnoxious. You so very often get reply by some turbo autistic retard that can't even comprehend questions and make an answer in general terms. It has to be super specific.

"How do I do X?"
"Do Y."
"But Y doesn't do X."
"Don't do X."
*replies closed by moderator.*

My biggest success was a web game that got 17k plays and a rating of 4.6 with 18 votes on itch.io. So, very modest.

Congrats. My biggest success was a Half-Life mod that got 500 downloads in about a week, and now sits at around 1000.

of course he won't get anywhere on it's own. blindly copypasting code from a tutorial only gets you so far.

I get that, but this mythical proper way of learning to code evades me, and the few answers I get are some online course that costs triple digits to start.

---

It seems that there is talent here in the forum. How come you haven't banded together an give it another shot other than the Yandere Simulator clone?

I kind of did. That's what the Doom community mapping project was about. I'm also tempted to do a "8bit" jam at some point.

As for Yandere Simulator specifically. Such games are a large undertaking and I think that effort would be better spent elsewhere.

---

Cyclops Level Builder is a huge boon to Godot users

Never heard of this. Will give it a look.

Why did you switch? I try to use Unity and I have tons of assets, that are useful sure, but they often end up short due to making them work together or needing extensive coding. I can't code for shit and I'm only interested in making cool stuff, not coding.

No particular reason. My first game was written in C# I learned from a book, but it was my first encounter with Tutorial Hell as I couldn't make anything else with the knowledge gained. Then I made stuff in Game Maker 8.1 for a while and I learned a lot there. I still remember some free PDF with a black jet that taught me a bunch.

Since then I've bounced around as needed. Half-Life mods, Left 4 Dead 2 mods, Doom maps, I never got the hang of Unity or Unreal back then. I settled on Godot for a long time and have yet to find a meaningful replacement.

That sounds really interesting, never heard about those. If you ever need some pixels done I might be interested. You know what I can make.

GBStudio is a simple tool that allows you to make GameBoy games that run on real hardware. It uses templates and a simplistic interface. You can get it to do more, but it's like those people that turn RPG maker into a platform game. Impressive, but I don't see the point. It's clunky, and the performance isn't the best, but it's quick and fun. There's supposedly a bunch of such tools for old consoles. I know there's one for the MegaDrive that's more involved, and there's a Mario 64 level editor that works on real hardware.

Pico-8 (and Tic 80) are "fantasy consoles". The idea being they are like emulators for hardware that never existed. The appeal of Pico-8 is that everyone is stuck with the same restrictions and the same tools, it's about what you do with them.

Commander X16 is like Pico-8 in real life. It's a sort of beefed up Commador 64 made with modern off-the-shelf hardware. That was the idea anyway. It's been in development hell for years.

The appeal of these to me is that they are simple enough to learn completely, they offer great creative flexibility while also restraining you from making a game too grand. There's no squabbling over engine choice, or claims that people don't know how to program any more. It's mostly nerds making stuff for the amusement of other nerds.

 

[Tiggie_Tiger]

depending on what kind of game you are thinking about making, it might unironically be faster to just do it yourself rather than learn unreal from scratch (if you have good programming knowledge in an appropriate language)

I wholeheartedly agree with this. Just play around with languages like C and make simple terminal applications or whatever. Learning to program the old fashioned way is probably the best since everything is so fucked these days.

 

[Dull Pencil]

The appeal of these to me is that they are simple enough to learn completely, they offer great creative flexibility while also restraining you from making a game too grand.

But why not go for some actual real consoles then? I know there's a market for Mega Drive(coughPapriumcough) and NES. Don't know about SNES though. But my point is that if you gonna make a game or something with limitations, wouldn't it be great to create something that you can hold in your hands? I miss physical games so much so for me it would be great to hold a cart for consoles I have, especially if I made it myself.
Even better if there's people out there who would actually buy it. Hobby projects takes probably just as much time as a commercial project for old stuff, so if you can get some $ for your effort it would feel great. But it might just be me dreaming...

 

[Kung Pow]

I get that, but this mythical proper way of learning to code evades me, and the few answers I get are some online course that costs triple digits to start.

You could do the CS50 online course from Harvard, it is free and the introduction course gives a nice foundation if you want to get into the roots of how computers work. And coding is mostly looking shit up on Google, I'm not even joking. The intro course takes around 2 to 3 months to complete.
It helped me a lot at programming in ACS for Doom.

 

[DumbDude43]

I wholeheartedly agree with this. Just play around with languages like C and make simple terminal applications or whatever. Learning to program the old fashioned way is probably the best since everything is so fucked these days.

it doesn't even have to be hardcore shit like C (or, god forbid, rust)
depending on how big your game idea is, you can probably do it in a managed language like java or c# and performance will still be fine

 

[Tiggie_Tiger]

it doesn't even have to be hardcore shit like C (or, god forbid, rust)
depending on how big your game idea is, you can probably do it in a managed language like java or c# and performance will still be fine

Probably not the best to suggest C. My reasoning for recommending it, because I started programming with C. Turns out, being completely fucking clueless and not understanding anything kinda forced my brain to adapt and suck in any information it could just to make sense of any of it.

 

[DumbDude43]

Probably not the best to suggest C. My reasoning for recommending it, because I started programming with C. Turns out, being completely fucking clueless and not understanding anything kinda forced my brain to adapt and suck in any information it could just to make sense of any of it.

no it's the correct suggestion, it's objectively the best choice for gamedev because of performance
i'm just saying that if your game isn't super large and you don't need to squeeze hard for every microsecond of frame time, then you can get away with using an easier language

 

[Grub]

Don't think in terms of files. So, the easiest thing to do is to store nothing. The second easiest thing to do is to store a score and nothing else.

That's all well and good for certain kinds of games but in anything with any sort of progression you're going to store and load more than that. I'm also not sure how the fuck you can not deal with files because literally everything on a computer is some kind of file. If you need to load graphics that's a file. Sound, that's a file again. You're going to, at some point along the way, need to get those files off of a hard drive, CD, disk, SD card, fucking something and into memory so your game can do shit with it. Whether an engine does it for you or whether you do it all manually, you 100% will need to deal with files.

After that, one can be well served by structuring the game into well-specified sections to massively trim down the state space; or taking the easiest way out nowadays and storing the entire dynamic game state, if the underlying system permits that approach. It's funny, how so many classic characteristics of video games were caused by these kinds of constraints; it's easiest to only track a few details and require the player to always start in the same spot, or designated save rooms.

Luckily on modern hardware with more than 32KB or whatever the fuck the chip-8 has, storing something like a few 32bit integers isn't a big fucking problem so luckily keeping track of player position and state and saving and storing that isn't gonna break the memory bank.

 

[UERISIMILITUDO]

I get that, but this mythical proper way of learning to code evades me, and the few answers I get are some online course that costs triple digits to start.

That's horrible. I'll only charge $99.

I wholeheartedly agree with this. Just play around with languages like C and make simple terminal applications or whatever.

Using the C language is a good way to ensure that he never learns how to properly program.

Learning to program the old fashioned way is probably the best since everything is so fucked these days.

For reference, garbage collection was created to serve Lisp, and all of this predates the C language. So, make certain that this old-fashioned way is actually old-fashioned, and not simply stupid.

no it's the correct suggestion, it's objectively the best choice for gamedev because of performance
i'm just saying that if your game isn't super large and you don't need to squeeze hard for every microsecond of frame time, then you can get away with using an easier language

The best system for expressing a game depends on the game. Never forget that glaring performance issues with GTA Online were caused directly by the C language and its asinine view of strings:

How I cut GTA Online loading times by 70%

GTA Online. Infamous for its slow loading times. Having picked up the game again to finish some of the newer heists I was shocked (/sneed) to discover that it still loads just as slow as the day it was re

nee.lv

That's all well and good for certain kinds of games but in anything with any sort of progression you're going to store and load more than that.

I agree.

I'm also not sure how the fuck you can not deal with files because literally everything on a computer is some kind of file.

I meant don't think in terms of files. Think in terms of data structures. Also, I was approaching this from the mindset of old video game systems which truly had no files whatsoever. They're not inherent to the problem, so don't put them front and center.

Luckily on modern hardware with more than 32KB or whatever the fuck the chip-8 has, storing something like a few 32bit integers isn't a big fucking problem so luckily keeping track of player position and state and saving and storing that isn't gonna break the memory bank.

CHIP-8 has a four kibibyte memory space, not all of which is usable. Super CHIP-8 allowed the program to store and retrieve sixteen octets at most from the environment.

I see myself approaching this discussion very differently from most others. I believe it to be important to learn fundamentals, without bullshit imposed by shitty systems, so I'm stating truths that nevertheless may not apply under certain systems.

 

[Individualism Incarnate]

depending on what kind of game you are thinking about making, it might unironically be faster to just do it yourself rather than learn unreal from scratch (if you have good programming knowledge in an appropriate language)

I know some C/C++ as well as Lua. For the kind of game that I want to make (Thief/System Shock 2 clone), I'm basically stuck either with UE or Unity, and Unity is a fucking mess.

 

[Grub]

I meant don't think in terms of files. Think in terms of data structures. Also, I was approaching this from the mindset of old video game systems which truly had no files whatsoever. They're not inherent to the problem, so don't put them front and center.

The issue I mentioned in my original comment was specific to the process of storing and retrieving those data structures from disk, not actually structuring the data. But yes, you should think in those terms and consider storing and loading whatever those data structures represent because whatever works in the game itself may not necessarily work so well with whatever system you're using to store and retrieve game data.

CHIP-8 has a four kibibyte memory space, not all of which is usable. Super CHIP-8 allowed the program to store and retrieve sixteen octets at most from the environment.

I truly and honestly do not give the slightest shit how many make believe bytes the pretend make believe toy computer has.

I see myself approaching this discussion very differently from most others. I believe it to be important to learn fundamentals, without bullshit imposed by shitty systems, so I'm stating truths that nevertheless may not apply under certain systems

Everything about the chip-8 is bullshit imposed by a shitty system. It's make believe and not reflective of what programming on modern hardware is actually like. It's pretending to be like programming something 30 years ago, but not actually really what it was like back then just a happy fun time easy feel good version of it.

 

[UERISIMILITUDO]

I truly and honestly do not give the slightest shit how many make believe bytes the pretend make believe toy computer has.

Everything about the chip-8 is bullshit imposed by a shitty system. It's make believe and not reflective of what programming on modern hardware is actually like. It's pretending to be like programming something 30 years ago, but not actually really what it was like back then just a happy fun time easy feel good version of it.

Don't confuse CHIP-8 with PICO-8 and its ilk. CHIP-8 actually existed half a century ago. The original host was the COSMAC VIP, which had an RCA 1802 processor, another interesting and old little chip. CHIP-8 is the real deal.

 

[baws man jack]

I'm not a game dev, just a regular dev. I've tried my hand at it a few times but I don't have the passion for it. I salute those that do because you guy make some fun shit (sometimes).

 

[Yaya]

Good thread. Sometimes I winder if creating a game engine for an rpg is worth it, but still I’d love to hear others’ opinions. Good luck everyone

 

[Georgio Cocklord]

I'm not here to toss opinions, I'm here to take notes

 

[Gender: Xenomorph]

It seems that there is talent here in the forum. How come you haven't banded together an give it another shot other than the Yandere Simulator clone?

I'd be down.

 

[Judge Dredd]

But why not go for some actual real consoles then?

That's always the problem.

Real retro hardware is rare and valuable. They also all but require knowledge of things like 6502 assembly. It's why it took programmers back in the day 6 months to make something that could made in 2 weeks today. Also some consoles don't do what you want, and you're competing with the AAA games of their day. I could make an action platformer, but it's not going to compete with Contra.

Fantasy consoles can make use of modern tools, programming languages, not arguments about the true experience, etc. They can also do things you want without the annoyances you hate. The Famicube is a famous fantasy console that never got past the idea stage, but was meant to be a middle ground between the primitive NES and the relatively advanced SNES. The problem with fantasy consoles there's no actual hardware. In that case just make things for actual retro hardware or emulators.

The problem there is real retro hardware is rare and valuable. They also all but require knowledge of things like 6502 assembly- and so on.


Fantasy consoles are also a very limited niche. Pico-8 does it's thing and that's fine, but I think there's a reason competitors like the Tic-80, X16, or even that playdate hand crank console never really took off. There's only room for a handful of these systems and they need to offer something that you can't get elsewhere. Ideally, there would be something like the ZX Spectrum or the Commadore 64 where anyone with a book about programming (that often came with the system) could pick it up, make something, and have it become a classic.

It's pretending to be like programming something 30 years ago, but not actually really what it was like back then just a happy fun time easy feel good version of it.

This is largely due to modern tools. Yeah, old games used assembly out of necessity, but there did exist games that didn't. Sonic Pinball was famously written in C and has performance issues as a result. However, modern compilers are more efficient. There's a guy making a Mario 64 romhack that is famous for his various optimizations and bug fixes of Mario 64. Taking the game from 20fps to 60fps on real hardware.

I mentioned GBStudio in the OP, and I've seen autists get mad that the roms it makes are 128k. GB games were 32k-256k, depending on the cartridge with most companies preferring the 32k carts because they were cheaper.

You're not writting in assembly. You're writting in something more readable (or even drag and drop if you're using templates) and having the computer do the work of turning it into machine code. Is that cheating? Yes. But so did devs back then. Sprite art changed from drawing on graph paper and typing those coordinates into code, to having art programs where you drew with a mouse.

Where is the line drawn on this? Are modern textures allowed? Do we have to use 90s texture CDs and Silicone Graphics workstations? Or should we get super accurate and have programers work in shifts because the publisher could only afford a single computer and the only tutorials were a maths text book and some books on programming theory from the 70s?