Game Creation/Design Catch All

I think I can mostly reverse engineer the process to consume items, but I still have to figure out how to get conditional choices to display. So if you are in an area where you can use a flashlight and you have a flashlight, an additional choice shows up to use the flashlight. If you don't have a flashlight, you shouldn't get an option to use it.

That is an interesting challenge but I'd warn against delving too deep into it unless this is your main goal. The reason I say that is because you can get lost trying to account for all possibilities the nested booleans. If it is just one layer then fine but once you start testing for A + B = true but not C, and B = true but not C or A, you can eat up days on the calendar. Plus the risk for project quitting frustration or losing interest is high. It is the kind of thing that eats at you at random hours of the day.

polypusher wrote:

Nice progress, keep it up!

Thanks!

fangblackbone wrote:

That is an interesting challenge but I'd warn against delving too deep into it unless this is your main goal. The reason I say that is because you can get lost trying to account for all possibilities the nested booleans. If it is just one layer then fine but once you start testing for A + B = true but not C, and B = true but not C or A, you can eat up days on the calendar. Plus the risk for project quitting frustration or losing interest is high. It is the kind of thing that eats at you at random hours of the day.

That's a great point, and I can totally see that. There's only going to be three or four items in the game, and the game will be super short. And now that I've messed around with it for a couple of hours, I can see how I'd design the original game differently to more easily accommodate these additional mechanics. The game wasn't built to have these sorts of things tacked on.

The thing I'm finding with this though, is that this is the type of problem that I need to spend more time with to get better. Game design requires a lot of skills, but the one that most tutorials don't get at is deciding which tool to bring to a problem, or how to design a system to do a certain thing in a game. Most tutorials/courses are linear, recipe-style affairs where all that type of thinking is done for you.

Godzilla Blitz wrote:

Most tutorials/courses are linear, recipe-style affairs where all that type of thinking is done for you.

Amen.

A lot of them are do what I do and whether directly or not follow with "and don't ask questions".
That is where they fail because game design is all about asking questions. Or learning to ask the right questions to progress.

Yes! I got inventory consumption working in the text adventure. So if you have a particular item, you can use it, it does something, you get feedback, and the item is consumed.

Functionally it's working, but boy is it convoluted. Now that I've got it done I almost want to redo it the whole game and make it better, but really to do this better I feel like I should do the whole game differently, and I don't want to do that.

I also got the game lost states working (run out of time, run out of health), and set up the associated game reset process.

Oh, and I tweaked the screen presentation graphics a bit more too. Because procrastination.

Now I can pretty much just write the story part, add a quit function, and it should be done.

EDIT: I might have jumped the gun on saying that inventory was working. I tried adding an item and ran into all sorts of edge case and display bugs. But I've got them hammered out now and everything is working. I've added about a quarter of the story and hope to be able to add the rest in the next day or two. I expect it'll only take a few minutes to play, but it'll be a functional text adventure with hit points, a timer, and a simple inventory system.

IMAGE(https://i.imgur.com/Mejlhbh.png)

I just want to say that "once I get this last system working I can just bang out the story and be done" would be a very apt description of my current 4-year-ish experiment with indie gamedev

fenomas wrote:

I just want to say that "once I get this last system working I can just bang out the story and be done" would be a very apt description of my current 4-year-ish experiment with indie gamedev :)

Haha! I'm hopeful that I can finish a 10-minute text adventure in less than four years, but I can relate to how this text adventure has been a microcosm of that. When I got to the end of the text adventure unit in the course, I thought, "Cool, I'll take a day to crank out a short text adventure. That'll be good practice." Then I decided to add health points, and a timer, and items, and now it's a week later and I just last night got the first quarter of the story done. So this one-hour sidestep will end up being a ten-hour odyssey. I bet I could easily turn a full length text adventure into four years.

EDIT: I got in a good hour+ of writing tonight. Things are taking longer to write than I expected, but I'm adding to the story as I go, and I'm having fun, so all is good.

Based on tonight's time to words output, I'd say I have another good 3-4 hours of writing before I get the whole thing done.

Hey guys, figured I'd jump back in here as I've resumed progress on my one-button shmup. I lost interest a few months ago when I realised Switch 'n' Shoot had the exact same mechanic as my project. I actually got in touch with the developer just to say "hey cool idea, I've been working on something similar" and got his blessings. I promised to buy Switch 'n' Shoot when I've finished this, as to not accidentally steal any ideas

Anyway, here's some progress.

  • Charge shot - player blinks until completely turning negative. Charge up sound pitches up to indicate it's ready.
  • Walls now move down the side pseudo-randomly these will eventually be hazards but I haven't coded collisions yet.
  • Added the beginnings of a boss fight. The trickiest part was figuring out how to make a weakpoint, but I think it's pretty reliable now. I just have a separate object tracking "under" the boss. If a bullet hits anything other than the glass dome, it will make a "plink" sound. If it hits the weak spot, you'll see a brief flash and here a satisfying crunch

