Veni Vidi Ameche! posted:

Because I want to generate them, not draw them. I’m trying to find out if there is established math or algorithms for this purpose. If not, I’m curious what approaches occur to others.

Elentor posted:

Elentor posted:

full point posted:

Svelto TaskRunner (github)

roomforthetuna posted:

I made a Mahjong solitaire game with Facebook integration (which doesn't work for invites yet because they direct people to the facebook app page, which won't load unless either the user has already approved the app elsewhere, or Facebook has approved the app, which review apparently has like a month long waiting list at the moment).

Just made with raw HTML5, drawing using canvas instructions (no bitmaps at all except for Facebook-imported faces), and super lazy; I don't pre-render to bitmaps and I don't skip drawing hidden faces, because the performance didn't seem bad enough to merit making the effort, even on a Chromebook. I did the scripts with ES6 and built it with parceljs.

It's here if anyone wants to take a look. (Doesn't require Facebook permissions, you can just play solo non-challenge.)

Fun bug - if you leave it on the menu for a while, in Chrome, the font of the challenge button changes size. This only happens with the 'compiled' javascript, and seems to be only in Chrome. It seems like measureText starts returning a different size after some number of repetitions.

Comfy Fleece Sweater posted:

Wow it runs surprisingly well on an iPhone, nice job. Would like it to fill the screen though, very small window on mobile.

ddiddles posted:

Anyone have any decent tutorials that go over more advanced Unity concepts, rather than the standard game dev version of "hello world", with simple movement?

I've been messing around with it for a bit, and I'm having a hard time imagining how any sort of complex game structures its GameObjects and code. I've been trying to wrap my head around composition based architecture, but I'm not really that sure how granular you should be getting, and how you should be sharing data and references between scripts.

For example, I have a LocalPlayerMovement script that needs the players rigidbody to run, as well as the ability to read player input. It calls a method on a PlayerInputManager script to get the current axis values to calculate the force needed to move, as well as a PlayerReferenceManager that is a central point to store all the components scripts need access to often.

In addition to that, I have a PlayerAbilityJump script that also requires the players rigidbody. It uses the same components as LocalPlayerMovement to get the jump button press to fire off the add force, and uses the reference manger to get the players rb.

I have no idea if this is the correct way do this as I think about more complex relationships, like storing the characters equipment and inventory, equipping weapons, etc. I feel like like I'm over complicating something I don't even understand yet.

Lork posted:

I don't think there is an established "right way" to do things, but for whatever it's worth, my instincts tell me that you're stratifying your code way too much. "Player Input" "Player Movement" and "Player Jump" are all interrelated enough that it would make much more sense to me for them to all fall under the domain of a single "Player Controls" component. Where does it end? PlayerAbilityAttack, PlayerAbilityStrongAttack, PlayerAbilityUsePotion, PlayerAbilitySwitchWeapon, and on and on... Each needing to be hooked up to who knows how many other components they need to do their job. I don't see any benefit to doing things that way.

ddiddles posted:

I was thinking about having different weapons with different characteristics, and how having a large WeaponController script would require a bunch of switch or if/else statements to set up the weapon correctly.

This might be because my background is in JavaScript development living in MVC land, so I'm used to have a set way to separate data, logic and display.

OneEightHundred posted:

The end begins: Apple has deprecated OpenGL on macOS.

Doc Block posted:

Meh. OpenGL has been dying for a long time across the board. It's been effectively dead on iOS since Metal was introduced. People should've seen the writing on the wall for OpenGL on macOS as soon as Metal was brought over from iOS. I mean, hell, Apple didn't update OpenGL at all for the previous macOS release, opting instead to leave it at OpenGL 4.1.

My main system, a 2011 iMac, is too old for Metal (and too old for the upcoming macOS 10.14) which is a real bummer, but even I'm not mad about it and knew this was coming sooner or later.

At least Metal is a nice API.

Jewel posted:

For what it's worth, Celeste's had 2.5% of total sales on mac, and its most likely mirrored across the board . It doesn't seem worth it to take the time to port to metal. This is going to bite the game market bad I think.

96.3% of steam users are on windows, 3% on mac, 0.6% on linux.

Doc Block posted:

They’re already doing their own GPUs. The A11 used in the iPhone 8, iPhone X, etc, has an Apple-designed GPU.

Doc Block posted:

At first they used PowerVR designs, then they used customized PowerVR designs, and now they’re using their own GPU designs starting with the A11.

News that Apple would no longer be a PowerVR licensee hurt PowerVR’s owner pretty badly.

Nude posted:

You should probably just start here; those posts are 11 years old, so a lot are probably outdated. Got any questions/particular resources you are interested in?

Elentor posted:

None of the examples are very hard to recreate procedurally, but as far as "expandable" goes you'd have to be a lot more specific as to how different from a simple capped cylinder you want, because these things can range from trivially easy to unfathomably complicated. But in general what you want seems to be:

1) Create a cylinder of a certain length with X sides.
2) Have the option to cut the cylinder halfway and control the height of the cut.
3) Be able to perform boolean operations, at the very least a boolean merge, though a subtraction would be useful as well.
4) Have at least these controls/references on the API:
* Power over the vertices pertaining to the cylinder's body.
* Power over the vertices pertaining to the caps.
* Power over the vertex of the tip.
* Power over the vertices of the central cut.
* Same as all the above, but with edges instead of vertices.
5) If you want to expand, the ability to create classic diamond cuts:
* The ability to create bevels from an edge (so you can create an Old Single Cut)
* The ability to create bevels from a point connecting two edges (so you can create a Mazarin Cut+)
* The ability to cut an edge on an arbitrary position and have it automatically triangulated (so you can create a Mazarin Cut+)
* The ability to connect two arbitrary points and have it automatically triangulated (so you can create any other relevant cut)

