Java-Gaming.org
 Featured games (91) games approved by the League of Dukes Games in Showcase (577) games submitted by our members Games in WIP (498) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
 Home Help Search Login Register
Pages: [1]
 ignore  |  Print
 The Entropy Game Engine  (Read 2651 times) 0 Members and 1 Guest are viewing this topic.
saucymeatman
 « Posted 2013-10-31 03:10:11 »

This will be my thread for my game engine,

*thanks for the logo, kpars*

So here is the github page. I update the engine almost daily now so check here for the latest version,
https://github.com/Saucymeatman/EntropyGameEngine/tree/master

Here is video showing some of the features of the engine
Note : The frame rate is low because of the recording software not the engine
<a href="http://www.youtube.com/v/h0FYGMutZkg?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/h0FYGMutZkg?version=3&amp;hl=en_US&amp;start=</a>

Physics
Creating a physics object is easy,
 1 `PhysicsObject aObject = new PhysicsObject(10,15,"someImage.png");`

Once you have a PhysicsObject you can easily create colliders attatched to it.
Colliders are created with,
 1 `(Object objectAttatchedTo, double startPointX, double startPointY, double endPointX, double endPointY)`

For example we could create a collider attatched to our example object,
 1 `Collider c1 = new Collider(aObject,-10,0,10,0);`

Or we could create a object independent of any object,
 1 `Collider c2 = new Collider(-10,0,10,0);`

And set it's bounce so its bouncy,
 1 `c2.bounce = 1.1;`

You can add or set momentum for a PhysicsObject like so,
 1  2 `aObject.addMomentum(10,0);aObject.setMomentum(15,10);`

PhysicsObjects also have other attributes that make them more verisitile
such as air resistance and gravity,
 1  2 `aObject.airResistance = .95;aObject.gravity = .25;`

Rendering
Everything in the game is rendered relative to the camera and the camera
is automatically created in Level.

But more important is what you can do with the camera! It can be easily
manipulated with,
 1  2 `Level.camera.smoothMove(1000, 0);Level.camera.move(10, 4);`

Or attatch the camera to an object,
 1 `Level.camera.snapToObject(aObject);`

Create an image that renders relative to the camera easily like so,
 1 `RelativeImage anImage = new RelativeImage("someImage.png",10,15);`

Note : realtive images come with easy manipulation meathods like smoothMove()

GameStates
unfinished
You will be able to save the current state of any given level and all the objects and
images in it with these meathods,
 1  2  3  4  5  6  7  8 `//save current state to last open slotGame.saveState();//save state into a fileGame.saveState(file);//save current state in sixth slotGame.saveState(6);//continuously save states, 100 states maxGame.beginRecording(100);`

And load states easily like so,
 1  2  3  4  5  6 `//load the sixth stateGame.loadState(6);//rewind through the game states to create a rewinding time effectGame.rewindStates(10);//load a state from a fileGame.loadState(file);`

If you know what your doing, and want to join in the project email me : vanaficionado@gmail.com
opiop65

JGO Kernel

Medals: 123
Projects: 7
Exp: 3 years

Team Alluminum

 « Reply #1 - Posted 2013-10-31 03:15:46 »

Upload your image to an image hosting site like imgur and use the [img]url to picture[/img ] tags.
As for the engine, sorry but I don't think anyone will look at it if you don't provide clear and friendly examples of your code and what it can do. Just linking us to your source code isn't enough, I want to know what I can do with it. Pictures, videos and code are necessary, almost, to attract attention to your project. Not just a large page of text.

saucymeatman
 « Reply #2 - Posted 2013-10-31 03:16:42 »

Thanks man, Ill rework the thread
 Games published by our own members! Check 'em out!
StumpyStrust
 « Reply #3 - Posted 2013-10-31 06:07:48 »

I like this. Seems like you actually have a little more going on then the other "Game Engines" people post on here.

One thing I strongly suggest if you do not mind, try using libs that are out there for certain tasks. Unless you want to reinvent the wheel, which is fine, there are libs out there that have been put through the gauntlet and work well instead of some code you write which may be wonky. Part of a game engine is to link all the different components people may use in a very thought out manner. Its not just about physics, pathfinding, AI, rendering but how they interact and how easy/hard it is to do certain things. Good GUI stuff can be a huge pain and your time may be spent somewhere else in the engine that needs it so why not integrate a lib that is already out there.