It's been a fun project so far. I still feel like an absolute beginner just abusing "if, then" statements, but I'm going to force myself out of my comfort zone with these bosses and start learning loops.

I'm also at the point where I want to name my project. Thinking of the following (any suggestions welcome).

  • Tapgun (with a cheesy Topgun looking logo)
  • Clickshot
  • Star Strafe

Ha! Tapgun is a nice play on words.

That's looking really smooth! Congrats on what you've accomplished with it so far.

Another hour of writing tonight. This is actually quite fun, crafting a story driven by player choice. I've carved the story up into five parts, with four bottleneck points to keep things from getting too spaghetti-like. At the moment, I'm mostly done with Section B. I just have to add/code an item pickup, and then tidy up the flow and check that everything is linked correctly. Then it's on to Section C.

Things I've learned so far...

1 - Text adventures are unexpectedly challenging to write, because you've got to write for all decision trees. It's quite a bit more writing than I anticipated. I have a better appreciation for quest writers in RPGs now, who have to account for much more complexity and durability of player choice.

2 - These things get like spaghetti very quickly. Every time you fork the story, or allow for people to go backwards, you create the possibility for your narrative to not make sense. For example, arriving a second time in a place and getting the same text you got when you first arrived doesn't read well at all, which means that you're creating another narrative box and even more complexity. Section B isn't very complex, but my head is barely able to hold all the pieces together.

But that being what it is, I'm enjoying the writing a lot more than I thought I would.

In case you want to see how Infocom did it once upon a time, all of those games have been open sourced here.

Ars Technica article.

I have a question that I've been stuck on for a while, and I wonder if someone more experienced here might be able to point me in the right direction...

Some of my game design interests lie in niche simulation games, where a large part of the game under the hood is data that the player manages. Think Football Manager, except on a smaller scale. For example, the game would have a database of players with various characteristics, and the game needs to display this data to the player in a variety of screens, modify it over time, and of course filter, organize, and sort it in ways that the player can manage.

I have no idea how to get started with this, and can't seem to find tutorials/courses aimed at this. Most of the data/Unity stuff I find is about how to manage multiplayer databases online, and that's not what I'm looking to do. The data would reside with the game, and be part of the game experience. I'm not looking to build an online game.

Compounding this problem is that I don't have good database skills yet, so sometimes when I find something that looks like it might be what I want, I don't even know what I've found.

I'm wondering, would anyone have suggestions on what might be a learning pathway through this stuff?

I'm willing to spend a few months or whatever it takes to learn enough database skills to pull this off, but I'm a bit at a loss where to start, and what skills would be best to learn first.

Thanks in advance!

Are you asking about how to create the database or how to manage the UI of the database?

For the 'database' depending on just how dense it is, I might go with using Object Oriented Programming. So say it's a racing simulation (like Motorsport Manager) Each car is an object, each driver is an object. Each object is as deep a collection of figures as you need and its fairly easily accessible.
Then you make containers for the objects, like a list of the instances of cars. Then you have access to all the data you need. You can display a page that has a list of all your cars and the appropriate stats for each.

If you're talking about how to make a good usable UI that's a tougher problem to advise on. Look at google searches like 'dense data UI' I found this article that gives some reasonable suggestions. https://uxdesign.cc/5-tips-for-desig...

For learning database programming, I recommend Practical SQL by Anthony DeBarros. It starts right from the basics of how to install PostgreSQL, a good free database server to experiment with, and gradually develops a thorough coverage of SQL.

For the kind of application you're looking at, where the database is going to be part of the game state rather than running as a separate app, you probably want to use Sqlite, which is designed to be embedded in other programs. Sqlite's native API uses C/C++, but there are bindings for most popular languages. I seem to recall you were using Unity; there are several Sqlite-for-Unity plugins, on a quick search this one looks good. (You should probably learn SQL on a more conventional DB before trying to use Sqlite though.)

A lot of this is informed by what your final goal is. Is this like a 4X or City Builder type where the player needs the info to make decisions? Is this for individual, AI controller mobs?

Data Structures can be a very odd topic, especially for storage and retrieval. When I start, I try to look at the purpose of the data and what it’s used for before I start building it.

Thanks so much everyone! I should have asked here six months ago.

polypusher wrote:

Are you asking about how to create the database or how to manage the UI of the database?

Probably both, eventually, but mainly the first part right now. For whatever reason I don't feel so intimidated by the UI of problem, but that might just be a Dunning-Kruger level of ignorance. I have experience with course and website design, so to a degree I feel like I know enough to get started with the UI of things.

polypusher wrote:

