Too Many Games near Philly was my 1st con, 1st real NG meetup, and 3rd time meeting at least one longtime NG friend. I was a bit worried that I drove 3 hours to hang out with a bunch of stinky 12 year olds, but no one stank (from NG) and the 12 yos had summer camp and couldn't come.

Some standout moments for me:

• I saw a buttcrack in the first 30 seconds (non-NG) and thought it would be frequent, but that was the only one
• Everyone sketching in each other's sketchbooks was so precious, especially at the beginning
• Talking with @IvanAlmighty about hydration and carbonating water
• @emizip's Ena cosplay and waving hi to me while I was zoned out wandering the expo
• @moawling's handheld microcontroller portfolio and adorable business cards
• @NinjaMuffin99 being like 10" taller than I had in mind (@austineast you were discussed!)
• Also when he said he learned from me when he was 16 and is 23 now made my bone density decrease
• @Squidly gathering the Flixel-ers to gang up on me for not using it anymore
• @Hibachi and @PKettles with the cleanest art you ever seen
• @RavioliBox's sketchbook with the black pages
• I've been amazed by @TomFulp's AS2 workflow for over a decade, so same thing but in person this time
• A random NG user recognizing my larger collabs is normal. NG Snowboarding, sure @NeatoNG. But Date A Monkey???? @MrShoeShine7
• @MindChamber has a MindChamber jacket
• An interesting proposal from @NattoSumi...
• @vividlance gave me a NEMGROUNDS bracelet jkjkjk
• @Bill go to New Orleans except not during the summer
• @Imprez and also Ivan talking about finding programmers/learning programming for big art collabs
• Talking mobile with @Luis and wanting a shorter turnaround project next
• @Chourios pronouncing "Chourios" ("it's like Cheerios with a U")
• @Tamag0 saying "but with a 0 at the end!"
• @D-slick N O L A
• @MysteriousMantis and I gently trying to make everyone leave the expo to get food
• @Kastozx's "K" looked like "CL" so it took me like 5 tries to find their account
• @BrandyBuizel having exactly the markers needed to draw Lucky
• @SrPelo buying "Hannah Montana: Rock Out the Show" for PSP

So,

1. We need to do nametags sooner in the event, and I need to take more pics of them
2. I need to make a new Ren'py so y'all can finally have medals in your VNs
3. We should make some kind of art collab code template or something, idk
4. @Sabtastic you might be the last "old" person I haven't met yet 👵
5. I have to make a sequel to Date A Monkey

The 3 Star Jam was announced an hour before I finished a little Haxe/Heaps framework I've been making on the side, so it was perfect timing to test it out. I made a DPS clicker over that weekend, and I gotta say, it was so fun to make. I was smiling the whole time.

My past couple posts have been me leaning more and more towards a custom library that does what I want it to do, and based on this jam, I'd say the idea is solid with some rough edges. I'm still in the process of isolating the library code from game code and then making it a bit smoother to use, but at that point I'll actually upload and maintain it. I'd be surprised if anyone wanted to use it... learn from it, sure... but maybe the idea appeals to someone else too.

Now, the downside to improving your code is that your past code now sucks. My past games don't matter in that respect, but my currently-working-on-and-kinda-going-slowly game does. I thought about it for a bit, and I think it's best if I rewrite what exists now in the new framework. I'll have to do it eventually anyway, but going back and developing "bad" code doesn't sound fun. I ended up making a lot of decisions early on based on an incomplete understanding of what I was making, and it's been a pain maintaining all of that, so things should flow better soon.

I have some more to add to the framework, especially NG things like clean API integration and the classic/styleable popup for medals. Physics integration. Sequencing. Dialogue... We'll get there.

I don't feel like clicking for 5 minutes to get a screenshot, so here is an earlier view of the jam game. "Earlier" here probably means like 4 hours before submitting.

Man oh man. I said before that finishing games is what helps me figure out what I like and don't like in my code workflow. It's still true.

Interstice Academy is my latest game, a dating sim made with a bunch of writers and artists and composers on team Milk Chocolate for a month-long jam. This is my second finished game using Heaps, first using ECS, and last using the current iteration of my dialogue engine. It was a good experience overall, working with high quality creators but also rushing a good bit toward the end. I had something of a dialogue engine already built in a prior workflow, and bringing it over wasn't that hard. I think I worked on it after playing Half, which I really appreciated and kinda inspired me a bit. But I need to work on it some more. Code is here, minus the assets.

As far as my workflow, let's start with the bad:

There are 286 manually created "dialogue" files. This worked in Quarantine which didn't have as much dialogue in comparison, but man this sucked. I didn't have time to make sweeping changes to my parser, but even some tiny changes probably saved me hours of effort in copying from a Google Doc to the code environment. The doc was either one huge file or like 7 smaller divided but sizeable files, and I feel like my code can get closer to either of those. An innocent option in game with 3 choices that all end up at the same line is 5 individual files: the original, the final, and 3 for the options. This could definitely be inlined, if nothing else, to all be in the same file. Times 60 for the entire game. The biggest time sink was coming up with new names for each file.

The UI library didn't correctly scale with the game. This was annoying. When I implemented fullscreen towards the end, I realized that the mouse interactions didn't scale with the game. Everything on my side scaled, but the UI interactions either didn't or just broke. Fixing this would have taken several weeks on its own, just because of how entrenched interactions are in a User Interface library. This one sucked because I assumed resolution was easy and handled already. Even zooming into your browser or people on tablets with a default Windows scaling breaks it. Unfortunately, I think the solution is rolling my own in-engine UI components. I had so many other gripes that just fixing resolution wouldn't make things that much better for future projects.

The dialogue file syntax was too strict. This wasn't the worst in the world. After submitting, I talked with the coder for Love Me Newgrounds, who used Renpy. Just loading that game, not even getting to the title screen, I could tell it was a whole ass thing, and they agreed. But, reviewing the narrative syntax, it was much easier to write because it was less strict. I think something closer to Renpy or Twine, with syntax highlighting in the code editor, but also extreme flexibility in manipulating the UI or adding random shaders like IA asked of me, is the ideal. Something that checks the syntax in either case would be even better, making sure I didn't forget a quotation mark deep into the story. Renpy by itself seemed annoying and had some bizarre restrictions.

The good:

Workflow is clean. I'm getting more used to my own ECS workflow, and man it is so easy to do things. Tweens, fades, and delays just happen with barely any thought of side effects (though the UI library made visual glitches happen without being careful). Editing code is easy because everything is organized by function. In a separate project, I'm finding that something like AI is overcomplicated by the methodology, but here it worked well. I think a hybrid approach, whatever that ends up looking like, will be good in general.

It mostly works on mobile. My input handling code just dealt with mobile without me having to try, so touch input was supported right off the bat. Scaling mostly worked, though hampered a bit by the UI stuff. I haven't tested enough to be confident, but it seemed like high DPI screens didn't scale independent of mouse coordinates, ie the mouse position scaled with the display. I need to experiment more, but it's good to know ahead of time that it will work one day.

So, A) progress, B) I'm gonna end up making a whole ass game engine one day, C) we got daily #1 which is my first!, D) I have a bunch of new names I'd want to work with or commission in the future.

Pretty good pretty good.

Last time, I talked about how I was switching game engines to Heaps, from Flixel and OpenFL. I also decided to start using the ECS coding style/paradigm. I'm enjoying it! Who knew you could have fun while coding?

Heaps is really two different game engines: a poorly documented engine that has everything you need, or a poorly documented engine with almost nothing you need but a ton of examples. I think that second option is better, because Flixel is a far better "everything you need" engine.

For instance, there is a default animation class, but I don't find it all that nice to use in a game. Interfacing with it is awkward, and it updates automatically instead of when I want it to. However, it does show you how to draw changing things onto the screen. I can write my own animation code just fine, but I would have no clue how to do lower-level drawing without some good documentation and examples. The docs aren't that good, so we have to take whatever examples we can get. There is a lot of (snarky) help in the Haxe Discord, for better or worse, so I try to take notes when discussions go down.

Some people have mentioned wanting to learn about or try Heaps, so I recommend it only if you're not afraid of going into the source code to figure out how something works, and then rewriting it yourself because it was implemented weirdly. Or having breaking changes pushed to dev because Shiro Games codes differently than you.

Heaps gives me just enough so that I'm not talking directly to your graphics card, but not so much that it would be awful and silly to rewrite parts to be how I want them to be.

Entity component systems (ECS) are a way of organizing your code. It's a bit fussy, but it scales well. Like, a project I'm working on could easily have local multiplayer added, and I'm not even trying to make it happen. Typically, it's a pain in the ass since you tend to code assuming there's only every going to be one player, or you start off knowing there are going to be multiple. Everything is broken up so much that adding a new player is barely any additional code, mostly just saying which controller or keys to use for input.