Just a thought. Have fun.

65K
 « Reply #4 - Posted 2013-10-31 07:31:01 »

Some issues found:
* Camera creates a thread on each smoothMove(). First, rather use thread pools for creating many threads, second, it is not thread safe and a generally questionable idea
* Object inherits from image class, but a game object is no image but may use one. Makes usage of Object unnecessarily inflexible
* Drop RelativeImage completely, has no right to exist
* Object adds itself to some external collection in an unfinished state
* Object.smoothMove() should not put the current thread to sleep - it does not know how threads are handled at that point
* PhysicsObject uses threads but is not threadsafe
* PhysicsObject should not implicitly start working from its constructor
* Members of Level should not be static

saucymeatman
 « Reply #5 - Posted 2013-10-31 19:49:40 »

"I like this. Seems like you actually have a little more going on then the other "Game Engines" people post on here."

Thanks! Im glad you like it, replies like that keep me coding. (+1)

"One thing I strongly suggest if you do not mind, try using libs that are out there for certain tasks."

Yea thats a good idea. Particularly for rendering, LWJGL is GPU accelerated. But for now at least, the engine will be indipendent of other game librarys or engines.

"* Camera creates a thread on each smoothMove(). First, rather use thread pools for creating many threads, second, it is not thread safe and a generally questionable idea"
First off, thanks for looking through my code and finding things that I missed. Not many people would go that far to help someone they dont know. Secondly, now that Im looking through my code several things arnt thread safe, ill work on that right away.

"Object inherits from image class, but a game object is no image but may use one. Makes usage of Object unnecessarily inflexible"
Yea your right.

Drop RelativeImage completely, has no right to exist
If someone wants to have an image upon screen, without it being rendered relative to the camera, Image makes sense to use, where a relative image would be used in other ways. Why no right to exist?

Thanks again for those finds, +1
65K
 « Reply #6 - Posted 2013-10-31 20:02:54 »

Drop RelativeImage completely, has no right to exist
If someone wants to have an image upon screen, without it being rendered relative to the camera, Image makes sense to use, where a relative image would be used in other ways. Why no right to exist?
Because it is inflexible.
What does RelativeImage actually change ? Another way of calculating a location. That is done by injecting a hardcored static reference to another class. Not good. Always keep dependencies low between classes.
Images do not need to know the context in which and how they are used - let class users decide what to do for each use case.

saucymeatman
 « Reply #7 - Posted 2013-10-31 20:15:17 »

I think I understand what you mean. I think the best solution would be to combine them and have a boolean in image like isStatic, which by default will be false. That would probably be the best way to fix this right?
65K
 « Reply #8 - Posted 2013-10-31 22:36:45 »

An image is, well an image... a wrapper around some bytes. Maybe it can draw itself, to be generous.
Actually it does not even have a location - that is part of a use case, like for example when it is used to represent a game object. Remove the location and you can draw the same image object to different places, otherwise you need to create new objects.
Limiting class responsibilities simplifies class design, programming, testing, maintaining.

saucymeatman
 « Reply #9 - Posted 2013-11-08 01:08:21 »

~Update~

Small Stuff
-improved physics, much less buggy
-added in some misc geometric methods
~Tools.getDistance(x1, y1, x2, y2)
~Tools.isCloseTo(a, b, tolerance)
-added dontCollideWith(Object obj) to the PhysicsObject
-added checkNormalColliders() to PhysicsObject, returns true if it's hitting anything

Bigger Improvments
-new video, in the original post
-added rotate(double amount) to Object, Collider and Image,
this is in preparation for rotationalMomentum and the huge planned improvments
in the physics engine that will distribute collision force between xMomentum,
yMomentum, and rotationalMomentum disproportionaly
 Games published by our own members! Check 'em out!
vbrain
 « Reply #10 - Posted 2013-11-08 02:55:26 »

I went to take a look at your Camera.java file and cringed at the monstrosities I saw.

