Jacob Kovac on KivEnt

Can't actually remind remind each other of these things because inevitably 1 of these days we're gonna forget. Yeah.

Hello, and welcome to podcast.init,

the show about Python and the people who make it great. We're recording today on June 17, 2015.

Your host as usual are Tobias Macy and Chris Patti.

You can follow us on Itunes, Stitcher, or TuneIn Radio.

Please give us feedback. You can leave us a review on iTunes,

contact us on Twitter, send us an email at host@podcastinit.com,

or leave a comment in our show notes.

I'd just like to say, we don't have any corporate sponsorship or advertisements in the show because we are making it for the community, and we respect our listeners and value your time.

If you'd like to help support the show and keep it ad free, you can find out how by visiting our website. That's podcastinit.com.

Today, we're interviewing Jacob Kovach about the Kibbent game engine, which is based off of the Kibbe library.

Jacob, could you please introduce yourself?

Alright. So, my name is Jacob Kovac. As you said, I'm a core developer of Kibbe, 1 of the youngest core developers and kinda new, so I'm I'm not really super great at it, but I'm learning.

And I've been building the Kibbent engine for

about 2 years now. I live in Salt Lake City, and I, kinda

have done a variety of freelancing

and entrepreneurial

programming stuff for the past few years, basically.

Very cool. So, Jacob, how did you get introduced to Python?

I graduated college in 2012. And kinda right out of college, I had started a,

a software development company and kinda web development

company is mainly what it did. But we dabbled in software a little bit with a friend from high school and 2 friends from college.

At the time, I was the web designer and graphic designer for the company and didn't really do a whole lot of programming,

but we we were running behind on a project and I really hate missing deadlines and stuff. So I kinda just

picked it up, and this was a project we were building in Kibbe that was a,

think it was kind of like a fitness tracker

designed for, like, middle school gym classes, you know, to track how many push ups and pull ups and sit ups and things the kids did.

And so that was really my first programming experience

other than some kind of dabbling I'd done, and I took 1 class in university.

But other than that so that I kind of hit the ground running with Python with a deadline and a client we needed to please.

And I've been doing it since then, actually.

That's very cool. It's definitely a good inspiration to learn something and just sort of dig in and having a project to work on is really the best way to learn programming

is what I found.

Did you have training in graphic design from college or something that you just had taught yourself before getting into the the web design industry? Or

It's pretty much something I had taught myself as well. I actually went to school for economics

and

kind of philosophy stuff, but, I've always kind of had a passion for math in high school. I kept in the math team and did lots of, you know, that kind of stuff,

math on Saturdays and so on. And so programming kinda naturally grew out of that a little bit. And I've always had an interest in kinda

the artistic side of things. And so I find that

the, graphic design and the programming and the math go really well together when it comes to making video games since that's basically the 3 parts.

Very cool.

Could you please give us a high level overview of Kibbent and how it differs from other game builder frameworks like Unity or Unreal?

The first thing is that Kibbent really does 3 things for you at base. I mean, it it gets more complex than this. But

number 1, it gives you a way to manage the memory for your game objects so that they are stored contiguously for

processing.

Since,

when you have a game, you're really kind of looping through

1, 000, maybe 100 of thousands of objects if it's a modern game,

and doing all kinds of random code to all those different objects based on what they are. And And so 1 of the number 1 things you need is for those things to be stored as continuously in memory as possible

in order to keep them from

keep your processor from jumping around in memory all the time so that you slow your loop down and you have poor performance.

And so it it gives you a method of continuously managing game object memory. It introduces a new real time focused rendering pipeline to Kibbe. The Kibbe pipeline has really been designed for

sparsely updated things. Like, in most graphical

interfaces,

most things are stationary until you touch them or interact in some way. And so Kibbe was really designed to save battery on mobile devices and things like that. So it doesn't actually do any updating until it needs to.

This is, of course, sort of not what you want for real time graphics since you actually know for a fact that you're gonna be updating

30 or 60 times a second, all of your game logic.

And so,

a completely new pipeline for the most part has been introduced in Kibbit that focuses on being more performant in real time cases.

And then finally, it there's kind of a,

bit of Python magic that allows you to

have game objects that are completely manipulatable

from Python,

but have their actual update loop on on all the game objects

pretty much not touch any Python

at all

because, I mean,

I think we kinda all know Python is a little

slow, and I it's usually fast enough is kind of the mantra going on. But for games, you really

you don't wanna have too much pipe on overhead because when you do have it, it,

it'll slow you down a lot. I recently increased the speed of our, render, the Kevin's rendering loop by, 38 times by removing a single

list lookup that was in kind of the inner loop, not even the most inner loop.

But,

any Python at all can really

hamper your ability to compute real time kind of displays,

basically. And so and then how does it kind of relate to Unity and Unreal?

Number 1, Unity and Unreal are largely 3 d focused. And at the moment, Kibbent is mainly 2 d focused. I really would like to dive into 3 d at some point, and I think we would be capable of it. But there's a lot

of extra things that would need to happen to get us there.

However, Kibbit does use a very similar

architecture to the entity component architecture used by Unity, and I think Unreal has moved that way as well. And 1 of the key

advantages, I think, of Kivint is that it is

pretty much Python all the way down. When we get really to the lowest level stuff, a lot of it is Python and manual pointer management and memory and stuff. But for the most part, when you write a game with Kivant, you will be working entirely with Python constructs and Python data

with the option to dive into a deeper kind of c level API if you want to.

But the whole thing is

the whole thing is set up to be familiar to Pythonistas,

to give you the ability to build a fairly

performant game, not triple a or anything, but maybe a. That's I I sometimes tell people I'm aiming for a level games.

To be able to be built in Python, to be able to control the entire rendering loop and anything like that

entirely in Python or a little bit of Cython if you really need the extra performance.

With regards to not being 3 d, I don't think you should beat yourself up about that because

I think that, you know, especially recently, there's been this whole focus in the gaming industry

around,

you know,

2 d has not been fully explored yet, not by a long shot. And there's so

much amazing gameplay

in a way, you know, 3 d can be kind of a distraction. Right? Like, I mean, but there's this whole trend towards

making really great rock and 2 d, you know, comparatively old school for for most people who were kind of brought up on a diet of 3 d games,

productions,

and they're incredible. So I think Kivant being kind of firmly in 2 d space for now is not is not a bug, it's a feature.

