Coding before a live audience

In this post, it was estimated that programming an NES game from scratch would be too tedious for a live audience. Might something more limited in scope, such as adding a new block type to an existing SMB1-class engine, be a better live coding demonstration?

Maybe, but that might be less compelling. Adding a brick to your existing engine would be so engine-specific.

If I were doing it, I'd start by already having a template with vectors, NMI, game loop set up, routines for reading game pad, etc. But not displaying anything.

Then write the code for displaying a single sprite. Then add code to move it around the screen with the gamepad. If you prepared, you could do that pretty quickly, and it'd be moderately interesting to the audience, by giving them the ability to imagine "I could make a game out of that!"

Hacking a game isn't such a good demonstration because you'd have to explain a lot about the game's engine and architecture before what you do makes any sense to the audience, and if on top of that you have to explain how 6502 code and the NES work, that's a lot to convey in a short presentation.

It's unrealistic to expect anyone without prior knowledge in the field to learn anything significant about NES programming in about an hour or so no matter how you go about it. I agree with gauauu though, it makes more sense to build something simpler (not a complete game) but still interactive, that people can easily observe the way it comes together. I don't know if I'd go as far as having the controller reading pre-programmed, as that could be a good lesson on subroutines, memory-mapped registers and the NES architecture, because it touches all those subjects without being overly complicated. I would save input for a later time though, after sprites are already being displayed and moved by a simple INC or something.

I also feel that the game loop, as one of the most important aspects of a game engine, should be built from scratch, otherwise it feels like magic that the code you write runs every frame, because most beginner programmers are used to more linear stuff (input->processing->output), so building the game loop is a good opportunity to show how you go from linear to interactive.

Code Pong. It has all the elements, covers the basics and can easily be done from scratch in an hr.

And it's boring as hell... Code at least snake/nibbles, which feels more dynamic (player changes size, there are dynamically spawned objects), and is easier to test.

There's a hundred variants you can do on pong alone. Move paddle x direction. Varying speed of ball by impact. Introduce gravity. Put a fence in the middle of the field. That's essentially "tennis for two".

Or Introduce paddle angle. Curve balls based on paddles' delta-velocity between n frames. Out of bounds zones. Z depth, shown by shadow and ball size. Now it's more like real-life ping pong.

Three player pong with three goal zones. Four player pong with four goal zones. Introduce solid corners to lower goal frequency (probably needed for more than 2 player pong).

Sure you can make Pong more interesting, but you probably wouldn't implement all that stuff in front of a live audience... My point was that the base game is boring, and that there may be better base games out there that aren't any more complex to code. OTOH, I can't objectively say that something is boring, some people may actually prefer Pong over Snake, so... Do what you think is best.

I do think that the concept of dynamic objects is a cool thing to teach though, and without enhancements, Pong has none of that. The food in Snake might be the most dynamic type of object either (you could argue it's always the same object that's moved elsewhere when eaten), but at least the snake itself may be an interesting example of how to modify game objects on the fly.

Yeah, that's true. Dynamic objects is a harder to grasp-concept and might benefit from being presented 'live'.

One thing you could do is put together a team to divide the burden. One does sound, one does graphics, one does game logic. Maybe a fourth will put together a Picture-in-picture live stream and make a live commentary.

A precursor could be the ludum dare live stream that morphcat and betoux did.
Timelapse version: https://www.youtube.com/watch?v=DcHKqaKljGQ

The scope here was more ambitious (72 hours), but you could scale it down.

Really? Because I had the dynamic objects in my first NES game, coded in a single afternoon, using generic, reusable subroutines.
Every object in the game (including the player, but excluding bullets), were updated in the same way, as quickly, and efficiently as possible.

I had started on a tutorial last year, to create a shooter, using a similar object-handling code, to show how easy it is. But I haven't had the time to sit down, and finish the write-up.

The enemy patterns would be presented to the beginner, using a human-friendly byte code:



More advanced users would be encouraged to code the enemies, directly in hexadecimal!


Not a tutorial, but a game I had never released, was coded in only 5 hours, during a marathon coding session:
viewtopic.php?f=22&t=14773#p178844

Piko was going to release this game on cartridge a while back, but... things happened. Oh well.

I don't know how much you knew about programming in general before you coded your first NES game, but most newbies (no prior knowledge of low level game programming) coding NES games tend to evolve from tutorials that teach how to move a sprite around in front of a static background and not much else. Such tutorials often use hardcoded OAM positions for a constant number of objects and don't ever touch on the subject of dynamic objects and OAM allocation. You'd be surprised at the number of people who move objects by INC'ing/DEC'ing sprite attributes in $200-$2ff.

My personal background is that i made small adventure games (and just the one simple topdown racer) in qbasic to show friends in school They were entirely comprised of a bunch of "scenes", made from draw instructions, the occasional hardcoded bitmap, and text strings. I'd then spaghetti-string them together. Variables representing carryable objects and a few events would keep the experience from being nonlinear, but that's it.

Then i took a long pause.

Not having taken a single programmers' class, everything i've learned since then is very circumstantial.

Don't people show it for Ludum Dare? Like, they created Banana Nana on a stream, didn't they?

There's a difference between live streaming your coding session for hours, and doing a live coding presentation.

One is more like letting people watch over your shoulder as you work normally. The other is about teaching/showing.

Both can be useful, but both are intrinsically different.

Ugh. Coding before a live audience can be terrible. I once had to do it for a "surprise" interview, AFTER I had already landed a job (long story), and I totally froze up. The person thought I couldn't code at all. One of the worst experiences of my life. I went to a park, laid on the grass and listened to Wolfheart (Winterborn) for the rest of the afternoon to numb the pain.

Definitely. That's why for a planned demo, you practice a few times to be sure of what you're doing. Otherwise it's s disaster.

You should definitely plan at least the basic outline of the program, and the order you want to implement things, otherwise you might end up losing precious time and making the whole thing harder for the audience to follow.

As someone interested in coding I have zero interest in watching others do it.

Pick another hobby to demo.

Yeah I think even Pong is a bit too much to do in a live session, and as Tokumaru said, it's unrealistic to expect that newbies would grasp enough of NES programming in an hour to be able to learn anything significant from it. And if done more like a introductory demonstration I think one hour is a long time.

In the same thread I already stated my opinion on video tutorials:

And doing it live is even worse than recording a video. The audience naturally can't rewind, so the demonstration might need to be something much lighter than a full game.

I agree, but some people like that kind of thing (shrug). I live streamed my first few coding sessions of last year's nesdev competition entry, and I had a good handful of people that decided to watch.

(It ended up being too hard to concentrate while live streaming and talking about the code, so I gave that up pretty quickly)

+1

The only reason I'd have any interest is if it's presenting a new language or paradigm or something, and even that is stretching it a bit when another medium such as a book or static web page makes a better medium for that (we the audience can follow at our own rythm).