Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (530)
games submitted by our members
Games in WIP (512)
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 2693 times)
0 Members and 1 Guest are viewing this topic.
Offline 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 slot
Game.saveState();
//save state into a file
Game.saveState(file);
//save current state in sixth slot
Game.saveState(6);
//continuously save states, 100 states max
Game.beginRecording(100);


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




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

JGO Kernel


Medals: 128
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.

Offline 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!
Legends of Yore - The Casual Retro Roguelike
Offline 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.  Smiley

Offline 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

Offline 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
Offline 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.

Offline 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?
Offline 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.

Offline 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!
Legends of Yore - The Casual Retro Roguelike
Offline 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.
Offline 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)?
Offline MJF

Innocent Bystander





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

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

Thanks man, Kpars did it for me   Cool
Offline 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!
Offline 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!
Offline wessles

JGO Ninja


Medals: 49
Projects: 4
Exp: 3 years


Loves games, loves coding; this is only logical.


« 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 (72 views)
2014-04-15 18:08:23

BurntPizza (68 views)
2014-04-15 03:46:01

UprightPath (79 views)
2014-04-14 17:39:50

UprightPath (65 views)
2014-04-14 17:35:47

Porlus (80 views)
2014-04-14 15:48:38

tom_mai78101 (104 views)
2014-04-10 04:04:31

BurntPizza (164 views)
2014-04-08 23:06:04

tom_mai78101 (260 views)
2014-04-05 13:34:39

trollwarrior1 (210 views)
2014-04-04 12:06:45

CJLetsGame (220 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!