Fangames > Game Design

Looking for people to work with

<< < (2/3) > >>

willsherwood:

--- Quote from: Derf on July 12, 2015, 04:07:15 PM ---The reason new engines are unpopular is because I Wanna games are about precision, which comes from dedicated practice with already existing physics engines. The benefit to universality in the engines (and subsequently physics) used is that a wide range of fangames become accessible owing to the fact that one can carry muscle memory from one one to another. For the most part, people are unwilling to relearn how to play in a different physics engine as it can take a long time.

While it's certainly an impressive feat to create a new engine, and in a language few IWBTG projects have been attempted in, I'm not really sold on the idea that it's innovative. Certainly what you do with it has the potential to be innovative, but just coding an engine in another language isn't especially innovative if you're just getting yourself to essentially the same baseline as other engines. The method may be different but the result will be relatively the same until new things are added.

I question how exactly your new engine is 'limitless' and while I don't necessarily doubt it, I'd be curious to hear/see an example or two of gimmicks you've created that borderline cannot be created on Game Maker. You've nothing to fear about people stealing them if they are truly close to impossible to replicate in Game Maker as this is a community full of people who pretty much exclusively use Game Maker.

I'm interested and I do want to commend you for attempting something as grandiose as to create the next most popular I Wanna game and something that is more than just a fangame. But I'm not sure you've necessarily researched your audience - I doubt many here will be prepared to provide a portfolio as it is simply such a professional practice you are asking of what is essentially a forum of hobbyist teenagers (which I am not speaking ill of as I am one). That said, if I see more and am sufficiently convinced you are capable of doing things in your engine that would be impossible, or close to impossible, on my own in Game Maker (and that I think are interesting!), I may consider taking your offer up. If not, good luck!

--- End quote ---
Hi Derf, and thank you for your reply. When I say portfolio I don't mean some formally typed up document showing expertise at all. I just mean like, if you've made or worked on a fangame before, send me the fangame or a screenshot or something to prove that you could be helpful in the whole process. Here's an example of one thing I've never seen in a game maker game before

https://www.youtube.com/watch?v=gLMKGP_yTlA
This video shows a line attack where the lines cover up a part of the screen. This was done using trigonometry and I have never seen or heard of anything like that ever been implemented using game maker. PS: Don't mind the FPS -- I was recording every frame in 100% quality mode and saving it as a PNG... Not the fastest way to record games :-)

klazen108:
Yo!

As someone who does Java programming for a living, it is beyond awesome to see someone working on a fangame engine in Java. Are you going to release the basic engine to the community? I know there's a bunch of us who would love to provide feedback and help make it the best it could be - there's a lot of intricacy in fangame physics that can be tricky to replicate if you're not experienced in the dark arts of "pixology" as we so lovingly call it. For example, if you're using a delta-time system instead of locking the frame rate to 50FPS, then there's no guarantee that a 0.02 second tap will move you exactly 3 pixels, and many people depend on this to line up their jumps.

I understand if you'd like to keep it under wraps until you finish your game, completely understandable to not show all your cards before you show the winning hand haha. However, I'd also be interested in just hearing what (if any) frameworks you're using, like LWJGL or JOGL, to envision some of the design choices you made! (From what I can see in your screenshot it looks like you're using the standard AWT graphics system - you could really harness a lot more power with OpenGL or DirectX, just a suggestion ;) ) Having a fangame engine available in a general purpose programming language like Java would be great for the community, as even though many people are already very experienced with gamemaker, I believe in the power of competition (yay capitalism). I know I would certainly be interested in using it, to interface with all the other great things Java has to offer.

As an aside, you shouldn't brush us "game maker programmers" off so lightly, as I replicated your screen sector-blocking demo in Game Maker Studio in 20 minutes - we certainly can do trigonometry :Kappa: https://i.gyazo.com/5b20a3c3240409df06fdd89c7ab50ecd.mp4

willsherwood:

--- Quote from: klazen108 on July 12, 2015, 09:39:19 PM ---Yo!

As someone who does Java programming for a living, it is beyond awesome to see someone working on a fangame engine in Java. Are you going to release the basic engine to the community? I know there's a bunch of us who would love to provide feedback and help make it the best it could be - there's a lot of intricacy in fangame physics that can be tricky to replicate if you're not experienced in the dark arts of "pixology" as we so lovingly call it. For example, if you're using a delta-time system instead of locking the frame rate to 50FPS, then there's no guarantee that a 0.02 second tap will move you exactly 3 pixels, and many people depend on this to line up their jumps.