None of the examples given seem to need an L-system but if you absolutely must, you can add a simple tree reference and the ability for the spawn position of an n crystal be the body of an n-1 crystal and limit the width of the crystal to the size of the polygon or adjacent polygons you're spawning the crystal on though that all seems incredibly overkill especially if you want to make it not suck.

With 1 through 4 you can create all the examples given in an extremely simple manner. Most of the crystals in the first image and second are 6 sided cylinders with random offsets. The diamond in the first image can be created by creating an n-sided cylinder, scaling down the top cap triangles, then rotating their vertices 180/n degrees around the center where n = the amount of sides of the cylinder you're using. Move the vertices of the bottom cap except for the tip up. For example, this operation on cylinders of 4, 6 and 8 sides, notice how the shape is the same as the crystal in the first image you posted when n=4:





For the other examples you just perform random rotations and offsets on vertices. For the base you spawn a bunch of 4 or 5 sided, scale them down and perform huge offsets on random polygons, then boolean add them. For the crystals with rhombus-shaped tips in the second image you offset every odd cap vertex of an even-sided cylinder:





For the final result you just stick a bunch of them together around a small area with higher rotations the further away they spawn from center.

Edit: Also, just to make sure, don't forget to add the ability to split triangles, to harden/soften edges (Maya) or smooth groups (Max). You can have a smooth transition by sharing a vertex between n triangles and having that vertex face towards the average of the normal of the triangles. You harden the edges by have each triangle have its own set of vertices all facing towards the normal. Most of the crystals you showed would be better having every triangle split, though you can make a single quadrangle made of two conjoined triangles for each side of the cylinder to preserve that quadrangular facet look.

Khorne posted:

Am I insane for thinking of using the 3rd dimension of an octree, or similar structure, to represent time for a discrete 2d grid? I had this idea while driving, and a quick look over literature and web articles doesn't seem to show anyone doing this. Or even thinking of doing this. When this happens, it usually means my idea is total garbage and I am overlooking why.

One thing that's messing with me a bit conceptually, without working through it at all, is that there are presumably situations where you'd want an irregular resolution, aka not a cube. Being able to look n steps forward without adjustingthe x,y boundary may be useful, or looking at a fixed or minimum depth x,y cell with a larger sized z-axis. I realize violating the cubic split would make it not an Octree and I also realize an octree can somewhat account for this at the cost of accuracy by just accepting you're increasing the search space. So let's look a bit at the octree side of things, there are useful applications (like pathfinding/AI) where the normal depth split of an octree trivializes some problems provided you modify the property you're propagating up the tree (think of dampening by some function of distance from the centerpoint, or reducing the value for each level of the tree it propagates up, kind of similar to FMM).

There's also the issue of time continually moving forward. It will represent a discrete 2d grid of at most 256x256 (or some other chosen constraint). This means if our z axis expands beyond 256, consider situations well beyond like say magnitudes further forward, things will get pretty "worst-case". I can think of some ways to combat this, mostly by not allowing it happen through some method (there are a few, one is if the time axis value would exceed a preset limit to make a new octree with the parent node being "now" and copying over all "now" and future nodes from the old tree). Heck, even looking at the base case (many objects in a 256x256x1 space) is perhaps not ideal for an octree. Then again, this may not even be a real issue because we know the x,y constraints and any entity added to the octree will have a known "location" from its known x,y,t values allowing for insert, traversal, and range optimizations.

I was hoping I'd find someone suggesting this on stack overflow and some big nerds telling him he's an idiot and to use this data structure or that there's no advantage. I'm recruiting you games dev posters, to be big nerds and tell me I'm an idiot. I mean, there's probably a better structure for this, right? I'm effectively creating a time-varied density function for a 2d grid that I can get a time-averaged value from for a subsection of the grid over a given time period. Doing it with an octree simplifies that a lot but also has some potentially undesirable constraints. Maybe there's a more ideal method or structure that I'm not familiar with.

Related note, the game this for has more "concrete" actions than most other games. Issuing a move command that traverses 20 tiles on the grid has a start point, end point, and pre-determined velocity. This allows for calculating quite far into the future with no interpolation, and it allows for calculating exact x,y,t intercepts using newton's equations of motion as well as knowing exactly where things will be until an object's old command ends or is interrupted for almost free provided you have an accurate object list to check. Nearly everything in the game is like this, so there is perhaps a larger advantage to using this method, or a similar one if I am a big dummy who's overlooking some other, better-suited approach, for this particular game than in a game where player motions and actions even half a second in the future are unknown or must be interpolated.

ps the procedural generation of crystal post is very good.

Khorne posted:

Am I insane for thinking of using the 3rd dimension of an octree, or similar structure, to represent time for a discrete 2d grid? I had this idea while driving, and a quick look over literature and web articles doesn't seem to show anyone doing this. Or even thinking of doing this. When this happens, it usually means my idea is total garbage and I am overlooking why.

KillHour posted:

Add a gameobject field to the inventory item and drag the actual item into it via the inspector? I think that still works with a prefab.

Khorne posted:

Am I insane for thinking of using the 3rd dimension of an octree, or similar structure, to represent time for a discrete 2d grid? I had this idea while driving, and a quick look over literature and web articles doesn't seem to show anyone doing this. Or even thinking of doing this. When this happens, it usually means my idea is total garbage and I am overlooking why.