Oh, yes. I absolutely I love 2 d games. I love that we're seeing a resurgence. I really grew up in the nineties, and so something I always think of is the fact that,

for my whole generation, the black and white Pokemon red and blue on the original game boy just captured our entire imagination.

That world was so real even though it's only, you know, 16 grayscale colors and barely any art at all. And I I really think it's amazing to see

2 d games and really almost all types of old kind of games coming back with the whole indie game development thing going on nowadays.

We're really starting to see a whole lot of different types of art. And there's definitely, like you said, a lot of,

a lot of places that are underexplored

or not even explored at all because you couldn't do some of these things

back when 2 d games were really in their heyday. The the computers were so much less performant.

I mean, you didn't have any of the modern kinda shader pipelines or any of those type of things, basically.

Or even ubiquitous Internet working. Right? I mean, like, you know, which is now everywhere. You can even deploy your game on your mobile device and and still do multiplayer because the cellular network is everywhere. So it's really kind of like it's like, as you say, this territory has not been explored and all of the infrastructure that game developers used to be

straining at the edges of in the old days. Now, computers are

many hundreds of time orders of magnitude more powerful, so

all those restrictions kinda go out the window.

Yeah. And that's definitely a key thing as well is that we're really just trying to bring some of those advancements and some of those kind of ways of thinking and ways of building games to Python since

pygame and,

most of the other

kind of options

in the Python world are really rooted in like a very, very old school

way of thinking about computer graphics that barely even deals with the GPU, really.

And and that's you're not gonna have a really good time, particularly if you're targeting

mobile without

trying to make as good of use of the GPU as you can, basically.

Absolutely. And I just wanna say real quick with regards to the 2 d versus 3 d debate that I'm old and I you know, you mentioned you you cut your teeth in the nineties on Pokemon. I cut my teeth in the in the eighties on, you know, Intellivision and Atari and and 8 bit computers. So and I still love and play the dickens out of some of those games because they're fabulous. And and

the gameplay

in those things is amazing and timeless, you know. So I I just think this is all great. This this trend is some 1 that I really applaud.

I think you also sort of get the focus because in a 2 d game, you you don't have all the pixels in the world. You don't have the ability to do things photo realistic. And so especially as I've gotten older, I appreciate the focus and the ability to pick up a 2 d game and understand what's going on. In a lot of modern 3 d games, I find I feel like you sometimes are just staring at a bunch of green, gray, and brown kind of pixels trying to figure out what what thing you're actually supposed to be looking at or looking

for. A a lot of games, The Witcher 3 even comes to mind,

have, like, buttons you can press to highlight the stuff you really should be looking at because they know that's a problem. As

we've tried to go for photorealism,

we've lost a certain

sense of focus on the game part of a game in favor of a focus on kinda

the entire simulation as a whole.

Yeah. And going back to

the resurgence of retro oriented games and also the design

and

enchantment of older games. It's really just an example of how constraints can really bring out the best in people as they're working on a problem

because

they they really have to think creatively about how to create the experience that they're looking for. 1 of the best examples that I've heard of thinking creatively to create a game is when they were making Pac man and they were trying to figure out how to program the ghosts so that they would follow pac man in an appropriate manner. What they did is they decided that pac man would leave a smell trail,

And so, programmatically, they made him leave a scent trail and the ghosts were following the scent. And that was how they were able to create the algorithm to make the ghosts follow Pac man. It's just really a beautiful example of constraints leading to a really elegant solution.

And I think, constraints bring up a good point, and I think this is something that'll probably be weird for a lot of Pythonistas.

Kivint is actually

built with constraints in mind. You actually have to, for instance,

declare a maximum amount of game objects that are going to be in your game. And in general, there's a lot of static allocation that happens.

Because ultimately, if you were really going to be shipping a a professional game, even if you built it with some dynamic

parts, at the end of the the life cycle there, you would probably go in and make a lot of the dynamic areas static because you gain a ton of performance from that. And, you know, so, like, for instance,

most games have a limit on exactly how many lights can be on scene at 1 time or something, anything like that, really, all over games are are static constraints. And those things are

really at the forefront of K event because I think that constraints help you do better art, not worse art. And being able to set limits and work within them causes you to come up with creative

solutions as you as you pointed out with the Pac Man anecdote.

For anybody who's interested in Pac Man and the kind of detail that Tobias just gave, I'll I'll add it into the show notes. There's a really amazing,

web page that and I forget the gentleman's name, this man basically

did this incredibly in-depth study of of the the intricacies of how Pac Man was made and the, you know, disassembly of the code, it's called the Pac Man dossier. And, it's it's really great super geeky reading.

So what inspired inspired you

to

create the Kivent engine? The game engine, actually, I referenced earlier that right out of college, I had started a company. In late 2012, we kind of pivoted to trying to

bring out an Android game, just a simple infinite runner.

And really, and it was built with Kibbe. We ran into some

it was working great on the CPU, I mean, on the desktop and on a tablet we had.

But on older Android hardware, it was running terribly. It was just really sad. It just chunked in, you know, 10 FPS and things like that. I had a droid 1 at the time, so that's practically the first Android device, and it it could barely run it at all. And the frustration the team had related to that performance problem really eventually led to it abandoning the game, and, actually, the team broke up and everybody went separate ways. The whole time, I really

was saying to myself, yes. Python is slow,

but, I mean, we used to do kind of more than this on Game Boys and things. We I mean, computers,

especially mobile, aren't fast, but they're not slow either. I I I remember when I was excited to get a 200 megahertz computer so that I could run, you know, modern games at the time. We easily could do

more with less, and that's really what led to Kivint as I started down this really long and experimental road looking for how I could build games in Python

with 1, 000 to tens of thousands of objects and hundreds of thousands of vertices and, you know, with with major data. Data enough to build like a kind of modern game.

Is there a particular kind of game Kvent is particularly suited for versus any of the other popular

frameworks? It focuses mainly on 2 d games, but I've tried to be, relatively

agnostic into what type of game can be built with it.

And I mean, the basic Kvent really provides little more than some data memory management and renderers,

basically. There's there's additional modules that add more stuff. It really should be suitable for nearly

anything. It kinda

has my interests are largely in procedural generation kinda action y games. So it does

the pieces that are in existence are sort of focused on solving problems I had myself.

But I tried to solve them in a general way that I hope will be useful for others as well.