I understand if you'd like to keep it under wraps until you finish your game, completely understandable to not show all your cards before you show the winning hand haha. However, I'd also be interested in just hearing what (if any) frameworks you're using, like LWJGL or JOGL, to envision some of the design choices you made! (From what I can see in your screenshot it looks like you're using the standard AWT graphics system - you could really harness a lot more power with OpenGL or DirectX, just a suggestion ;) ) Having a fangame engine available in a general purpose programming language like Java would be great for the community, as even though many people are already very experienced with gamemaker, I believe in the power of competition (yay capitalism). I know I would certainly be interested in using it, to interface with all the other great things Java has to offer.

As an aside, you shouldn't brush us "game maker programmers" off so lightly, as I replicated your screen sector-blocking demo in Game Maker Studio in 20 minutes - we certainly can do trigonometry :Kappa: https://i.gyazo.com/5b20a3c3240409df06fdd89c7ab50ecd.mp4

--- End quote ---

Hi, and thanks for your reply klazen108. It is a lock-FPS mechanism (no frame skip, but rather slo-mo mode on iwbtg). The only reason my FPS was dropped on the last clip I posted was because I was outputting each screen frame to an image haha. I'm still debating about releasing to the public yet. I think I may wait to make some improvements. You are right in the fact that I am using the swing library and a double buffer strategy to draw graphics to the screen. I will definitely go into however much detail anyone would like on how the engine works though. Each level has its own responsibility to draw things to the screen. The default draws any objects added to the level and any custom code can go after it. I actually wrote this whole engine as a project for school, which required me to write everything from scratch. This means I am not using jogl or lwjgl, and I have no experience with those anyway. From what I've heard you can't draw directly to the screen with jogl and I'm really unsure about how that works. All I can say is that if I were to include jogl or lwjgl I would (probably?) have to rewrite a lot of the code. I am using an anti-aliased Graphics2D reference that uses a double buffering strategy to allow for objects to draw themselves to the screen. I'll include some structural screenshots below.





PS. I'll be more impressed when you can have those lines move around to specific points of origin and go through certain points and have different slopes :-). Also collisions!

hotpocket:
Seems cool! I've actually been working on my own little engine and fangame in Java too, using JOGL for graphics, so maybe we could learn a few things from each other. Yours is probably much better structured than mine though, since I don't have much experience in programming and this is the first relatively large project I've worked on. Looking forward to seeing the finished product!

klazen108:

--- Quote from: willsherwood on July 12, 2015, 10:27:25 PM ---It is a lock-FPS mechanism (no frame skip, but rather slo-mo mode on iwbtg).

--- End quote ---

Alright, that shouldn't pose any issues then. I'd like to see a delta-time implementation some day, but for now, that remains an interesting thought experiment (Although I think Starz0r had something along those lines, I should check that out). When your game comes out we'll see how well you did matching the physics!


--- Quote from: willsherwood on July 12, 2015, 10:27:25 PM ---This means I am not using jogl or lwjgl, and I have no experience with those anyway. From what I've heard you can't draw directly to the screen with jogl and I'm really unsure about how that works. All I can say is that if I were to include jogl or lwjgl I would (probably?) have to rewrite a lot of the code.

--- End quote ---

Well if Swing is doing well enough for you, why fix what ain't broken ;) Certainly go for getting everything to work first. OpenGL is pretty complicated, it's very difficult to make anything resembling a "hello world" example using it, so it requires a lot of warm-up time as you learn how to interface with the GPU. I would say that "you've got the proper interfaces, e.g. Drawable, set up to abstract the actual code away so you only have to update it in one spot", but it's never as simple as that is it :P You do have everything structured well though, very good to keep the responsibilities separated like that so that a game tells the room to draw, the room tells the objects/tiles to draw, and the objects/tiles do the actual drawing. That said, it would certainly require some effort to replace the graphics layer. Might be an interesting thing to fork and add one day, if the code ever ends up on github or the like!

One thing I'd really like to see is your collision handler code. Are you doing pixel-perfect collisions, or using polygonal bounding boxes? Did you write an algorithm based off the Separating Axes Theorem? That was the fastest, most functional thing I found when I was researching the subject at the time, would be interested to hear if you went a different way.


--- Quote from: willsherwood on July 12, 2015, 10:27:25 PM ---PS. I'll be more impressed when you can have those lines move around to specific points of origin and go through certain points and have different slopes :-). Also collisions!

--- End quote ---

This is why I can never get any work done :Kappa: https://i.gyazo.com/47c0c28177fcd9a74961cd180d4d04ac.mp4

Navigation

[0] Message Index

[#] Next page

[*] Previous page