next »

[JWki]

In that case I'll be glad to!

Oh, and pointer arithmetic for that matter. I don't really do that very much otherwise.

Well there tends to be a lot of pointer arithmetic in the code I write for some reason. Even in web code 

[Richard Kain]

I had a pretty good time programming last night. I've been working on a plug-in for Unity that creates basic links between gameobjects. It allows you to metaphorically "point" gameobjects at each other, and use those links for game logic. One of the basic applications I envisioned was in creating basic board games, such as chess and checkers. As part of the plug-in, I've been coding an extra tool that automates the construction and assignment of basic grids. You choose your options, pick a pre-fab to serve as the basis, click a button, and presto, you have a game board with links between all of the tiles.

One of the features I've been trying to add recently has been the option of creating a staggered grid. This takes a little more doing, as positioning of the individual tiles relative to the board's origin has to be tweaked, as well as the tile assignment options. Thankfully, I a few tricks that I had come up with for cycling through the List of generated tiles really helped out, and my current code for it is working well. I'm actually almost done, and the current implementation is stable enough that I will feel confident in releasing it. Staggered grids are necessary for creating isometric as well as hexagonal game boards. Both of these are popular enough in various types of games that I felt it worthwhile to add support for generating them.

[oahda]

Not sure I understand what you're doing. :c Could you offer some concrete example?

[Richard Kain]

Not sure I understand what you're doing. :c Could you offer some concrete example?

I'll give it a shot.

Unity has a capable tag system. But tags are more designed to allow search access to large groups of gameobjects. By default, there is no means in Unity to describe relationships between individual gameobjects. Part of this is due to the component architecture. Often times, it is assumed that gameobjects will bump against each other, and then you can base game logic on what individual components those two objects possess. For many instances that is all well and good.

But there are times in some games where pre-defined relationships are desirable. One of the early use-cases that I was envisioning was a simple board-game, like Candyland, or Chutes and Ladders. Creating "tiles" for a board game like that isn't hard. You don't even need a modeling program. For prototyping purposes, you can just make a cube object in Unity, and adjust the z-axis scale to flatten it a bit. Boom, you've got gameobject to serve as a tile. But its relationship to the other tiles is going to be central to the game's mechanics, how do you define those relationships?

The component I created to answer this need is extremely basic and simple. I defined a very basic link data class, that contains little more than a string to serve as a label, and a reference to an instance of the base component. The component itself contains a very basic array of that link class, and the needed functions for accessing data from that array. A custom inspector provides a GUI interface for adding and removing links in Unity's interface. I threw in one extra property to allow the selection of a "default" link from the list of existing links. The links can be accessed via script by their label names, using a public function. The label names can follow standard naming conventions, but don't have to. They are intended to be readable by the user.

In the case of the board game, you would simply apply the component to each of your game tiles, and a "Next Tile" link to each of those components, and then select the tile instance that each of those objects will lead to next. Now you have a defined game board in your scene that can have basic game logic applied to it.

I've already thought of other potentially useful applications, but this is a basic example.

[eerr]

Will the setup work in non-unity C# programs?

[Richard Kain]

The general structure would, if you were dealing with a somewhat similar component model. The basis for all of the storage is just a simple C# List. Everything around it is some basic nuts-and-bolts coding to make it easier to access and work with from outside of the class. (returning a list of links as an array of string labels, etc...)

It's really nothing fancy, just a very basic class for referencing objects from other objects in a more dynamic and readable fashion. I came up with it when I tried to think up the bare minimum structural information I would need to construct a version of chess. The rest was just fleshing it out a bit to provide more options.

[bauer]

The last 3-4 weeks I've been re-creating our engine for Super Sportmatchen with the main intention of having clean multi-platform support from the start. My aim has also been to learn how to program in a more "lean C" kind of way instead of the heavy C++ way of coding that I've mostly been doing. As someone mentioned recently, it is a lot more fun to code when you're aware of the bits and bytes instead of hiding it all behind crazy libs and templates! For me that means no STL (especially no std::string and std::map), no SFML/SDL, no crazy class hierarchies etc. It's all basic but highly functional C-type code, compiled with a single .bat file as a single translation build (~1s compile time!).

I wish I could tell my teenage self to not listen to the OOP teachings and "don't be afraid of the bytes and pointers" or something.

[oahda]

@Richard Kain:
Would be neat/helpful to see that custom editor, perhaps in the context of an example in the scene view as well. c:

I wish I could tell my teenage self to not listen to the OOP teachings and "don't be afraid of the bytes and pointers" or something.

I personally prefer a healthy balance in between either extreme school of thought. Just try to make the best choices for each particular situation, taking every aspect into consideration. c:

[JWki]

The last 3-4 weeks I've been re-creating our engine for Super Sportmatchen with the main intention of having clean multi-platform support from the start. My aim has also been to learn how to program in a more "lean C" kind of way instead of the heavy C++ way of coding that I've mostly been doing. As someone mentioned recently, it is a lot more fun to code when you're aware of the bits and bytes instead of hiding it all behind crazy libs and templates! For me that means no STL (especially no std::string and std::map), no SFML/SDL, no crazy class hierarchies etc. It's all basic but highly functional C-type code, compiled with a single .bat file as a single translation build (~1s compile time!).

I wish I could tell my teenage self to not listen to the OOP teachings and "don't be afraid of the bytes and pointers" or something.

Did you watch Handmade Hero?

I personally prefer a healthy balance in between either extreme school of thought. Just try to make the best choices for each particular situation, taking every aspect into consideration. c:

That sounds like a healthy approach. Even though I guess everybody comes from one of the two directions originally so everybody has a certain baseline way of thinking. I'm still trying to find a spot that feels good to me.

[oahda]

Did you watch Handmade Hero?

Hah, I actually thought the same thing, because I've been watching a few of those streams this week!

Even though I guess everybody comes from one of the two directions originally so everybody has a certain baseline way of thinking. I'm still trying to find a spot that feels good to me.

Yeah, I'm actually currently pondering all the functional craze that's going on at the moment. An orthodox functional approach doesn't seem like it's the best tool for the job when it comes to most games, as they are all about state, but perhaps there are still lessons to be learned about affecting state as little as possible wherever possible from it, so long as it makes sense and doesn't make the program more difficult to work with, since it may help lower the rate of certain sources of bugs, maybe?

[JWki]

Did you watch Handmade Hero?

Hah, I actually thought the same thing, because I've been watching a few of those streams this week!

Even though I guess everybody comes from one of the two directions originally so everybody has a certain baseline way of thinking. I'm still trying to find a spot that feels good to me.

Yeah, I'm actually currently pondering all the functional craze that's going on at the moment. An orthodox functional approach doesn't seem like it's the best tool for the job when it comes to most games, as they are all about state, but perhaps there are still lessons to be learned about affecting state as little as possible wherever possible from it, so long as it makes sense and doesn't make the program more difficult to work with, since it may help lower the rate of certain sources of bugs, maybe?

Yeah HH is a great learning resource!

Regarding functional programming, I like the idea of pure functions that don't modify any state at all and instead take immutable data and produce new immutable data. It's certainly a good tool for API design, although of course not applicable everywhere.

[InfiniteStateMachine]

A funny example Carmack made was in a pure functional world  when you want to draw a pixel you take the frame buffer, then throw it out and return a new frame buffer with the modified pixel :D

Of course that's not really how it works but it's a good introductory example.

[qMopey]

A funny example Carmack made was in a pure functional world  when you want to draw a pixel you take the frame buffer, then throw it out and return a new frame buffer with the modified pixel :D

Of course that's not really how it works but it's a good introductory example.

Well that is more or less what double buffering is

[ProgramGamer]

Or, you know, shaders.

[JWki]

Or, you know, shaders.

Not really.

[ProgramGamer]

Well, you'd be drawing more than one pixel at a time, and instead of creating and deleting frame buffers, you'd be using existing ones. I'll admit that the subtlety of drawing only one pixel at a time with this method got past me in the above example, but still. Shaders are about processing images pixel by pixel, so I don't think I was completely off the mark, at least conceptually

[qMopey]

Well, you'd be drawing more than one pixel at a time, and instead of creating and deleting frame buffers, you'd be using existing ones. I'll admit that the subtlety of drawing only one pixel at a time with this method got past me in the above example, but still. Shaders are about processing images pixel by pixel, so I don't think I was completely off the mark, at least conceptually

Well he was talking about functional programming where instead of modifying state (like a framebuffer) you create new state that represents a delta. So each game tick the old state is thrown away after new states are constructed that encode a delta. It's a dumb idea in practice but conceptually it can be useful to think about or toy with.

[ProgramGamer]

I understood that from the start.

[qMopey]

Oh gotcha. It sounded like the point was about functional state deltas, not really about the pixel drawing part. You're right shaders do draw pixels, but it did not sound like that was the focus of the conversation.

[ProgramGamer]

In any case, I expressed myself poorly. That'll teach me to blurt out things in a technical thread lol


On another note, I'm happy because I finally managed to figure out how to do vsync with SDL2. All you had to do was use a renderer, give it the right tags and use RenderPresent. I was trying to implement my own timestep with timers and wait commands before. You can scold me, I deserve it.