Does Kiven have any particular support for multiplayer

games?

I kind of consider multiplayer to sort of be out of the scope. Being built on Kivi, Kivi kinda relies on having a graphical kinda context

to do a lot of stuff, and you probably would have a bad time trying to run Kivi on a server for instance. It'll at least error out when trying to make a window and things.

And so multiplayer

seems to me to kind of be you could build the client for a multiplayer game in Kibbit, but there's nothing

in Kibbit right now to help you build the server

or to handle pulling the data from the server into the client and stuff. You'd have to choose any of the really innumerable Python frameworks that help with that type of stuff.

You know, that's that's a really good point though. Right? So Kivint solves the problem of

you know, being a framework that allows you to

dynamically

move objects around the screen and handle the memory management and the other low level details like that.

And as you say, you know, that the server side pieces are interacting with the server.

You don't necessarily

provide

facilities for that, but there's no reason developers can't layer those in from

from other tools. And I realize I just I said exactly what you just said,

but, I guess I'm just trying to put a more positive spin on it in the sense that it's not like Kivant is a bad framework for making multiplayer games based on what we just said. It's just that this particular piece does not encompass that functionality.

Right?

Yes. Very much, Abel, and thank you for doing the marketing for me, by the way. But

very similar to Kivy's approach, the Python ecosystem is huge and full of wonderful, wonderful

libraries and various different approaches to nearly any solving any problem at all. You usually

have 3 to 10 options for any anything you wanna do in Python.

And so Kivy and Kivint try

to handle graphical

and input management sides of that while still giving you the full benefit of using whatever part of the Python system you love most

to handle

problems that are sort of ancillary to the to the main problem of getting data to the GPU so you have nice graphical

displays. Does the fact that Kivint games need to run on so many platforms present any unique difficulties in the development of Kivint?

Yes and no to some extent. Really, Kivy is

wonderful at cross platform and has solved most of the problems so that I rarely even think about how things are gonna work on Windows versus Mac versus Linux or Android or whatever.

There have been some times when

cross platform miss, and particularly the difference in GPU vendors, have reared their ugly head, so to speak. I had a really wonderful performance enhancement that was running great on my desktop, and then I found out that it doesn't run at all on some Android and doesn't run on Intel graphics processors, and so I had to end up dumping that.

So in a way, it has forced me towards

trying to find the most general and best implemented

way to work with GLES 2. And I mean, you don't really get many options in ES 2,

but there's still a little bit of area where you could choose between this function and that function or this approach and that approach. And I've tried to

find the middle ground where it's fairly performant on every system

and and also works everywhere, which can be a little harder than you'd think. And I've also kind of started on a little task of trying to document areas where you should be aware

that, like, certain hardware will cause problems if you do things that you might expect you should be able to do. I have a, tablet here that cannot transfer

matrices larger than a a matte 2 by 2 between the vertex and fragment shader. And for instance, there's all kinds of little gotchas like that throughout the especially the Android GPU GPU ecosystem. It's a little better on desktop where you mainly have NVIDIA and AMD. However,

Intel has made a lot of headway, and they have some differences in how they handle graphics as well.

That's that's very interesting. And and mentioning Open GL ES,

I don't know if you saw this. It's kind of a tangent but kinda not really. It seems to me that OpenGL

is kind of under attack, right? And there's always been DirectX, and now Apple has come out with this metal framework for OSX. It feels like

the gaming industry in general is straining it the bit that open GL maybe doesn't move fast enough or doesn't have latest, greatest enough support for various

GPUs.

Do you think the mobile space is an area where open GL will continue to not only survive but thrive, or is it in general destined to go the way of the dodo?

You know, I think Open GL has a really strong history of adopting

the

best industry standards eventually. And modern Open

GL, any of the really good supporters, which, I mean, I'm stuck on ES 2 because of mobile.

Modern Open GL does have support for solving the same problems that modern DirectX or or or Apple's metal, for instance, does.

And I I do also think that mobile has been a big help for Open GL

because it it it is definitely dominant there. Even though Apple is sort of introducing metal, even you'd still to target all the devices

in Apple's lineup and especially to target all the devices

in the entire mobile space when you consider all the Android devices and such. You're gonna need Open GL for the next little while at least. I mean, we just barely hit 99%

open GL ES 2, what, I think, a year or 2 years ago, Google said. And

that's a API that's

12, 13 years old, I think, at this point.

So, I mean, it'll shift slowly,

and there's some very interesting things. For instance, you may have heard a little about AMD's mantle, which has already been subsumed by Kronos, which is the company or the

organization that kind of handles Open GL and the related libraries. They've already taken that mantle

and turned it into Vulcan, which is supposedly works anywhere open GL 3 or ES 3. I'm not really super up to date there.

But so if open GL goes away, I think it'll still be replaced

by more open technologies such as Vulcan or something like that. Although, I'm really skeptical we'll see open GL go away at all. It's got such

wide support at this point that there's a lot of even with major companies wanting to like Apple wanting to replace it,

there's a lot of momentum for them to shift.

And in addition, I would point out that Microsoft

made a huge what I would consider an error in going

direct x on their mobile device because that that created a huge barrier to entry for anybody who is currently serving mobile apps on their competitors' platforms

in the sense that for,

for instance, for any Kivi app to work on a Microsoft device, you either have to use this kind of,

I think it's still fairly incomplete. Journals

to be able to target Windows Phone with Kibby apps. And that's internals to be able to target Windows Phone with Kibbe apps.

And that's that's a huge thing to ask when we can work everywhere else with the single graphical API, basically.

Yeah. Particularly

when you're talking about such a small potential pool of users as what the Windows Phone Ecosystem currently supports.

Yeah. It raised a huge barrier to bringing your app to that device because it it wasn't just learning how to, you know, get your code compiled. It was

completely swapping out the graphical back end. And with the the amount of users they had, there was not enough incentive

for a lot of apps to switch at all, basically.

So switching gears a bit, I hear game developers talk a lot about assets and asset formats. What kind of assets can be used with Kivant?

Alright. Well, so assets really,

2 d assets are fairly simple compared to 3 d where you really start dealing with lots of different model formats. And particularly when you get into materials, which materials are sort of a collection of textures that represent anything from the

actual kind of colors there to how

bumpy or the normals for a surface or all kinds of stuff. You can represent a lot of things as textures. And the sum total of kind of the pairing those textures with the model data