For the 'database' depending on just how dense it is, I might go with using Object Oriented Programming. So say it's a racing simulation (like Motorsport Manager) Each car is an object, each driver is an object. Each object is as deep a collection of figures as you need and its fairly easily accessible.
Then you make containers for the objects, like a list of the instances of cars. Then you have access to all the data you need. You can display a page that has a list of all your cars and the appropriate stats for each.

I think what I want to do is dense enough that OOP would break down. I'm envisioning a game with a database of a few thousand people, each of whom could eventually have a few dozen data points.

CaptainCrowbar wrote:

For learning database programming, I recommend Practical SQL by Anthony DeBarros. It starts right from the basics of how to install PostgreSQL, a good free database server to experiment with, and gradually develops a thorough coverage of SQL.

Thanks so much! That looks very accessible to a newbie. I ordered it from Amazon. It'll arrive on Saturday.

CaptainCrowbar wrote:

For the kind of application you're looking at, where the database is going to be part of the game state rather than running as a separate app, you probably want to use Sqlite, which is designed to be embedded in other programs. Sqlite's native API uses C/C++, but there are bindings for most popular languages. I seem to recall you were using Unity; there are several Sqlite-for-Unity plugins, on a quick search this one looks good. (You should probably learn SQL on a more conventional DB before trying to use Sqlite though.)

Those look excellent as well, and yes, ideally I'd like to leverage my Unity learning and use that as an engine. I've noted both things. I was also poking about today and stumbled onto Unity assets for SQL, like this one: SimpleSQL, but it sounds like these might be Step 2 kinds of things, once I get down some SQL and database fundamentals first?

athros wrote:

A lot of this is informed by what your final goal is. Is this like a 4X or City Builder type where the player needs the info to make decisions? Is this for individual, AI controller mobs?

Data Structures can be a very odd topic, especially for storage and retrieval. When I start, I try to look at the purpose of the data and what it’s used for before I start building it.

Here's the basic idea, from this post.
"Related to this, one crazy "game making" idea I've had bouncing around in my head is a World Cup simulator, where you play the role of a nation's national team director, and are in charge of promoting the sport, hiring a manager, and working to develop your nation's capacity to develop and recruit talent to win the World Cup. Impacting this would be the country's political, economic, and cultural climate. I'd imagine it running at a 10-15 minutes per year pace, where you could play a nation for 100 years in about 10-15 hours."

For more details on the idea, there is a brainstorming conversation that follows that post. My thoughts are to try to build out a rough prototype of that idea, something bare bones simple that I could keep adding concepts, mechanics, and features to if the base concept seems fun enough.

Thank you again, everyone, for the help with this. I no longer feel totally stuck. I feel like I have a starting place.

Godzilla Blitz wrote:

Those look excellent as well, and yes, ideally I'd like to leverage my Unity learning and use that as an engine. I've noted both things. I was also poking about today and stumbled onto Unity assets for SQL, like this one: SimpleSQL, but it sounds like these might be Step 2 kinds of things, once I get down some SQL and database fundamentals first?

SimpleSQL looks like a good choice. And yes, I'd definitely advise you to get at least a basic working knowledge of SQL before you try to integrate Sqlite or SimpleSQL into your coding. That way you're not trying to learn two things at once

CaptainCrowbar wrote:
Godzilla Blitz wrote:

Those look excellent as well, and yes, ideally I'd like to leverage my Unity learning and use that as an engine. I've noted both things. I was also poking about today and stumbled onto Unity assets for SQL, like this one: SimpleSQL, but it sounds like these might be Step 2 kinds of things, once I get down some SQL and database fundamentals first?

SimpleSQL looks like a good choice. And yes, I'd definitely advise you to get at least a basic working knowledge of SQL before you try to integrate Sqlite or SimpleSQL into your coding. That way you're not trying to learn two things at once :)

Sounds like a plan. I'm excited. I picked up this Udemy course as well: Ultimate SQL Bootcamp, because buying a Udemy course is the best way to feel productive without having to actually do anything.

Thanks again.

That game description doesn't seem like it is asking for a database at all. If your game state persists between play sessions, then you've got to get the sum of the saved state onto the hard drive somehow. What are the typical ways developers do this for an average game, and how does that fail to meet your needs?

That said, picking up SQL as a skillset plus your stated frontend experience makes you basically qualified to give a talk at a web dev conference about how the singularity will effect SVNs. If the game project serves as a neat way to learn SQL then maybe go for it anyway? Otherwise I think you may be dumping a lot of overhead between you and making the actual game that will turn out superfluous.

Danjo Olivaw wrote:

That game description doesn't seem like it is asking for a database at all. What are the typical ways developers do this for an average game, and how does that fail to meet your needs?

Interesting. My first reaction: That's probably the question I should have been asking from the start?