ECS libraries split up code into data (components), data holders (entities), and operations on that data (systems). It makes sense on paper, but I tried 5 or 6 different libraries (and started to write my own) but never really liked it. I ended up loving "Aidan's ECS" as we call it, which uses a significant amount of black magic to streamline the coding process. It's starting to feel like I'm making a bit of a library on top of it, which is a nice feeling knowing I'll be able to easily reuse code.

I said that it's a bit fussy, and I'm going to see just how fussy in a Haxe game jam coming up. ECS make it hard to write the kind of spaghetti code that brings a game jam game together in a short time, so we'll see what happens. I haven't finished a game using an ECS library yet, so I'm going to need to keep my scope small.

But yeah, it's so easy to modify code and add new features because of how ECS is organized and split up. And I'm not fighting the game engine all the time because there's almost nothing there to fight against. I'm really enjoying it so far.

It's been about 10 years of making games as a hobby, and 99% of that has been Flash or Flash-adjacent. But no more.

I've posted a few times about using HaxeFlixel, and it's probably the best all-around code library I've seen. But man, I fought with it every step of the way to get what I wanted done. I think my earlier games, which were all top-down pixel art FF6 looking, would have been a breeze with Flixel. But when you stray from pixels or try to do something too complex, it can be a bare-knuckle brawl. I was moving away from its intended use, which isn't a bad thing at all.

After Quarantine (the game, because... yea), I decided to stop using Flixel and go back to OpenFL. Basically Flash AS3 for the modern coder. (Flixel is built on top of OpenFL, and you interact with it a fair bit, so I consider it to also be Flash-adjacent.) We did Newgrounds Snowboarding for Pico Day, which was super cool but also highlighted that I don't really like OpenFL either. The AS3 API, my dear and problematic friend of 10 years, was being more annoying than helpful at almost every level. Adobe even felt that way, back when they pretended to care about Flash (sigh).

Since I only code as a hobby, I don't need to put up with not enjoying it. Flixel is amazing for beginners and great within its chosen limitations. OpenFL is just AS3 minus Flash. Leaving OpenFL now ultimately means I'm leaving AS3, which.... yeah ok bye ✌🏽.

I'm trying out Heaps now, written by the same guy who made the Haxe language that all you FnF modders hate so much apparently. It's lower-level and has less goodies, but it's so much easier to put code together. The internals are implemented better than OpenFL's are, which I sorta don't care about but also do if that makes sense. It seems like actually finishing games is what allows me to make these judgements, so I'll post something to NG made with Heaps and see how I feel then.

So. Keep making games (or mods) with Flixel, if you want to. If not, explore the other Haxe libs and see which one you vibe with most. Then make a game! Rinse, repeat.

I never really thought about how Flash has affected my life until recently.

My games and open source contributions didn't open a career path or anything life-changing that, but the practice and experience I gained in programming them has absolutely helped me. Coding classes in college, a minor in Computer Science, the light-to-moderate coding I do as part of my job... doing games and all on the side prepared me to be able to take these on. I don't think I would have done the minor or survived at this job without being "fluent" in programming.

Basic concepts like loops and variables of course translate from Actionscript 3 to any other language. But I'll never forget a Java class I took where one assignment was to make a Pacman-style game. Having been coding in AS3 for several years at that point, I was well aware that there's a delay between pressing a key on your keyboard and "holding down" that key (to make typing possible). Without handling it, your character's movement will hiccup almost, before smooth motion begins. I had already dealt with it numerous times back then, so it was trivial for me to do it again for that class. I didn't think about it. Well apparently, almost no one else figured that out and I got bonus points for being clever.

I don't consider 5 points on an assignment to be life-changing, but perhaps the minor and job preparedness were. Maybe I would have gone down that route anyway and learned quickly, but maybe not. Ignoring what maybe could have happened and just looking at what did happen for me, I guess it was life-changing after all. Thanks NG.

Press F and draw a dick to pay your respects.

Play my new game: FlxLightPuzzle Demo!

Made with HaxeFlixel, which I talked about before. Definitely check out that post if you're interested in making games like the cool kids are all doing these days. The neat thing is that I got a SWF version and an HTML5 version of the game from the same code (I don't know Javascript at all, so that's really good for me).

The other neat thing about this game is that the source code is all online and free for people to learn from and edit. Add your own levels or a new mechanic or something!