and the the math that'll run-in the shader to actually produce your image is known as a material.

And so 3 d engines have a lot more to do there. Kibbit will really support any type of texture that your imaging providers for your platform for Kibby will support. I know that's kind of a a throwing the answer on to Kibby there, and it does vary somewhat. But so that should work pretty well.

And more excitingly, I have recently,

in the next released version of Kibbit, really updated the way we represent that model data. And so it does not support anything else yet, so to speak, but it is ready to do so. You can now basically

specify

the vertex format that your, model data is going to the GPU

in, and Kibbit will automatically wrap that vertex format with a model that allows you to interact with all the data from Python

and

set up your custom vertex data for whatever it is you're actually trying to draw to the screen.

And I'm pretty proud of that point because I think it'll help people who want to do very experimental stuff or just really anything that they can think of off the top of their head. They have a very quick pipeline to go from imagining the structure of their model's data to actually specifying it in code and then working with it live in the engine.

So if this is 1 of those questions where it's just too hard to describe it in words and it would make no sense, feel free to say so. But can you give me an example of, like,

a a standard vertex format and how someone might want to customize it or create their own? Like, what's the use case for that new feature?

Okay. Yeah. So, for instance, the standard vertex format

in Kivi itself, this is how almost any anything you draw in a Kivi app is represented.

It has 2 floats for the x and y position on screen

and then it has 2 floats for the uv position, which is the position

that in the texture file

that maps to the position of that vertex on the screen.

So for instance, if we were going to draw a

rectangle with a texture, like a whole image file, just any standard PNG.

That would be something like let's say it starts at the origin. So the first vertex would be 0

0 and the first u v coordinates would also be 0.

And then maybe it's 50 pixels by 50 pixels. So the next vertex would be,

50,

and the the u v coordinates would be

1.

And so you see

that that's basically saying the top of this rectangle

on on the left side

is at the position

50.

And in the texture that we're going to map to that rectangle,

that top corner

is 0%

of the texture

the height department, basically.

Gotcha. So so,

UV coordinates are always represented on a a normalized 0 to 1 scale, and that's to do with the way

the GPU

actually,

people who really know are gonna tell me this is definitely long. But it basically lurks between those 2 positions, really. And that's how it kind of scales so that you could you could map the texture to either a 50 by 50 object or a 150 by 150 object, and it would still know that that that top corner needs to be 100% of the height. So it's

I see. And so other engines

or other tools that people may have used might store their vertices

in a slightly different representational

format, and your custom vertex

support means that they don't have to retool their data or convert their data. They can

specify

the write a little bit of code

to make their vertex format work with Kivent.

Yes. And and for instance, you also asked what would be an example of a different format.

I've recently been working with procedurally generating,

kind of space scenes that are done without textures. So it's all just colored vertices.

And in that case, the vertex format is just 2 floats x and y.

And then 4 byte sized things that represent the color data, r, g, b, and a. And so,

in that case, you're not doing any texture lookup. You're not including those UV coordinates at all.

And instead, you're just having basically

a color and a position.

That makes perfect sense. Thank you. Can, provide a little video to give a idea of what that would look like that you can link to people, I guess.

That would be really cool. Thank you.

So I've heard that unit testing games is difficult and rarely done for reasons of time pressure as well as lack of determinism in the interactions.

Does Kivant provide any utilities to make this easier? And also as a corollary, how well unit tested is Kibbent

itself?

At the moment, the answer to the last question there is not really. I I

much like most game developers, I've been too busy making things show up on the screen and testing different performance things

to really get around to unit testing. But that's something that is really on my mind and something I I hope to change in the next year and definitely before,

KIDMITH 3 0, so to speak. I want to get to the point where it's really heavily unit tested, and you are certain that it all works, basically.

And I I do think that, the architecture, the enemy entity component architecture does a good job of kind of separating your game logic concerns

to make it easier to test. Not that not that you can test everything because some stuff, particularly graphical things,

present

very large challenges

and especially when a game, you know, is sort of a a kinda

the simulation results from a whole bunch of tiny state changes, so it can be kinda hard to track

any 1 thing.

But I'm hoping to find at least a somewhat clean solution that's easily reusable by people making their own logic in the next year here, time willing, basically.

Very cool. You know, it's funny. I don't listen to it anymore because I'm kind of out of the Xbox scene a little bit. But I used to listen to the major Nelson podcast,

which was Larry Herb, the Xbox 1 of the Xbox community evangelists,

would get a bunch of people from Microsoft together and do podcasts.

And it was great. And some of the people that he would get would be Microsoft

Studios,

Estes, you know, software developers in test, and a bunch of them even made their own podcast, I don't know if it's still going, called Platform Biased,

which was mostly about Xbox as well. And it was very interesting because they would, every once in a while, drop these little tidbits about how they do

automated testing of these uber complex

open world 3 d games. And it just really kind of fascinated me, you know, that, obviously, they didn't get into too much detail, a, because

that kind of detail on a podcast would would put most people to sleep, and, b, because

they probably can't reveal a lot of it because of, you know, legal concerns.

Because especially back then, Microsoft was not the the pinnacle of openness.

But it's definitely a fascinating problem space. And you might actually consider going back and listening to some of the platform biased episodes where they talk about that stuff.

Yeah. I've written that down and I definitely need to learn more. And by no means,

I haven't even gotten as far as, like, choosing a Python unit testing framework to use really. So I I've got a lot of research to do in that area

and it's definitely something I hope to address in the future and learn about in the first place.

So how does Kivint handle input and what kinds of input devices are supported?

Oh, this is definitely a question I'm gonna shove back off on Kibbe again. Kib Kibbe relies entirely on Kibbe to handle input. And, Kibbe itself is you know, it handles pretty much all touch inputs out there, including, like, overlays that plug in the TVs and things like that. It also handles traditional mouse and keyboard. There's kind of

stub support for gamepads. You're gonna be digging into the,

the kind of details of the SDL 2 provider if you really wanna use that or SDL 1.2 if you're still with pygame for a variety of regions including your, targeting Android. And so I also think there's actually even I've heard tell of some people kinda working with, you know, things like the connect camera and Kibbe apps as well. I've never done that personally, but

I think in general, Kibbe has very good input handling. And in particular, I think their decision to kinda unify

mouse and touch input as much as possible

