00:00
00:00
MSGhero
Free time is nice time.

Nick @MSGhero

28, Male

Somewhere in the North

Joined on 12/15/10

Level:
16
Exp Points:
2,756 / 2,840
Exp Rank:
17,613
Vote Power:
5.83 votes
Rank:
Police Sergeant
Global Rank:
6,432
Blams:
453
Saves:
928
B/P Bonus:
12%
Whistle:
Normal
Trophies:
4
Medals:
635
Supporter:
9y 5m 21d
Gear:
3

MSGhero's News

Posted by MSGhero - March 18th, 2022


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.


Tags:

4

Posted by MSGhero - December 3rd, 2021


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.


Tags:

8

Posted by MSGhero - May 5th, 2021


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.


Tags:

12

Posted by MSGhero - January 1st, 2021


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.


iu_218542_3611941.png


3

Posted by MSGhero - January 19th, 2018


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)

FlxLightPuzzle Demo logo


1

Posted by MSGhero - August 26th, 2017


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.

Really super 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!


Posted by MSGhero - July 21st, 2017


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.


Posted by MSGhero - May 22nd, 2017


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.

 

Inventory

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!

 

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.

 

3611941_149543247351_chest.png

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.


Posted by MSGhero - April 29th, 2015


I wasn't sure what to post, but I wanted to post something today. So here's the current items and scribbled thoughts on the todo list for Enki Adventures, the rogue-like/lite/whatever with Jordan (look at his or my previous posts for actual game info). I doubt it makes sense to everyone (anyone?), but I'm probably not the only one with a chaotic todo list.

Debug shapes are great.

 

 

 

 

 

 

 

 

 

 


Urgent:

  • How do I lob bombs? Either keep the footbox (and hitbox?) on the ground or dot the collision normals (eww)
  • How do I directionally lob bombs?
  • Add hscript enum??? super powerful but super terrifying
  • Tween offset y with bouncing ease for horiz, scale for vert
  • How do I make bombs explode near enemies? onCollide sensor (onSense?) which has to ignore the player and objs (delete inRadius and maybe target)

Important:

  • Rename hitboxes to something better (taking dmg versus dealing dmg)
  • Rename or clarify kb vs kbr in data files (better names prolly)
  • Custom game reset(), flx's is annoying (destroys current state which i don't want prematurely)
  • Abstract action1 for general bomb/boomerang/whatever

Todo:

  • Tween controller?
  • Flicker consts
  • update(0) timing
  • Assign all cb groups
  • Bomb place anim
  • Add facing bias to knockback (straightDir somehow)
  • Better iphysics abstraction
  • Null weapon for enemies: need to specify dmg and kb somewhere tho (enemy stats best place imo)
  • .5 sec extra invuln for player (no hit stun)
  • Hp checks in CR states
  • Placement of onhit/ondeath might account for this (2nd death transition might just be ignored)
  • Gamepad: service per gamepad type (via lime.ui for now)
  • Replay service? (change all math.randoms to flx random to remember the seed)

Minor:

  • Tree positioning for vertical parts (big tree, 80/48/32 screws everything up) + hardcoded numbers ewww
  • Macro build a config file into Consts (into backends in Consts) ???
  • Asset paths into consts?

Polish:

  • Hitting trees and such does something nonpermanent
  • Screenshake
  • Hit hold

Bugs:

  • On transition, only a chunk of the player gets scrolled (move player all the way forward during transition, loc problems?)
  • On transition, if a bomb was exploding in the prev zone, it'll be exploding when you get back (destroy all)
  • Short death anims might NOR with kb tween

Posted by MSGhero - March 6th, 2015


To my left, neural networks are taking their sweet time to run. Behind this browser window, the beginnings of a lab report are forming. On my desk, project concept drawings and notes are scrawled on the backs of receipts. Spring break looms as a deadline and hamper to group project work rather than time off. The stretch before the final stretch.

This is senior year.


WIP

Meanwhile, my code for a Steam-game-hopeful lies restless. Enki Adventures. The flash game that can be casually compiled to an .exe. Haxe, OpenFL, Flixel, and Nape working in tandem, working against each other at times.

The game will look something along these lines and right now looks empty. It's progress. It's 1,125 sprites packed together in a sheet with more on the way.

I thought Steam was for the big players, the real coders, the lifetime game devs. Are we dreaming big, or do we have what it takes? Roguelikes, roguelites, and procedural death labyrinths have a hardcore following. The promo art sketches look badass so far. Tom believes in us.

We shall see.