I haven't uploaded anything in a while, so it was fun working on this puzzle game. If you think there's anything clever about it, it was probably accidental. (apparently it works on Android devices, but maybe maybe not iOS. didn't even know)

I just finished my first post for the HaxeFlixel community, introducing myself and our future goals!

HaxeFlixel is a cross-platform, open-source library for making games. Cross-platform meaning you can make Flash, HTML5, iOS, Android, and native EXE games all from the same code (and maybe even AIR builds now).

If you're worried about the state of the Flash player, you can literally just export to HTML5 instead to upload to NG. Or if you're looking to get onto Steam, just pick Windows/Mac/Linux export. It's that easy.

You can even use your existing SWFs as asset libraries, so you don't have to break your workflow.

The API is similar to AS3's Flixel, except modernized. Both have received praise for being easy to get into. It's being used a ton for Ludum Dare games but also in big games as well. Defender's Quest 2, for instance, will be on Steam as well as consoles.

For your first game or 30th prototype, check out how to get started!

For Enki Adventures, I've been dealing with a fundamental coding problem. Is it better to quickly shove things together to make them work or solve problems elegantly?

Chris DeLeon makes videos where he creates prototypes very quickly, like this platformer. His code isn't organized, and adding features would be a major pain, but it works, especially for Ludum Dare and Game Jams.

I took that approach when generating procedural terrain in my game. Things worked, but I had 1300 lines of code in a single file and a lot of things that would make programmers make a face. Now, I'm rewriting the whole thing far more elegantly. But when I finish refactoring everything, the game will look the exact same. It's for the best, naturally, as I'll be able to make future changes more quickly. But I wonder if I could have avoided all this mess by doing the elegant solution first.

It's probably not possible to come up with a clean solution first, especially when doing something new. You might spend all your time figuring out the "best" way to do something and not spend any time actually doing it.

I guess it's a tradeoff, and I guess the path I'm taking is working. It'll lead to a great blog post about terrain generation once I'm done, complete with algorithms and crappily drawn pictures explaining them.

Stay tuned.

Time flies when you're having fun, and boy was I not having fun.

It's been two years since my last blog post, just before grad school began. It was time consuming as anything but probably (hopefully) worth it moving forward. Now I've graduated and finally have the free time to write up another one of these posts. Plus there are a bunch of people in the Game Dev forum posting devlogs, and I can't let them show me up.

I really didn't have time to code at all in the past year or so, putting Enki Adventures on hiatus. But I've recently had time to get back in the groove of programming. Here are some of the code things I've picked back up. (Hopefully it's not too boring.)

There's a work-in-progress code library for making user interfaces called HaxeUI. It performs some dark magic to make pretty and organized menus, and it works with any game engine written in the Haxe language. It does need a bit of help working with each engine, though, in the form of a backend library. I ended up writing the one for my game engine of choice, Flixel. I've got it integrated into Enki Adventures, so now it's just a matter of positioning and sizing the menus.

People have already started using my code as well! It's always weird and cool when people use your code libraries in their projects. Contributing to large projects is fun, but it's something special when someone finds your little old library and thinks it's useful enough to use.

In Enki Adventures, I use the Nape physics engine for collisions and interactions and things. By being creative, I've gotten these "non-collision" interactions to trigger dialogue and even swimming!

Too bad the little pet guy can't swim yet.

I probably rely on Nape way too much, but my game has excellent performance doing it my way. It also saves me the hassle of having a bunch of different systems in place to do each specific thing: being creative lets one system handle a lot of my game. My code is very organized this way.

My dialogue system I wrote years ago is paying off, letting me also open chests, receive items, and do all kinds of custom behaviors. Technically any behavior, since I'm able to inject code using some more dark magic that this language offers.

Now I'm simultaneously working on the inventory and accessibility options. The inventory is using HaxeUI and is a breeze compared to when I've coded inventories in the past. From ugly spaghetti code to an organized workflow, it's almost like I'm getting better at this. It doesn't hurt when the tools improve too ;)

I'm interested in accessibility as a topic. "Can your game be played with a single button?" "Can your controls be remapped?" "Can the sensitivity be lowered for people with jitters or be raised for people with a limited range of mobility?" "Can colorblind people play?" "What about deaf or blind people?" I can deal with two of those questions pretty straightforwardly, but the others I have no idea. There are some guidelines to include gamers with disabilities, and I'll be perusing those at some point. I saw this one DIY controller that was a bunch of buttons and joysticks on a board controlled by the person's feet; I'm pretty sure that would work with my game without an issue as long as the computer can recognize it in the first place.

So there you go. The next post will be within the next two years, and I'll be updating the Tumblr blog more regularly as well, although code is boring and I'm not sure who would even want to read that.