I'm programming my RPG in java  so generally the java way  is make everything an object but when does that go to far?  Say for example in my game I have lamp that makes light and burns oil  should oil be a class that an gets   object  instance of it passed to the lamp  that the lamp burns? or simply an int that gets counted down and up?  Is the oil object  a good  idea or is it taking OOP too far?

My usual advise is get it working and decided if you need to generalize it later. There are no hard and fast rules, unless you are are taking to some Uber purist which I'm not.

At some, level, everything has to be implemented in terms of atomic types - integers, floats, etc. - so it can't be objects all the way down. The question you need to ask yourself is where the appropriate level of abstraction lies. More levels of object means more abstraction, and may cost performance, but lets you do things that are difficult or ugly otherwise.

In your example, I would make consider making the oil an object if you can take it out of the lamp and do something else with it, or objects over than the lamp are able to interact directly with the oil. Otherwise you are abstracting without purpose.

Think in terms of your game. Would it benefit your development of the game for Oil to be an object? Would it benefit your game? Is Oil being just a piece of data about your Lamp going to impact your gameplay? Do for some reason you *need* Oil to be a separate Object?

If not then don't treat is as an Object. Programming practices and paradigms are just tools. They are ideas. They are there for you to use when you see fit. When it is beneficial to use them. Anything other than that is wrong way to write software. The only things you should be doing are things that benefit you and your software. 

oil is an object it burns  it has weight, density, it flows,   lamps use  it canteens hold it,  but does the lamp need to have an array list of oil objects  or would having the oil objects converted to a int for the  lamp  be much faster better? I know not to think optimization early, but it is nice to know when you have gone too far.

Knuth's infamous comment about "premature optimisation" was referring to the fine details of assembly, not high level architecture decisions. You absolutely should think about performance when considering these kind of broad implementation decisions, especially when writing games, because they profoundly impact the performance of your code in a way that is difficult to fix later.

36 minutes ago, macmanmatty said:

Is the oil object  a good  idea or is it taking OOP too far?

I would say it goes much too far within the context you give. Likely oil has no functionality and is just data. The lamp has the functionality to burn oil so likely you implement it there (which brings us to the question: Do i need a lamp class at all or can i use a data driven approach configurable so stuff can emit light and consume oil?)

Designing data coupled to functionality as OOP seems to intend only works if you already know how the end result should look like. And often you know this only from experience, guessing, or not yet at all. 

Some rules of the thumb that mostly work for me:

If you are not sure if something deserves its own class, then likely it does not or not yet. 

If you can implement something just by data it is usually preferable.

If the functionality processing the data turns out to be too complex or partially reusable, you can still divide it into multiple classes later on.

2 hours ago, macmanmatty said:

I'm programming my RPG in java  so generally the java way  is make everything an object but when does that go to far?  Say for example in my game I have lamp that makes light and burns oil  should oil be a class that an gets   object  instance of it passed to the lamp  that the lamp burns? or simply an int that gets counted down and up?  Is the oil object  a good  idea or is it taking OOP too far?

It's taking it way too far.

If oil is just something a container has but itself has no inherent properties (i.e. there are no different types of oil and oil itself does not - for game purposes - contain anything) then what you have is an attribute of objects which contain oil holding the quantity of oil that object contains (a float or int) as there is no additional information that needs to be held about the characteristics of the oil itself.

In this context "oil" is like "credits" in the context of a space trading game - all that matters about it is how much a container has of it, how much it gets and how much it uses, as neither oil nor credits have any inherent characteristics themselves which are relevant and can change in the game.

In general, if things do not themselves have inherent variant characteristics in the context of a program, then they do not get represented by objects, rather there are attributes in existing entities which do have variant characteristics (i.e. a lamp is an object because it has a number of variant characteristics, such as how much oil it has, whether its on or off, where it is physically located and so on).

In fact, this whole way of partitioning data is not at all OO-specific: when, for example, designing the Data Model for a Relational Database, data pieces are split between data entities which have their own tables and data attributes which are just columns in tables for the data entities.

In general, beware of confusing the real world with the program representation of it: whilst indeed in the real world oil/water/money do have characteristics important in certain contexts and are thus entities, in the program world you probably just have a simplified representation of those things where all oil/water/money is the same and indistiguishable from all other oil/water/money, and in that case those things are not entities in their own right, rather they are just attributes/properties of things that contain them, produced them or consume them.

Use common sense. Just that.

The fact that you asked for it indicates that you already almost knew the answer.

my answer is yes I was trying to see if my  yes should be a no.