was a very powerful decision going forward as we start to see, you know, devices that have keyboard, mice, and touch screens, for instance.

Yeah. Definitely. And when we were talking to some of the other kibbe core developers

a few weeks ago, 1 of the things that I believe it was Matthew who started talking about was working on support for the Leap Motion controller. So that would probably be really cool to see how that would play into being able to create some Kivend games to support that kind of interaction.

Yeah. Definitely. In in general, this is 1 of those areas where Kibbe is really wonderful because they I mean, Matthew and the rest of the gang really go out of their way to try to handle

any type of kind of cross platform low level operating system

concerns

you would have when building something and and hiding all that behind nice

Python interfaces that you don't even have to know about the operating system stuff about really.

Also, I mean, maybe it's just me, but I I kinda feel like

game controllers

on computers, in particular,

are kind of a black art. Right? There have been quite a lot of times. I as I mentioned, I'm old, and I like old games, so I end up playing a lot of these, you know, retro,

platform emulators and playing games on them. And

it is hard getting a game an actual gamepad to work reliably under OS X and have it actually be supported by the software that you're trying to use it with, it's not easy. And then if you are enough of a masochist as I am to try to actually

hook up a pair of, original

Atari joysticks

and try to make them go, that's even more difficult, which is kind of amusing given the simplicity of the device. It just basically 1 8 way switch and 1 button and and that's the size of it, but it's surprisingly difficult.

Yeah. It really it hasn't gotten much better either even nowadays.

I'm recalling specifically, I had a laptop that I had put Fallout New Vegas on. I wanted to play it on airplane, so I decided to try to hook up my Wii U controller and control Fallout with the Wii U controller.

And, of course, a lot of even modern games had actually been designed with controller support

support specifically

only for the Xbox controllers, basically, thanks to Microsoft's kind of dominance.

And so I ended up, like, I had to install custom Bluetooth drivers. I had this program that I was manually mapping keys from the Wii U controller to the Xbox 360

controller.

Actually, I I I couldn't even get that part to work. I ended up mapping keys to to keyboard buttons and mouse

axes, basically.

What I mean so even now, gamepads, specifically on desktop, haven't gotten much better.

I hope to, eventually, 1 day, if I ever get around to the time and I really need the support for a game I'm building, to build a very nice sort of

unified single,

you know, control

interface that will work with Kibbent that maps to basically any type of joypad I can think of, and hopefully, SDL 2 will help with that a little bit.

But I'm not really

I'm kind of a keyboard and mouse guy. I rarely use physics engine into

into Kivant, or is that something that's pluggable?

Mostly pluggable, really. It is kind of built in. I've had it since basically the beginning. I,

Tito

Matthew

Verbal from Kibbe,

had started a long time ago a a wrapper built in Python around the chipmunk 2 d library,

and I kinda completed some of the parts of that. And there is a module for

for Kibbent called Kibbent Psymonk that includes basic support for all the physics stuff that Chipmunk 2 d does

as well as a a growing library of sort of systems built on top of that, things such as enabling multi touch control of the physics objects or,

steering behavior is a is a big thing, I think, for physics stuff because that that that'll help you build a decent

AI that can respond to the physics environment and stuff. And so I've kinda started that as well. So it's a work in progress, but we do have basic support in that module for the chipmunk 2 d engine.

And, of course,

1 of the 1 of the major goals behind making Kivint as modular as it is is that may maybe you don't like Chipmunk 2 d for some reason. There's kind of a holy war in the 2 d physics area

between, box 2 d, which is a c plus plus engine and chipmunk 2 d, which is a c engine. Both of them are great. Both of them are fast. Both of them are really good at 2 d physics. And so, potentially somebody may come along and hate chipmunk and want to build a wrapper for, box 2 d instead.

And I would be very happy to have that as a module for Kivint as well.

I wrote a little bit about the particle panda library that's available for Kivy. Does that have any applicability to the sort of space that Kivend is working in, or is that something that's entirely on its own? So I actually I built particle panda as well.

And yeah. And particle panda is actually 1 of the major inspirations for Kivent,

because it particle

pen is still really slow. And at this point, it's actually dead, I believe.

Google

changed their TOS, and I couldn't I I couldn't get back in touch with the the guy who actually had the Google Play account because he's out of the country, and he might not even know the password and stuff anymore.

And so Google pulled it from the store, but I'm actually hoping to write a particle panda 2 in the next few months.

And just yesterday, I was working on a new version of the, particle engine

that kinda was underlying that. I I've rewritten that freaking particle engine,

5 or 6 times now, and it's actually a driving force behind how Kibit has changed

because, handling the amount of

math that must be done on the Python CPU side to update the particles as well as the amount of data they submit to the GPU since they're,

fully dynamic in the sense of scale, color,

and

and position and rotation. So that that's

pretty much everything you can do in 2 d.

They it's a fairly expensive,

memory wise, submitting it to the GPU and calculation wise as there's a good bit of trig going on there and things like that.

And so I I'm I'm writing a new version of that right now actually and that's gonna be another, another module that will be released in the next update for Kibend.

So given the constraints that you're working with and having to support multiple platforms, are there any of the Python numerical libraries they were able to leverage for doing any of that computation? Or is it something that you have to sort of handwrite all on your own from scratch?

Early on, I really wanted to use NumPy or something like that to do a lot of these calculations, but I found that it was a major headache

getting the entire scientific Python stack deployed for a game, basically. And that's also a lot of extra

extra,

code really that you probably will use a tiny amount of,

basically, because those dependencies are very heavy and very interlinked with each other. And so I really want that this is really 1 of the precise

kind of reasons Kivin exists is that

I had to forego most of those numerical libraries in favor of making sort of custom logic that's easy to work with and portable everywhere easily. Because when I started, NumPy was not on Android. I believe NumPy is on Android now, actually.

We have a recipe for that, although I don't think we have the Fortran parts

working. And of course, that's another thing is that NumPy doesn't just wrap c stuff. It wraps Fortran. It wraps all kinds of things, basically.

And so I I really try to avoid those libraries. And when you're doing, kind of intensive calculations

in, in Kivant, you're usually storing your data in kinda raw c structs

and using the, using the c level math functions and things like that, basically.

So given that you had to rework a lot of the capabilities that you were looking for in NumPy

