Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Iris]

I have a bad habit of writing down ideas that I will never get to (or, at least, currently lack the skill to implement). With that said, I have been thinking recently of a voxel-based 3D open world game centering around building factories.

The problem is "3D open world sandbox" is a terribly crowded space these days. I thought of a variety of ways to make it interesting (focus on player-made content? "Age" system allowing you to advance to different technogical eras? Some kind of vehicle creation system? Modular machines [but isn't that what a factory is, just on a larger scale?]) but none of them seem to fit. I was wondering if the esteemed forumites of Bay12 would have any ideas to make it interesting?

[delphonso]

I think for anything open-world, the only way to add meaning to whatever the player is doing is to build systems which can react to it.

Something like an ecological system would fit with factories well - the more factories you build and the more you dump waste into that nearby river, the more it effects the local ecology and perhaps even the weather. It'd be interesting to turn a splendid green forest into foggy London Town after enough work.

More impactful is a system which reacts to the player actively and has long-term effects. This is essentially what DF does - there's a world with history and factions, and the player seems to have the ability to completely derail that history, with the implication that the world ticks on afterwards - although that part is a bit slower/harder in DF.

[Iris]

Interesting. I suppose it comes down to what I want the player to be able to do?

[IndigoFenix]

When in doubt, pick a genre and blend them!
Let's see, what hasn't been blended with factory building yet?

How about a factory-building platformer?  Each factory part represents a different part of the course, you have to build a functional factory but sometimes monsters appear and you have to navigate through your own factory to clear them out.  Some parts are easier to navigate but less efficient, so you have to decide whether to take on the extra platforming challenge.  You can also build factory sections that give you bonuses in the platforming stages, like extra lives (robotic bodies?).

Or you could have guns and more powerful guns can also damage parts of the factory if you miss.

Maybe a style rating system so that you are encouraged to build more interesting challenge courses?  You can record yourself running through the factory as a TV show and more style points gives you money.

[eerr]

One thing I haven't seen done fresh in awhile 'you surround it, you own it'

Basically like in rampart, where you place tetrominos and other pieces so you can build walls to encompass an area.

Any enemy, house, or water you encompass is also destroyed and gives points.

You also need to surround at least one castle, for points to put down cannons.

You also need those cannons to blast away the invading ships. or your friend's castle...

[King Zultan]

One thing I haven't seen done fresh in awhile 'you surround it, you own it'

Basically like in rampart, where you place tetrominos and other pieces so you can build walls to encompass an area.

Any enemy, house, or water you encompass is also destroyed and gives points.

You also need to surround at least one castle, for points to put down cannons.

You also need those cannons to blast away the invading ships. or your friend's castle...

I'm pretty sure I've seen an add for a phone game like that recently, but I didn't pay enough attention to it to get a name.

[delphonso]

There's a 3-hour gamejam over on twitch that I think I'm literally the only participant in. If you want to take a crack at it (it's Godot), I'd appreciate some competition.

The jam is here.


Edit, wrote Twitch, though I meant itch.

[Iris]

Huh. I was just thinking about picking up Godot earlier today. Although since I haven't touched the game engine at all and I don't do well under pressure or time/theme constraints, I'm not sure if joining that would be a good idea.

[Naturegirl1999]

OTW, this seems interesting

[delphonso]

Does anyone have a good tutorial on dialogue trees?

Most of what I'm reading uses json, which is fine, though I've heard csv are easier for translation purposes (a baseless claim, as far as I can tell). The issue is that they're all just examples of reading dialog from one file for one character? Is that best practice? As many jsons and you have Jasons? Or put all your characters in one big json and just find the right one on reading?

[Telgin]

In theory I'd expect JSON to be better because you could nest the dialogue paths somehow, but I haven't actually tried to build anything like that.

The one time I've built a dialogue system, I used something essentially like CSV files, though it was in Unreal Engine.  The conversations were just rows in a spreadsheet, with a character name, a character portrait (to support changing expressions), a message, an optional name for the row, and a pointer to the next row name to jump to.  The system would just show messages in order unless there was a next message name provided, at which point it would jump to that row.

It works fine, but it was kind of clunky to manage for obvious reasons.  I also didn't get far enough to have branching trees, though that was the intended use of the row names, so picking different options could skip to different parts of the conversation.

Something like that would probably work okay if you had a simple editor built to help manage the structure of the file.  JSON may end up being better, but I'd have to think about how to store the data.

[King Zultan]

Cataclysm uses JSON for their character dialogue system with each NPC getting their own file dedicated to everything they say, but I've never messes with those files so I have no idea if they're the way to go or not.

[delphonso]

Interesting. I guess I'll just tool around with it and see if I can make something that works.

I found a tool for Godot called "Whiskers", which just gives you a tool to generate a file (JSON, I believe), and an opensource parser to use. I can already understand the parser, so maybe I can just cut this up into something useful for me.

[delphonso]

Mike chucked this in my thread, but I think it's pretty well-put advice for new devs.

Forgive me because I haven't actually read very much of this thread :-)  I started work on a DF-like game a few years ago and got a fair way through.  I generate a map and have a dwarf wandering around in it trying not to die of thirst.  Not really that engaging, but it was fun to code.  I did most of it on Twitch, live streaming usually 8-10 hours a week for about a year.  Unfortunately, I found that the stress of keeping that schedule on top of my already busy work life caused problems for some health issues I had and so it's been on the back burner for a *long* time.  It was super fun streaming development, though, so I'd like to get back into it.

Having made that long winded introduction, I've learned some things along the way.  The first is the old classic: You can make a game or you can make a game engine.  If you start making a game engine to make a game, at best you will complete the game engine.  More normally you complete nothing :-)  Going the other way around is actually easier.  Pick an engine that gives you as much facility as you can find, start writing your game and when you get a good way through it, rewrite the whole thing from scratch.

The reason for this is that coding is coding.  You've just got to grind your way through all of the details.  The hard part is figuring out what the details should be.  if you are coding the engine at the same time you are figuring out how the game should play, or what facilities your game engine needs to provide, you will not be nimble enough to try what you need to try.  One day you think, "I know!  We should try X".  6 weeks later you finally add the features to your engine to try X.  X sucks.  It's fine because by trying X, you realise Y is the *real* way to go.  6 weeks later, you add the features to try Y.  Y doesn't suck, but it's not really right either.  Z is definitely the way to go!  Rinse and repeat forever.

Ideally you want to be able to rapidly try your ideas until you are very sure that you have the game play that you want.  Then you have plenty of time to implement it in the best way possible.  At least if you are an indie dev and you don't have project managers screaming at you to do the *next* idea, so let's hang on to that bloody legacy carcass a bit longer...

This is obviously not what Tarn does, but he's special in a number of different ways :-)

I think the other big thing I learned was that it helps to make a lot of small, completely unrelated games before you tackle a big long term project.  The reason is that the "game loop", the thing that people find fun about playing your game, is quite elusive.  I had assumed that, like most development I do, I could write something quite basic and then just keep enhancing it with more features as I discovered what I wanted to do.  The problem is that "fun game loop" is surprisingly difficult and it's not really an incremental thing.

Getting some practice just crafting "fun game loops" is a really good idea, I think.  This is something that Tarn and Zack do a lot of (and you can see that they have *many* games in various state of completion).  I think this is part of their "special sauce".

So, what I would do now that I have some experience is:

1) Write something tiny, unrelated to any big idea, using an established platform that makes it quick to churn out a game.  Tamagotchi remake is a *wonderful* idea.  The original is *so* basic, but it has a fun game loop.  Try to implement just that classic game loop.

2) When you have something working, think about what the ideal development environment would be and build that.  Then reimplement your tiny game.

3) Spin on that idea for a while, changing the "fun game loop".  How did that influence the underlying development environment?  What kinds of things did you have to do?  How would you support that in a larger game.

4) Goto 1, but with a bigger idea.

Hope that helps you.

I'd add something like, "Don't get discouraged, coding docs/tutorials are written by moonmen and make no sense. It's not just you, it's all of us."

[Telgin]

That's all very good advice that I agree with, and I've made those mistakes myself many times.  I've gotten much further in the games where I used game engines than when I tried to build them from scratch, and the only game I've ever completed was using XNA during a game development class in college.

The big one I still struggle with is finding a practical scope for a game.  My last two projects were way too big.

One was an action-adventure RPG shooter that was supposed to span a full narrative over like 10-12 levels.  I churned on that for 2 full years and got most of one level done, and that was using Unreal.  I realized that there were parts to the process that I hadn't even considered, like level design, which I had no skills for, and after years of working on the game had no patience to learn.

The other project was a space 4X game that was supposed to be more detailed than most 4Xes and be more fun to play peacefully with internal political and population dynamics.  I burned a few months on it, got to the point of randomly generating solar systems in a galaxy, and burned out because I wasn't using a game engine.