Fangames > Game Design
Looking for people to work with
willsherwood:
--- Quote from: klazen108 on July 12, 2015, 11:38:11 PM ---
--- 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
--- End quote ---
Ok, now I am impressed... good job on that one! Yes, I am using the separating axis theorem for collisions backed on a quadtree setup (https://en.wikipedia.org/wiki/Quadtree). Quadtree guarantees that I'm not checking collisions between objects that aren't even close to eachother which means collision checking is actually approaching linear rather than quadratic time. Certain objects handle their collisions differently, so I have the option of using any polygon, circle/ellipse, or "pixel-perfect" sprite collisions. Also, the project has been hosted on Github since the beginning on a private repository. Programming large projects without version control is Hell...
klazen108:
Alright, very cool, seems like you know what you're doing! I'll be looking forward to seeing updates on this engine, so don't forget to keep us posted!
--- Quote from: willsherwood on July 13, 2015, 12:11:11 AM ---Also, the project has been hosted on Github since the beginning on a private repository. Programming large projects without version control is Hell...
--- End quote ---
tfw you can't fork a private repository :BibleThump: True that though, I'm happy that GM Studio splits the project file into its constituent parts to make version control possible, back in GM8 we had one monolithic blob of a project file that contained all the resources and made it impossible to track what changed... not to mention the amount of time it took to save after you packed a bunch of music/sounds/images into it *shudders*
willsherwood:
--- Quote from: klazen108 on July 13, 2015, 12:35:45 AM ---Alright, very cool, seems like you know what you're doing! I'll be looking forward to seeing updates on this engine, so don't forget to keep us posted!
--- Quote from: willsherwood on July 13, 2015, 12:11:11 AM ---Also, the project has been hosted on Github since the beginning on a private repository. Programming large projects without version control is Hell...
--- End quote ---
tfw you can't fork a private repository :BibleThump: True that though, I'm happy that GM Studio splits the project file into its constituent parts to make version control possible, back in GM8 we had one monolithic blob of a project file that contained all the resources and made it impossible to track what changed... not to mention the amount of time it took to save after you packed a bunch of music/sounds/images into it *shudders*
--- End quote ---
Oh man, I stopped using game maker in version 7, and I mostly worked in 6. Maybe the stuff it can do now would surprise me.
Aelya:
--- Quote from: Derf on July 12, 2015, 04:07:15 PM --- (click to show/hide)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 ---
lots of truth here guys
i don't doubt your coding potential and ideas, but if you lurk around "this side" of the community you'll see that the bar is, uh, not that low.
and innovative doesn't necessarily mean fun, so i guess that from a player point of view we'll only be impressed when you show us a playable demo for realzies.
Derf:
Ah, okay. My mistake misinterpreting.
From my experience Game Maker is a powerful program, even versions as far back as 8.0 (which I primarily use), but a few things inhibit it from having a good reputation: low skill threshold leading to an almost inescapable tidal wave of poorly programmed games, incredibly bulky and vulnerable compiling process (though iirc this has been improved on in GM:S) & counter-intuitive workflow (imo at least). In the right hands I think you'd be surprised with exactly what it can do, and there are certainly people here pushing the boundaries of what has been done before.
I'm not sure I'd be of much help since the extent of my java programming is a random sentence generator I made a few years ago to help write the dialogue of characters in this avant-garde play I was writing (it wasn't as terrible as it sounds haha). The coding for it was, as you can imagine, incredibly rudimentary. And as for level design and gimmicks ideas, I'm currently working on my own game right now and have not come across any instances where my ideas weren't possible in Game Maker. I do hope you continue posting about your progress though! Very interesting + inspiring project.
Navigation
[0] Message Index
[*] Previous page
Go to full version