for Kibbent, Did you create that logic in such a way that it could be extracted into its own library for people who might be trying to do similar types of computations with similar constraints in terms of the platform that they're trying to work on or the resources that they have available to them?

You know, I did not cut it out directly,

but I think you almost could, basically.

I mean, really, the core behind this is the kind of arena allocation memory management that Kibint does, which basically allows you to sort of even take objects of a similar type and then give them arbitrary groups. For instance, I could say for the particle engine, there's a there's a section of memory for particles reserved for, say, 10, 000 particles.

And that way I know when I'm processing my particles, they're all gonna be in this 1 section of memory tightly packed.

And other than that, you're just gonna be doing basic math functions outside from the c library and stuff like that.

But so you could cut it out

and potentially

use it. I'm not certain how useful outside of the very specific concept of the entity component system that memory management solution would actually be.

Fair enough.

So how does Kibben handle collision tracking?

I ask because it's always been an area I've been fascinated by ever since the 19 eighties. I had an Atari

microcomputer,

and it had Atari logo on it.

And that logo language implementation

had

DynaTurtles,

so you could you could make the turtle look like anything you wanted and moreover,

that language actually

provided the ability to say, when I collide with another turtle, do

run this blob of code. So I've always thought collision tracking was kind of a neat problem space for game writers.

Collision is definitely, a, 1 of the most mathematically

intensive areas and also 1 of the hardest to get right, I think, in a very general sense. And what I tell people is don't do it. I recommend people use the physics engine, because chipmunk 2 d, in addition to being a physics engine, is actually a wonderful collision library that can do segment to segment to segments,

you know, circle to circle, box to box,

arbitrary polygon to arbitrary polygon, and all the, permutations

in between

and,

obviously

think. And obviously some of that is physics, but some of that is also just collision math. And early on, I did write a little bit of collision math.

I implemented circle circle,

circle segment, and circle box collisions.

And that not only took a lot of time, it's very freaking slow in Python. It's there's lots of corner cases that you need to solve,

and it's really something unless you are super interested in creating a collisions and physics detection library,

you should just use what somebody else has already built there, I think.

It seems like you've been very smart with the KV design in the sense that you're very, very focused on solving the hard problems that would be tremendous obstacles for people wanting to write a performant 2 d game in Python

and you're very careful where someone else does something

hard really well that you can just layer, you know,

leverage and pop in, you do that. And I think that's really, really, really smart and good engineering for that matter.

Yeah. I definitely think that's

almost any game is really going to end up being a a coming together of many different middleware solutions or open libraries or whatever you end up needing, basically. And so 1 of the things that Kivant has also done is try to keep this in mind and and have a very clear, open, and easy pathway

for taking libraries written in a in a variety of languages

and wrapping them easily in Python

so that they can be scriptable by people building games,

while still gaining all the advantages of using whatever library that is. And that's something where the combination of the Kivy ecosystem and and Cython itself is amazing

because Cython will give you access to easily wrapping

c and c plus plus code, and Kivy itself has the Pygenius library for wrapping Java code and the, Pyogdis library for wrapping Objective C code. And between CC+

Objective C and Java,

I think you have access to almost

the entire software ecosystem for games, basically, with exception c sharp, I guess.

It just struck me as you were saying that how writing a game these days

essentially

always ends up being

bringing together

various pieces of kind of packaged middleware is the term you used, which is perfectly reasonable in this context.

Context. But it just struck me, you know, again,

the difference between

that, the modern reality of writing games, and once again, the old school reality of writing games, right, where it was

you sat there with your macro assembler and you, you know, your memory map of your computer and that was all you had and that's that was all you could use.

And so you got incredibly creative with that.

And so it's just it's very, very different that in the space of over the space of years,

the nature of making a game has changed so radically.

Yeah. It's definitely become democratized in a lot of ways. And, you know, it's much easier than you don't have to be John Carmack to come up with even a 3 d game anymore,

basically. It's something where that's

1 of the things I really sat down when building Kivint. I knew for a fact that you would often be needing to integrate some type of middleware. And in fact, Chipmunk has basically been integrated since day 1.

And that's caused me to make design decisions

that allow for more flexibility

and

significant

amount of variety in how you approach creating a game object and what is the underlying

actual representation of that game

object versus how you want it to be interacted with from Python.

Forgive my ignorance for just a moment here, but so as a for instance, you integrate Chipmunk 2 d, which is a c based library

for physics and collision detection and all that good stuff like that there. From a developer's perspective, if I were using Kivant to make a game, does the Chipmunk 2 d API

or your wrapper of it have the same have a compatible object representation

for what

you would use in Kivant.

I guess what I'm asking is,

if you're designing a game,

let's say you're designing Pong. Right? And you you have different objects interacting on the screen, like the paddles and the ball,

and Chipmunk is handling the physics between them,

is the same object representation

used

sort of all the way down and across the board all through the code? Or do you have to do translation

between

Chipmunk 2 d's concept of what an object is and Kivent's?

So to some extent, the structure of Kivent

achieves some of that

abstraction, basically, and that's kind of

1 of the, things that entity component architecture is for. For instance, in Kivint,

every single object gets or or anything that's gonna be on the screen gets a position component.

And a system like the the Symantec physics component

or the Symantec physics system, every update frame

will actually take the the position from that physics object that it calculates after performing its update step and everything

and write that out into the position component. So any other game system you make, that all it cares about

is that x y coordinate of where your object is at, that's all it needs to look up. It just needs to grab the position component. It doesn't need to know whether it's a physics object or whether you're determining the position manually

or anything else basically. And so 1 of the 1 of the reasons gaming has shifted to that kind of entity component architecture

and 1 of the reasons I think Unity has been so successful in creating an entire ecosystem of middleware developers

is that the architecture itself enforces this sort of highly diced up

functionality

that means that you really don't need to know

the big picture of what's going on. You just care about the data that's relevant, the calculations you're going to do. And if you're wrapping something that controls that data, you just write it out to the component just like you would if you were manually controlling it, and the rest of your game can

be based off of that logic, basically.

It's almost like I I realize there's still, you know, low level hacking going on. It almost seems like from the game dev standpoint, what you end up with is this

super incredibly

high level

architecture that you're interacting with where you're almost making it sound like you're writing code, but you're not writing low level code at all. You're writing in terms of

very abstract

descriptions of things

like, you know, change the x coordinate of my ball as it moves across the screen kind of thing and and the architecture is handling a lot of the low level work to make that actually happen.