I was thinking that given the large amount of data involved in the game, a database would make the most sense, but that's more of a random idea than it is coming from any sort of understanding of how to solve the problem. Maybe polypusher's idea of coming at it from an OOP perspective does make more sense? Or maybe there are other tools to do this that would be better?

Unity has to support tables, right?

fangblackbone wrote:

Unity has to support tables, right?

Probably?

Just exploring in a bit, Football Manager uses a database. The game I envision would be a fraction of that size and have far fewer data points, but it would still need a couple of thousand players at a minimum and have at least two dozen data points per player.

I'm most definitely open to other solutions to the problem.

EDIT: Doing some math, at 200 countries with 200 players per country, that's 40k players. I could probably design it with far fewer countries, maybe 50? Still, that'd be 10k players. I don't think it could be done with less players per nationality.

fangblackbone wrote:

Unity has to support tables, right?

Looks like vanilla Unity might need help, but there is this asset that looks pretty good.

That asset only displays things in a table. You might want to look into something like this for a very large data set: https://assetstore.unity.com/packages/tools/integration/simple-database-137163. Then use the asset Godzilla Blitz mentioned to display said database.

Fredrik_S wrote:

That asset only displays things in a table. You might want to look into something like this for a very large data set: https://assetstore.unity.com/packages/tools/integration/simple-database-137163. Then use the asset Godzilla Blitz mentioned to display said database.

Yes, a different one that I stumbled onto yesterday was this one. But your solution is free, and might be just as sufficient.

If you are making something with a ton of data, a database is hard to beat.

But there are alternatives. For example, all the Paradox games store all their data as text files written in a scripting-ish language that they parse when loading the game. Here's a short video that shows how events work in EU4 for instance.

The metric of "ton" is pretty broad one. A megabyte? A gigabyte?

I think the structure of the data is more important. If you're going to be asking questions like, "For all players that have been on team X but then transitioned to a new team, what is the difference in their performance for action Y from team X compared to the new team, for a range of games played from time A to time B, aggregated by new team?" SQL gives you handy syntax for that. It is plausible for a management sim that this is the kind of question you'd be asking. Not my genre, so its hard to say.

I feel like I level up every time I read this thread. Thanks everyone.

tboon wrote:

If you are making something with a ton of data, a database is hard to beat.

But there are alternatives. For example, all the Paradox games store all their data as text files written in a scripting-ish language that they parse when loading the game. Here's a short video that shows how events work in EU4 for instance.

Oh! *jackpot*

Not so much for the database question maybe, but that was super helpful for learning how triggerable events might be set up in a game. And there is support for modding events in CK2 and EU4. I’ve added this to my list of things to explore. Thanks.

Danjo Olivaw wrote:

The metric of "ton" is pretty broad one. A megabyte? A gigabyte?

I think the structure of the data is more important. If you're going to be asking questions like, "For all players that have been on team X but then transitioned to a new team, what is the difference in their performance for action Y from team X compared to the new team, for a range of games played from time A to time B, aggregated by new team?" SQL gives you handy syntax for that. It is plausible for a management sim that this is the kind of question you'd be asking. Not my genre, so its hard to say.

I hope it won’t get anywhere close to being that complicated. I’m thinking of a simpler game than that, that isn’t centered on player management so much as on country management. The players are more the product of that country management.

There are a lot of good ideas here, but let me exhort you to keep them all in mind, but start out with the simplest possible data structure and switch to something more robust/performant later when you feel you need to. In your case that would probably mean starting with an array of objects, where each object holds the properties for one player.

The inflection point might come if you eventually find there's too much data to keep it all in memory at once - if the data needs to live on disk, and only be read into memory as needed, that would probably be where you'd benefit most from a database. But I don't think there's any value to trying to architect that from day one, your initial goal should always be to get the game playable as quickly as possible so you can figure out if it's fun or not.

Thanks. That's really important to keep in the forefront, isn't it.

I bet I could make a simple prototype with just one country as an option that wouldn't need much data at all. I could just use simple aggregate or static numbers for non-playable countries. That'd be plenty to test some of the mechanics to see if they were fun.

I do want to keep pushing my skill set, and learning SQL and database management would be helpful for work too, so I want to keep going down that route, but I can and probably should disconnect the two things for now.

----

On a related note, I got another hour in working on the text adventure game this evening. I'm starting to write in the third section of the game now. Every time I write I'm discovering that I need to write even more than I imagined, but I think I'm starting to learn how to control the decision trees better so they converge more often and don't branch off so much.

Another day, another hour of text adventure writing. About halfway done with the whole thing, I'd guess.

I also got started on the Udemy SQL course. I've got a MySQL environment set up to work in, and can create (and delete) databases and tables. Progress!

And new toys arrived about 10 minutes ago...

IMAGE(https://i.imgur.com/oWWVmZX.jpg)