I'm going to be making my own game soon without using tutorials and just using what I know. What I'm having trouble coming up with is the logic of the game. Things like upgrading weapons and towers, how to make ai detect when theres something in their way, things like that. Are there any books or tutorials that help with this kind of thinking while making a game?

I'd recommend starting with board games and moving up to simple classics like Pong, Breakout and Space Invaders.

Ive already made Pong, breakout, and space invaders. The logic behind them is easy enough to understand

Can you be more specific about where you're stuck then?

This sounds like analysis paralysis.

For AI there are a ton of resources available. It's more or less a decision table that randomly triggers predefined behaviors. More advanced AI just uses increasingly complex selection (by assigning weights to the choices) and simpler actions or a compound system that selects a strategy and then selects an action within that strategy.

Well its really more the things like adding something to an inventory, knowing how to measure where a mouse clicks in 3d space, and things that dont really have a specific answer. Like if you had an inventory, do you use a class? do you use an array list? how do you tell what items are going in an out of your inventory? with a method? a for loop that loops through the inventory? There seem to be multiple solutions to most problems in 3d gaming but I want to learn how to actually apply what ive learned towards a game

It's just a matter of breaking things down into a series of small tasks then trying to apply what you know to each task. For example, an inventory. At its heart, an inventory is just a list of items. An array would work well, since most game inventories are fixed size. You would want to encapsulate it into a class, of course, to carefully control the manner in which things are added/removed. When designing an inventory, you would first want to break it down. What kinds of things will the inventory be able to do, and what can be done to an inventory? The obvious things, of course: adding items, removing items, sorting items, displaying inventory contents, etc... Other things such as searching the inventory for a specific item, using an item, hovering over an item to see a description of it, and so forth. This is where design comes in.

It only comes with practice, for the most part. In the beginning, you're probably not going to be very good at it. The first inventory system I wrote was... horrible, to say the least. Riddled with bugs, awful to work with, clunky in the extreme. It looked good in action, but only because you couldn't see the nastiness that lurked underneath. Later attempts built upon what I learned from that first one to make things more elegant and simple.

Key to game development is the term "emergent behavior", which denotes complex behavior that arises from simple rules. That's pretty much what a game is. Or any complex software, for that matter. The trick is to start with the desired behavior and work backwards to the simple rules, the basic building blocks that you need to make it function.

Having a good grasp of design patterns can be extremely beneficial. For example, an inventory system could be elegantly constructed using the MVC pattern. (Model, View, Controller). The inventory array of items would represent the model. It would be a basic, dead-simple fixed-length array of slots, each slot able to hold an item. The view would be the UI representation of an array, the on-screen grid that shows a drawn background with the contents drawn on top. The controller would be the set of methods for interacting with the inventory and for controlling the UI representation of it.

Once you have the details of your model nailed down (1D array? 2D array? Fixed or dynamic length?) then you can start writing the basic methods for the controller. AddItem(), for example, would simply iterate the array and find the first empty slot, then insert the given item into the slot. RemoveItem() could come in various flavors: RemoveItemByName(), RemoveItemAtLocation(), RemoveItemsOfType() etc... whatever the needs of your game. You might write a set of query functions used for searching the inventory: FindItemsOfType(), CountItemsOfType(), CountItems(), FindFirstItemOfType(), and so forth; again, depending on your needs.

Once you've got a good start on your model and controller representations, and you've tested things out to make sure they work, then you might start on your view representation. Don't get fancy at first, just draw the inventory using basic colored boxes. Write a UI class to encapsulate the testing of mouse input against the inventory grid, relaying clicks through to the controller as required.

A left click on the inventory grid, for example, would trigger a method to calculate which slot was clicked, and perform some logic. If the slot was empty and there was an item in hand, then AddItem() would be called to place the in-hand object in the slot. If the slot had an item and the hand was empty, then RemoveItemAt() would be called to remove the item (and the in-hand object updated to this removed object). If both the hand and the slot had an item, then they would be swapped, the in-slot item removed, the in-hand item added, and the newly removed item placed in-hand.

A right click, however, would test to see what slot was clicked then attempt to issue a UseItemAt() call. If the slot was empty or the item in the slot was non-usable, nothing would happen. Otherwise, a message would be passed to the owner of the inventory to attempt to use the item.

As you can see, an inventory would make use mostly of basic array operations, housed within a larger framework. On the top of it, it might seem complex, but once you start breaking it down into smaller tasks you end up with the most basic of array search/sort/insert/remove operations, straight out of a beginner text book. Similarly, other seemingly complex tasks such as AI would also be built up of basic building blocks.

There seem to be multiple solutions to most problems in 3d gaming

and there you have it.

for almost anything you want to do in games, there are usually at least half a dozen ways, none of which is optimal for everything.

but there are definitely better and worse ways to go about things. much of which is usually game specific.

what you'll need to do, is select a game type, then learn how to do the bits and pieces specific to that game type.

general algos, approaches, and types of data structures will be recurring themes, but each implementation will be unique.

follow a methodology of incremental development.

learn non-game programming skills as needed.

if you can't implement a static array flat file database in your sleep, learn to do so before you write an inventory database module.

muddling through is no way to run a railroad.

i wrote one of every type of app before i started on games. and you really need to know a lot about a lot to do games well.

be prepared for the fact that you'll constantly be learning new techniques. i've been building PC games for 32 years, and still spend as much as 10% of my time in pure research on coding techniques. if you don't like to learn, you shouldn't be building games. constant sharpening of the saw is an integral part of the process.

Well its really more the things like adding something to an inventory, knowing how to measure where a mouse clicks in 3d space, and things that dont really have a specific answer. Like if you had an inventory, do you use a class? do you use an array list? how do you tell what items are going in an out of your inventory? with a method? a for loop that loops through the inventory? There seem to be multiple solutions to most problems in 3d gaming but I want to learn how to actually apply what ive learned towards a game

adding something to an inventory is a simple database function. you'll definitely want to learn how to implement relational databases in whatever data structure you prefer. they are the back end that drives games.

3d pick: us the pickray example code in directx, combined with the ray / geometry intersection test of your choice (from some source). a strong background in 3d math will help here. this pattern occurs a lot in games. you need something that does A and B. there's info for doing A, and info for doing B, but you have to hook A up to B yourself.

an inventory is a list, IE a flat file database. a static array of structs is the fastest running, easiest to implement, and most memory leak proof way to do it. but some prefer objects.

you should already know whats going into and out of inventory, cause you're the one doing it (with code).

collision checks will depend on the type of data structures you choose to hold your "world map" info, with collision maps being the absolute fastest.