And you really you have no concept of a game object like a ball or a spaceship

or a gun. You you just have this collection of data,

and each thing with the same type of piece processes it however

the your game logic dictates. And it's kind of, I think, a very

weird way of thinking about things for people coming from a heavily object oriented kind of Python approach,

but it is very helpful in terms of making it easier to debug your logic

because

everything behaves the same regardless of what it actually is. Everything is just a different kind of grab bag of the various pieces and systems you've built. And that also gives you more creative freedom because, say, you build

my traditional example is, say, you've got, like, a building, like, a a house in Warcraft 2 or something, and then you've got an archer character who, you know, can move around

and can shoot

a bow or whatever. And then you want

a tower, which is basically kind of a, you know, an archer, but it can't move and it's kinda like a building too.

That becomes immediately

easy to do

in an entity entity component architecture because you basically your archer is, you know, shooting component, movement component,

and, graphic component.

And your tower is

just a graphic component or, I mean, your house is, and then your tower is a shooting component and a and a graphic component

and no movement component.

I totally see what you're saying in a sense that people who are used to standard

object oriented construction in languages like Python would find it really difficult to deal with. But it almost makes me think that what you're describing

harkens back to the original conception of object oriented programming with

entities that respond to messages, right? Like, so as opposed to having these kind of big concretely named objects,

it was more about they had a they had a word for it, but basically characteristics

like I can shoot arrows or I can move or descriptors as opposed to necessarily

concrete

names for

things. Yes. That's actually kind of often mentioned is that it's really not that huge of an offshoot from object oriented programming. It's just a more strict kind of original conception, and I believe that original conception of object oriented program programming

even allowed for the idea that your objects may be storing

memory very differently

from the way the actual object sort of exposes its data in order to, you know, process things more efficiently, whatever your program needs to do and so on.

So can you tell us about some of the projects that you've seen built in Kibento which you're most excited by? Most of what I'm going to share here is from 1 of my first and best early adopters. There's a user on GitHub and IFC named Chozabu

who has done some pretty cool stuff including contributing Windows support for both the physics engine as well as Kibbent in general. But he has done some really interesting

kind of things. I'm gonna link a few things here, but also describe them.

The first 1 is what he called Kibbent Ed, which was sort of a very,

rough around the edges and experimental graphical editor like Unity or Unreal have for Kivint itself.

And that's something I definitely built Kivint to do

is to, you know, be able to live edit and interact with all the objects dynamically while the game is running, so to speak.

But it's not something I've had the time to actually work on myself, and so

his, his kind of, work on Kivinted, I think, is something I really hope we have a very solid version of in the future because I think having a graphical editor can not only make certain types of games much easier to build,

but it can also,

lower the barrier to entry for people who are getting interested in building games in the first place.

In addition, he has a pretty cool game that was built with Kivant 1 0, so it's not nearly as performant as games that you'll build with the more modern version.

But it it kinda does a good job of showing off the physics calculations,

And even then, it's

it it runs fairly well using a much less performant version of Kibin's architecture.

So, those are the 2 biggest projects people have really shared. I'm I'm aware of other people who are working on things, but they haven't finished them yet, nor have they really showed me what it is they're trying to do.

Well, I'm sure our listeners will really enjoy taking a look at those 2 examples of work that's been done on and with Kivent.

I do definitely think that having a an editor

like KiventEd

goes a long way towards attracting the same kind of crowd of people that are flocking towards Unity for exactly the reasons you specified. You know, they can take a bunch of assets

and

have only a moderate understanding of writing code

and put a game together. And I think a lot of people,

a, really enjoy that, and b, there have been actually some pretty cool, you know, even if they are somewhat simplistic games that have come out of it. So that's that's very cool stuff.

Yeah. Definitely. I I'm a big fan of people doing art whatsoever, especially kinda amateur art, and I hope that we will

continue to lower the barriers to entry.

1 of the things is I really don't want to have

so much priority as Unity on the graphical editor kind of thing because I I'm kind of a a raw code guy.

I I don't even really use an IDE. I just kinda

type in text files, and

I think it's important to leave that as a as a first class citizen in terms of development as well

because especially if you're doing kind of more procedurally generated games or or games where you don't really actually

actively place anything

manually.

The graphical editor can be kind of a gimmicky

thing that you don't need so much of, But I would like to support, obviously, both styles of game development in the far flung future, so to speak.

So totally random off the cuff question because you mentioned

being mostly focused on entering, you know, text, that style of programming.

What editor do you do you use? Emax, Vim, Sublime?

I use Sublime Text. I have since, a good buddy of mine in high school recommended it. I'm really happy with it, honestly.

It's a great editor. That's great.

What are some ways in which our listeners could can help contribute to the project?

So number 1, I

really would like to see more people go out and build games with Kivint. Kivint grows as people actually need things. A lot of the changes that have been rolled up into what I've been calling the 2 0 version are largely related to, Chozabu's projects and him continually asking me how to do something that I was like, oh, man. I never really even planned on anyone doing that. Let me build support for it and things like that.

Give it a go, you know, kinda download it, check it out, try to make a game, and, let me know

how it went. Let me know what you found was difficult. Let me know

what you would like to see in the future, and I'll try to get around to it. And in addition,

just a little shout out, if you have Apple hardware, since I don't have any at all, iOS or OSX, Give it a shot. Let me know what's going on. Post some errors, and I can try to figure out what compilation flags or whatever we need. Because in theory, it should work everywhere because it it's based on Kibbe's. It's only dependency, and Kibbe works everywhere.

But in practice, I have not heard from a single kinda Apple user that it does work, and that would be a huge weight off my mind to know that we really are as cross platform as I hope we are to be. So if you're if you're an Apple Pythonista,

really give it a go and let me know your experience.

So that would be great. Really, there's a bunch of examples inside the,

inside the root Kibbit project. There's an examples folder, and all of those should run.

And so if you just,

download and try to build Kivint, and if it builds, that's the first thing I'd love to hear. And if doesn't build, I'd like to see the error message because I'm sure it's nothing more than setting a few flags or something. It would be really good to know that because I really want to bring

completely cross platform everywhere support

for building

decent 2 d games to Python.

At this point in time, are there any other questions that you feel we should have asked or any questions you'd like to ask us?

I think y'all covered some some pretty good territory here,