First of all, you've limited the engine to a screen size of 1400x880. At least, that's what I deduced from this:
 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15 `        public double getLocationX() {                if (objectSnappedTo == null) {                        return locationX;                } else {                        return objectSnappedTo.getObjectLocationX() - (1400/2);                }        }                public double getLocationY() {                if (objectSnappedTo == null) {                        return locationY;                } else {                        return objectSnappedTo.getObjectLocationY() + (880/2);                }        }`

If someone snapped the camera to an object, then tried to use getLocationX() or getLocationY() and the window size was not 1400x880, their entire game gets screwed up if they use those values.

There's sooo many things wrong with smoothMove. First of all, why are you creating TWO threads??? One would have been bad enough, but two? Just to move the camera? And what about accounting for different framerates? What if I wanted the camera to take 5 seconds moving to a location? What if I wanted 0.5 seconds?
What you should do is change smoothMove to take a time variable, then set a boolean isSmoothMoving as true.
Give the camera an update(float deltaTime) function and have it check if isSmoothMoving is true. Based on its current location and angle between that and it's desired moveLocation, you should be able to figure out what to do. It's much more difficult than what you have now, but infinitely better.
saucymeatman
 « Reply #11 - Posted 2013-11-08 03:27:33 »

"return objectSnappedTo.getObjectLocationX() - (1400/2)"
This was only temporary, it centers the camera around a object at the center of the default window size.

Ill fix smoothMove() now. It should defiantly have a speed or time parameter.
I don't know about giving the camera a update timer, it doesn't really need one. What you describe can be done without one.
Maybe,
smoothMove(double desiredX, double desiredY, double time)?
MJF

Innocent Bystander

 « Reply #12 - Posted 2013-11-09 06:51:11 »

I like the new logo
saucymeatman
 « Reply #13 - Posted 2013-11-09 15:48:02 »

Thanks man, Kpars did it for me
Rayexar

Junior Member

Medals: 2

 « Reply #14 - Posted 2013-12-04 11:50:24 »

I'm excited for this, seems like it can be a really great engine!
saucymeatman
 « Reply #15 - Posted 2013-12-04 13:21:30 »

Thanks!
Ive been working really hard the last couple weeks on a huge update, it should be out soon.
I has to rewrite almost the entire physics engine for it!
wessles

JGO Ninja

Medals: 49
Projects: 4
Exp: 3 years

Coding with bad posture since 2011... Nonstop.

 « Reply #16 - Posted 2014-02-01 23:15:51 »

I miss this project. I just remember saucymeatman sending me a little 3 second physics demo of a box dropping. That is literally the last I heard of it!

You don't know nerdiness yet; you haven't even met me!
www.wessles.com
Pages: [1]
 ignore  |  Print

 Add your game by posting it in the WIP section, or publish it in Showcase. The first screenshot will be displayed as a thumbnail.
 xsi3rr4x (22 views) 2014-04-15 18:08:23 BurntPizza (17 views) 2014-04-15 03:46:01 UprightPath (31 views) 2014-04-14 17:39:50 UprightPath (15 views) 2014-04-14 17:35:47 Porlus (31 views) 2014-04-14 15:48:38 tom_mai78101 (57 views) 2014-04-10 04:04:31 BurntPizza (114 views) 2014-04-08 23:06:04 tom_mai78101 (214 views) 2014-04-05 13:34:39 trollwarrior1 (182 views) 2014-04-04 12:06:45 CJLetsGame (189 views) 2014-04-01 02:16:10
 princec 32x Riven 29x Rayvolution 20x Gibbo3771 14x BurntPizza 13x saucymeatman 12x kpars 12x Roquen 12x Drenius 11x ctomni231 11x trollwarrior1 10x matheus23 10x theagentd 9x HeroesGraveDev 9x Longarmx 8x opiop65 8x
 List of Learning Resourcesby Longarmx2014-04-08 03:14:44Good Examples2014-04-05 13:51:37Good Examplesby Grunnt2014-04-03 15:48:46Good Examplesby Grunnt2014-04-03 15:48:37Good Examples2014-04-01 18:40:51Good Examples2014-04-01 18:40:34Anonymous/Local/Inner class gotchasby Roquen2014-03-11 15:22:30Anonymous/Local/Inner class gotchasby Roquen2014-03-11 15:05:20
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org