+- The VG Resource (https://www.vg-resource.com)
+-- Forum: Creativity (https://www.vg-resource.com/forum-126.html)
+--- Forum: Game Development (https://www.vg-resource.com/forum-129.html)
+--- Thread: The Jam Engine - and the tiny prototypes that help me build it (/thread-27338.html)
The Jam Engine - and the tiny prototypes that help me build it - Bombshell93 - 06-24-2015
Hello ladies and gentlebutts,
So my goals for this topic are changing but not without reason, my goal is still to expand the jam engine and it seems I'm more productive in doing that than actually expanding a game, I do intend for small prototypes to pop out of this but I'd rather polish the engine than polish a game
![[+]](images/collapse_collapsed.png "[+]")
original post![[Image: CdfmOyv.png]](http://i.imgur.com/CdfmOyv.png)
Thanks for reading,
Bombshell
RE: Retro Fps - possibly RPG? - open for suggestion - Kelvin - 06-25-2015
Looks kinda like Tron. The ground is very hard to read, though; I didn't notice that little hill in the middle. If you're not gonna use shading, then at least make slopes and walls a different color/texture so players can know they're there.
RE: Retro Fps - possibly RPG? - open for suggestion - Bombshell93 - 06-25-2015
oh the texture at the moment is debugging texture (hence the 2 arrows on the walls, blatantly meaning positive X and Y in texture space) there will be lighting on a per tile basis, but its not a top priority,
while I'm positing might aswell make a progress report;
atm I'm making it region based mapping ready for a world builder, each region is 32 x 32 tiles and has its own assigned texture and texture offset, allowing hopefully a very diverse world.
I have had a brain storm of what I'd like the game to be,
I want a hub, with facilities to purchase items, modify / augment equipment and means to quick travel between areas, this quick travel I do not want as a teleport, I want it as a tram system, rolling you through areas you have conquered.
gunplay I'm unsure on at the moment, but I'm thinking bioshock-esque, 1 utility hand and 1 gun hand, utilities being things like flash, push, freeze, make enemy explosive? Guns will be modular, you'll have your core module determining what kind of gun it is (pellet, shotgun, missle, lazer) and then 3 modules modifying the weapon, be its damage, element, firing pattern, etc. Gun cores and Utilities should be earned through significant battles to reward the players progression.
Inventory I intend to make important, health items, armour pieces and resources for augmenting.
Enemies I want to have behaviours, perhaps the likes of which classic FPS's could not deliver, I at least want bosses to be significant figures who are unmistakable and formidable
... I dont know that I can come up with much more short of actually making it, but I figure its good to have an outline of where I'm going
RE: Retro Fps - possibly RPG? - open for suggestion - ivan.vinski - 06-26-2015
This looks nice! With all these plans, I'm looking forward to playing this game!
I have a suggestion. I know this is in early stages, but you could add MSAA so that lines look smoother. Look at this screenshot to understand what I mean:
![[Image: addmsaa.png]](http://s23.postimg.org/xw5vd3yq3/addmsaa.png)
RE: Retro Fps - possibly RPG? - open for suggestion - Bombshell93 - 06-26-2015
I understand what you mean, this is a matter of sampling rather than anti-aliasing, anti-aliasing is needlessly expensive, where as by generating mipmaps and using the appropriate min filtering I've fixed the issue, in my current version (not uploading it until the editor is ready), in my current version I've also changed how texturing works to minimize mesh complexity which has come with a slight distaste for mipmap generation, so I should simply have pre-generated mipmaps by time I upload instead.
RE: Retro Fps - possibly RPG? - open for suggestion - ivan.vinski - 06-26-2015
I'm not familiar with 3D game development so I'm not sure about anti-alias being expensive. In 2D games I've noticed it's fine.
Keep up the good work!
RE: Retro Fps - possibly RPG? - open for suggestion - Bombshell93 - 06-26-2015
I enjoy the ins and outs of graphics programming, any anti-aliasing is expensive, you have various methods of screen spaced aliasing to pick from but they all sample from an unmipmappable (a means of faster texture acces on the gpu) render target which itself is a dead weight of memory. alternatively you have hardware AA which pretty much rules out any form of depth shader (water shaders, transparency shaders, particle shaders) or SSAA (super sampled) which essentially draws the screen larger than how it plans to display and scales it down (by far the best for looks but often the worst for performance),
sorry didn't mean to babble, I'm far too passionate about graphics programming
kind of ironic as I'm committing some horrible graphics programming sins in this engine.ANYWAY! back onto progress report, I'm working on some textures while I fiddle, I'm just starting saving and loading but as you can see the editor is working;
![[Image: hCp5BhL.png]](http://i.imgur.com/hCp5BhL.png)
I'm not uploading the new version until I finish saving and loading (probably tonight) it will be an expandable binary format, for quick on the fly loading,
I figure 5 x 5 chunks loaded in at a time and 3 x 3 displaying at a time, object placement will be next on my list, after the saving and loading
RE: Retro Fps - possibly RPG? - open for suggestion - -Ash- - 06-26-2015
Anti Aliasing is one of the main things that tend to kill low end computers, that and other post processing effects. so yeah its pretty taxing.
RE: Retro Fps - possibly RPG? - open for suggestion - ivan.vinski - 06-26-2015
(06-26-2015, 04:11 PM)Bombshell93 Wrote: I enjoy the ins and outs of graphics programming, any anti-aliasing is expensive, you have various methods of screen spaced aliasing to pick from but they all sample from an unmipmappable (a means of faster texture acces on the gpu) render target which itself is a dead weight of memory. alternatively you have hardware AA which pretty much rules out any form of depth shader (water shaders, transparency shaders, particle shaders) or SSAA (super sampled) which essentially draws the screen larger than how it plans to display and scales it down (by far the best for looks but often the worst for performance),I can see that you absolutely love graphics programming. That's a lot of information I'll find useful sooner or later. I might be wrong, but from what you're talking about it seems as if those are consequences of applying anti-alias in a 3D game. Anyway, I'll make a test. My girlfriend has a laptop from 2008 or something like that, and I'll see the differences of 2D game with and without anti-alias on her laptop. My guess is that with 2D games it doesn't make much difference.
sorry didn't mean to babble, I'm far too passionate about graphics programming
ANYWAY! back onto progress report, I'm working on some textures while I fiddle, I'm just starting saving and loading but as you can see the editor is working;
I'm not uploading the new version until I finish saving and loading (probably tonight) it will be an expandable binary format, for quick on the fly loading,
I figure 5 x 5 chunks loaded in at a time and 3 x 3 displaying at a time, object placement will be next on my list, after the saving and loading
Wow! You're probably laughing at me, but I'm impressed. This is some next level stuff that's probably easy to someone who's familiar with 3D game development. I absolutely love these graphics. With each update, you make me look more forward to playing this game. As I said in the previous reply, keep up the good work!
(06-26-2015, 04:22 PM)AshuraAlchemist Wrote: Anti Aliasing is one of the main things that tend to kill low end computers, that and other post processing effects. so yeah its pretty taxing.I never thought about calling it expensive because on my laptop for 2D games of my own and some other indie games anti alias doesn't make any difference. I've completely forgotten the difference it makes when playing Arma II, for example. But then again, I haven't played anything commercial in a while.
RE: Retro Fps - possibly RPG? - open for suggestion - Bombshell93 - 06-26-2015
I'd never laugh, after all I wasn't born with this knowledge, one of the reasons I love this community is whenever possible we are encouraged to learn and or teach and never to think lesser of people sitting in our shoes from our earlier days, welcome by the way, while I've been away from this community for a while, I know of many of the frequent names, you'll enjoy it here.
as for expense, one of the pros of screen space anti-aliasing (such as MSAA) is also a con, it always costs the same performance wise, only being effected by the resolution your running, only reason its not noticeable with 2D games is because most dont use enough of the gpu for this performance hit to be significant.
also glad you like the graphics, heavy inspiration taken from Delver, I'd never thought to do grass in that way until I saw its grass and was awestruck at how good it looked
RE: The Jam Engine - and the tiny prototypes that help me build it - Bombshell93 - 06-30-2015
apologies for this but I'm changing the thread slightly, I've hit a wall in terms of the FPS due to shortcomings of my engine, I'm fixing these but they will essentially null and void the game in hand, but as a result the engine will be more versatile which was my original goal anyway,
expect a post again when I have a more solid prototype to show off
EDIT: problem has been fixed and I've started work on a larger scope FPS probably ditch the retro feel for a planet explorer,
I'm just working on the planet generator now, the planet is split into,
+X+Y+Z / -X+Y+Z / +X-Y+Z / -X-Y+Z / +X+Y-Z / -X+Y-Z / +X-Y-Z / -X-Y-Z for now represented by each by a LoD subdividing triangle,
these will form the base of the planet and provide the necessary coordinates used for mapping terrain detail,
I'd like some kind of concave terrain but how that will be achieved I've yet to devise.
EDIT: so I got the planets displaying and the mapping should be simple enough, but I've figured I'd take an easier route and have uniform Level of Detail on planets and have it so when you land you actually exit the play space of the solar system and enter the play space of the planet, that said I intend for planet simulation to continue and for them to effect the skybox accordingly, I additionally will have where you enter a planet to be where you enter and where you exit to be where you exit.
I'm going to be working on the physics engine for the sake of the planet simulation as well as some mapping and planet generation and ofc sun and lighting, by time I return there should be ship flying controls and my goal for this as a prototype will be to enter a planets play space, fly around the surface of a planet and land and explore on foot, the planets may not be all that exciting but this should be a nice goal
RE: The Jam Engine - and the tiny prototypes that help me build it - ivan.vinski - 07-06-2015
This might be kind of stupid to ask since you're the one deciding when will updates be posted, but how's it going? I'm just interested in the game you're making.
RE: The Jam Engine - and the tiny prototypes that help me build it - Bombshell93 - 07-06-2015
I'm working on the feature set of the engine at the moment, I've got basic 2D physics (AABB, Poly, Circle, Ray, Line) and I'm working on 3D physics (AABB, Sphere, Triangle, Ray), I'm also working on the content management, support for collada 3D files to be converted into an engine specific format, in the process I'm also adding ofc skeletal animation, tangent space calculation and animation mixing (those of which I'm writing at the moment), these features when finished should allow me to make a more modern Fps, but ofc I do want to stick to the retro sensibilities which inspired it.
They shouldn't take me long, I've done it all before, just need to do it clean and ofc not get lazy
I'll update when I have a sample working of the engine showing off its new 3D features, I've already got a little robot ready to run and jump around to show it all off.
EDIT: COLLADA FILES ARE ANUSES! actually collada is quite easy to work with as far as file formats go but hot damn does it take a while to wind and weave around the references, I've got meshes loading, I'm working on animation loading atm, following which I'll be organizing the content into a node system that lends itself to an expandable resource pack file format (which I'll probably just call a .jam) expect a collada viewer by the end of the week, I don't know how feature-rich it'll be though
EDIT EDIT: So I'm still working on the collada files, I've managed to make a proper system for loading them rather than an approximation of blenders exports, the node system I've created for them to load into is actually quite handy, to the point it may be used as the basis for the engines file format or at least for its resource format. Anyway I've just got meshes generating properly with all components in tact with the single exception of bone indices and weights BUT I know how to do those now, they are contained in an armature object controller aptly named the skin in blender and luckily linked in the object node, a little convoluted if you ask me but I'll support it regardless
RE: The Jam Engine - and the tiny prototypes that help me build it - Bombshell93 - 07-11-2015
Okay so this is kind of a hollow update as you won't see the effects just yet, but I'll give you this screenshot and explain why its awesome,
![[Image: AMiYk7J.png]](http://i.imgur.com/AMiYk7J.png)
This is a model successfully loaded from a dae file, along with it (though not displayed here) I have properly loaded all other mesh data, including full support of multiple normal and uv maps and group weights. using this from the outside is as simple as;
Code:
var scene = new Scene();
scene.fromDae('myUrl/myFile.dae');
var geometryNode = scene.nodes['myMesh-mesh'];
//scene.typeLibraries.geometry['myMesh-mesh'] also works and would probably work faster as typeLibraries contain smaller groups to search through
var mesh = geometryNode.generateMesh(['POSITION']);
//the first argument is an array of attributes you would like, in the order you'd like them, e.g. ['POSITION', 'NORMAL', 'TEXCOORD0']
//the index and vertex data is created with this in mind for optimal index buffer usage
mesh.draw();this may not be all that exciting to some of you, but trust me, I have big plans for this engine and this is a big step in the engines resource management.
THOUGHT DAE FILES WORKED, BUT TURNS OUT BLENDER EXPORTS THEM BROKEN!