stuff what some of the stuff I was thinking about when I built it. I don't think there's anything else for me at this time.

Well, with that, we'll move into the picks.

And for my first pick, I am going to choose

EIN,

which is the emacsipython

notebook project.

And it is an interface to ipython notebooks that you can use within emacs. And I started using it recently

since I started playing around with the IPython Notebooks after we had

Fernando Perez and Brian Granger on the show, and I've been really enjoying it.

The EMAX interface is really slick and well put together

and just since I use EIMAX as my primary editor trying to do any editing in the browser was just kind of painful because of not having my key combinations available to me, and EIN really solved that pain. And basically, you just start up an IPython notebook,

then you go into EMAX, tell it to connect to the notebook list. It just asks what port it's running on and away you go.

For my next pick, I'm gonna choose the

7 dot x release of PIP

because

it automatically

will cache

packages that you download and create wheels from them. So if you're installing

the same packages across multiple different virtual ends, it just really makes it run a lot faster and easier to manage. And it also makes deploying that code a lot easier to do because the wheels are already built. So you can just package up your virtual end, ship it to your production server, and be off to the races.

For my 3rd pick, I'm going to choose the book, restful web APIs.

I've been reading that recently, and it's just a really great

approach

and discussion on

a more correct way of building APIs that are accessible via the web rather than the

typical way that a lot of people think of REST, which is just having, you know, a resource that supports git put post delete

and then having a human readable API documentation that you have

to parse to try and figure out how to write your clients. And it's really trying to

introduce people to the hypermedia approach to APIs and

showing that it is possible for a large portion of the semantics of the API to be machine discoverable without having to have as much of a human intervention. So definitely worth a read.

For my first pick, I'm gonna pick a

series. I believe it was originally TV, but I we've been watching it on Netflix. Might be a Netflix only series. I'm not sure.

It's called The Killing.

And it is really well written, really well acted, and really, really intense.

It is heavy. I will say that. This is not like light viewing,

but it's a really good story. We're enjoying the heck out of it, and I can highly

recommend it. The next thing I wanna pick is this awesome blog post that I stumbled over the other day called

data science on the iPad with RethinkDB.

And the reason I think that that is such a great post is

I have gushed before on this show about Pythonista,

which is a really awesome Python programming environment for the iPad,

which is basically a combination sort of,

IDE slash,

iPad native UI

toolkit

slash whatever else for the iPad, which is really exciting because that kind of, you know, self hosted development environment

is not necessarily

a common thing or at least as well developed as Python east is on the iPad.

But the thing that has made it

interesting, but perhaps not earth shatteringly so, in my mind anyway,

is

Apple's restriction

on

not being able to import,

not not having your your, you know, applications not having the ability to dynamically import code.

But some brilliant individual, and I I should really be credit him or her,

but I don't have the the reference on hand,

has written a script called pipsta,

which you can install

to Pythonista

by copying and pasting it from GitHub. It's 1 script. You can just do the little raw mode thing there and paste it in. It's super

easy. And with that script, it basically gives you

pip like capabilities for your Pythonista

Python environment.

So you can pip install various modules.

And this guy who wrote this blog post

uses that capability

to do earthquake analysis

using RethinkDB.

It's it's really, really cool. It's a great post and I'm I'm really excited

over the fact that now I can pull in random Python modules,

on my iPad and do more interesting work. So that's very exciting stuff.

My last pick

is

unshockingly,

because it's what I do, a beer. I'm going to pick Left Hand Brewing's Nitro Milk Stout. As I mentioned, I've I've kind of been exploring

other varieties of beer lately because I really kinda

started out liking, you know, pretty much only porters and stouts. But this 1 is just an old favorite that is is, you know, really

stands the test of time. It's super, super, super smooth, great multi character.

It's just a great, great, great stout. And as a matter of fact, I think it is the best stout that I've ever I've ever had. So there's that. And I'll stop it at that this week. Jacob, what picks do you have for us? Alright. First, I'd like to give a shout out to the, the Pelican framework for static generational blogs. I'm really I just kinda started doing a blog recently, and I'm a huge fan of,

I mean, I've worked with Joomla. I've worked with WordPress. I've worked with lots of content management systems for various organizations and stuff.

And I've eventually ended up being,

1 of those type of people that just want static websites. I I want nothing else. I just want to

write a document that has whatever information I need in it, you know, run a compile stage, and then be able

to copy and paste

that stuff into my FTP and have the website going. And Pelican does exactly that. It has wonderful theming options.

I've been really impressed. I like Pelican a lot.

Number 2,

I

will actually give a shout out for something that's releasing later this month. Terraria

1.3,

I believe it is, which is, we talked about kind of retro 2 d games. Terraria is sort of a 2 d side scrolling Minecraft type deal, and it is a ton of fun. And

they've really done,

last year or the year before, I can't even remember when their last update came out, it basically doubled the the size of the game and they don't charge DLC or expansion prices. They always just give away the new content for free and they're a great company with a really great product. Finally, the last 1

in kind of the vein of Chris's beer recommendation,

last year, I made a batch of

wine, red wine from Italy known as Amarone.

And if you've never had an Amarone

or you've never made wine, it's a great place to start. Get yourself a startup kit. Get yourself,

a thing of Amarone. It's kinda it's not very sweet at all. It's a little spicy. It's a really good Italian red.

Well, Jacob,

for anybody who wants to keep in touch with you or follow what you've been up to, what's the best way for them to do that?

Let's see. I've got a blog that just kind of started, and hopefully, I will be posting regularly at chaosbuffalogames

dotcom/blog.

There's not even actually a rude domain site yet, so I need to get there.

And then you can always email me or find me in the Kibbe users chat.

My email is kovac1066@gmail.com.

And the Kibbe,

chat channel is on free node, and it's just hash

hashtag Kibby.

Well, Jacob, we wanna thank you very much for taking the time to speak with us tonight. I'm I'm sure our listeners wanna thank you as well. It's been a lot of fun and very interesting to hear about how you can use Python to make some decently performant games. So thank you very much.

Thank you all very much for interviewing me. It was a good time.

The Python Podcast.init

Synopsis

Brief Introduction

Interview with Jacob Kovac

Picks

Keep in Touch

The Python Podcast.__init__

Synopsis

Brief Introduction

Interview with Jacob Kovac

Picks

Keep in Touch

The Python Podcast.init