The Jam Engine - and the tiny prototypes that help me build it

[Bombshell93]

Hello ladies and gentlebutts,

original post

I'll start off quick, with this,
Retro Fps Base built in my own Jam engine,

this is my retro fps base, a little messy in the code, but I'm cleaning it up as I type,
W, A, S, D - move
Up, Down, Left, Right - look
(I am working on UI elements at the moment, first on my list is pause and options, so you can remap the controls and set the display modes, the jam engine does have fitting modes ready, it was started as a pixel game engine)
My inspirations are xibalba and Delver by Priority Interupt
I'd played Delver before but I wasn't very good at it and personally didn't agree with some of its game design choices, xibalba I came across 2 days ago and it got the theme jammed in my head "this would take my life away with rpg elements", remembering Delver I decided to take the 2 games as inspiration for a project, a project which will also help me expand my Jam engine (I intend to use it during Uni, in place of the courses 1st year software GameMaker)
I have 2 Goals set for myself,
1) to expand the Jam engine with encapsulation, self-maintenance, webgl saftey and quick, easy use, in mind, with an end goal of being used for rapid prototyping
2) to create a retro fps experience with all the tender loving crippling addiction of a perpetual rpg, including an engaging world, ridiculous levels of power and ofc the retro fps secrets to put a cherry on top.
INTENDED LIMITATIONS!
each tile consists of 2 32-bit flags, though due to how javascript works, while in memory they are 2 64-bit floating points, the first 32-bit flag contains a ceiling height for each corner and ground height for each corner, the ceiling is cosmetic, the ground is physical, the player may not climb any ground a unit higher than themselves, the second 32-bit flag contains texture indexes for, ground texture, wall texture, ceiling texture and floating texture (is a wall from ground to ceiling, non-physical, useful for aesthetic and hidden passages)

EDIT: the room currently shown is a 64 x 64 map, end goal is for 4096 x 4096, with region loading and unloading
EDIT: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

I'm open to suggestions, at the moment, all I have in mind is, big psychic robot man conquering an ancient kingdom of atlantic-like technology and magics... okay so thats kind of a lot in terms of setting, but mechanics and how I will implement them are very much free to suggestion
thank you for reading

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
Thanks for reading,
Bombshell

[Kelvin]

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.

[Bombshell93]

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

[ivan.vinski]

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:

[Bombshell93]

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.

[ivan.vinski]

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!

[Bombshell93]

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;

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

[-Ash-]

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.

[ivan.vinski]

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;

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

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.

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!

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.

[Bombshell93]

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

[Bombshell93]

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

[ivan.vinski]

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.

[Bombshell93]

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

[Bombshell93]

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,

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();

The importer also imports other nodes, I'm adding controllers as I type this (animations and timelines) and cameras and lights will be simple enough, the jam engine cameras already have a camera switching system by name, so loading a whole level in from blender will be very possible, only needing live objects be placed within the engine.
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!