7 ms·

Same here, first games in QBasic (no functions, all goto!) like Skifree. Used phaser.js for a bit. Last project implemented a sidescrolling beat em up in ASCII.

by dobin 5y ago

Same here, first games in QBasic (no functions, all goto!) like Skifree. Used phaser.js for a bit. Last project implemented a sidescrolling beat em up in ASCII. The most important thing i learned was that implementing your game as classes (with inheritance and all that) is futile. Use ECS (Entity-Component-System), its awesome. Even a simple MVP takes like months or years to develop. During studying how Disney designed animations (the 12 principles, like anticipation, staging..) i realized just how deep you need to go into non-coding things like animations, music, graphics, UI, and more. Shout out to the r/roguelikedev community though, they are awesome. People coding on their rougelikes for 12 years seems to be not extraordinary.

schemescape 5y ago
Did you release the ASCII beat-em-up? Care to share a link? :)
- dobin 5y ago
  Sure: https://github.com/dobin/nkeyrollover https://github.com/dobin/nkeyrollover. You can play it with "telnet exploit.courses". It will crash a lot. Stole some animations from "Stone Story" (Steam)
  - edf13 5y ago
    That is very very cool
    - dobin 5y ago
      Thanks. Still, abandoned it like the author mentioned after nearly getting the MVP to work. All which is left to do is fixing all the bugs, implementing all the skills, animations, enemies and bosses with choreographed attacks, and designing a lot of maps, add a story... (at least there is no music or sound effects). And of course, what often gets forgotten: Make sure it is fun, somehow. In my opinion, nobody can "make" a good game. Can just pump out a lot of games, and hope one is good. Be it EA, or King Digital Entertainment.
  - allenu 5y ago
    This is great! Thanks for sharing. I'm going to share it with some friends. I once had a goal of working on a beat 'em up engine for fun. I wrote one version on Mac and then later thought to write it in javascript. Like many other projects I've done, I got it to a working state and moved on. :) Take a look here if you're curious: https://www.ussherpress.com/yokosukajs/ https://www.ussherpress.com/yokosukajs/ It's not "true" game development, i.e. using modern 3d engines, but it did cover the core issues to think about, and I was learning to write more fp-like code at the time, so it helped me learn functional programming a bit. So, to echo other people's comments, there are transferable skills in game dev.
    - dobin 5y ago
      Hehe, i like it! Except that changing direction quickly left/right feels kinda bad. Seems you wait for the animation to finish before checking for new key presses, not buffering the last pressed key.
      - allenu 5y ago
        Yup, good callout. There's definitely tweaks I could make to get a better "feel". For some background, I have a state machine for the animations and I've set up some to be interruptible starting on certain animations, and in this case, I the "turn around" animation has to play out completely before I allow new directions from the "director". (I call the characters on the screen "actors" and the source of directions "directors", which can be a human or AI.) Anyway, the fun was in coming up with the engine, of course. :)
dj_mc_merlin 5y ago
> Use ECS (Entity-Component-System), its awesome. Seconded. Coding a roguelike in C and the amount of flexibility it gives even with no help from the language itself is crazy. It's really amazing how many concepts that were really hard to abstract become easy. Want a rock to move around and cast fireball? Give it the Actor and Spellcaster components. Do it dynamically at runtime. Now you can make a spell that makes rocks into wizards (.. if only, dynamic effects are more complicated than that, but it's a good showcase of the possibilities)
- dobin 5y ago
  Exactly this. Something like ECS, where you code your game "outside" of your game, may also be useful at some non-game software.
- steve_coral 5y ago
  Could you possibly post a pseudo-code example of how the above would work with ECS? How do you attach the components to the rock object if not inheritance? Would you just have them be functions that you call to include within the rock via a header file or something? Or a separate code module you import, if using Python?
  - dobin 5y ago
    To give a slightly different example. Basically, entities consist of components. Components should ideally just be data (a struct). Systems work on components (data), they are the code / functions. A system only cares about it's component (but for all entities, which have this component). A entity "player" consists of the components like "texture", "input". A "monster" entity has components "texture", and "ai". The graphic processing done by the texture system doesnt care how the changes in x/y position is happening (via AI statemachine, or keyboard input). Player and Monster should shoot too, so attach a "weapon" component to it. But then it's also possible to also create an entity with components "texture:door" and "portal" (portal system will teleport you to something, e.g. next level). No one stops you to attach the "ai" component too, making the door move around. And "weapon", which makes the door shoot too (then maybe call the entity something else, like portaling-monster). As the components are just data stored outside your code, e.g. in files or a DB, you can change them at will. And load it, without recompiling or even restarting your game! This allows a large amount of creativity and innovation, without refactoring your code all the time. I like to connect my systems with a message bus, where they send messages to each other. Messages change components, data, of entities. These may generate more messages. E.g. player clicking left mouse button creates a message, which gets handled by input system. This creates a message for the weapon system, reducing ammo count by one, and change its texture (-index) to like "shootingstance:1", and creating a new entity "bullet" with the source x/y and destination angle.
boredtofears 5y ago
> Use ECS (Entity-Component-System) If your goal is to make a game in a reasonable amount of time, I kind of disagree with this advice. Implementing an ECS system before anything else is a good way to find yourself spending time yak-shaving instead of actually building your game, and for most 2d games, YAGNI (at least not right away). My personal advice would be program some of the major game systems and objects you want for your game first, they'll probably take you longer than expected but at least you'll have something that actually resembles game play and not just a framework for building a game. If you get to the point where you need ECS for performance or organizational reasons you'll probably have a good idea of how you want it to work by then instead of guessing at how you'll use it.
- cableshaft 5y ago
  Agreed. Also for some smaller games the core gameplay itself is the easy part. The rest of it (menus, sound/music, levels, animations, game options, networking, localization, input flexibility, resolution/video settings, shaders, cross-platform support, achievements, leaderboards, statistics, a.i., etc.) is what can take forever. For example, I've got game with a core game loop that's been finished for probably a year now, but I've still got a ways to go with everything else before I'm finished with the rest of it.
xtracto 5y ago
A tangential thing that I've found: I also started programming by doing games. Also did a "pong" clone in Basic, a "reverse" UFO game in BASIC as well (you controlled the ship and had to avoid getting shot, get to the bottom of the screen and "rescue" persons [white dots]). I also did some more sophisticated games in C using Allegro. And a bit later I experimented with Direct3D and OpenGL under Windows. I loved making games. Fast forward 25 years later, I have installed Unity, Unreal and some other OpenSource game development environments, and I just cannot find heads or tails. I've followed some Udemy courses, but for me, the current "game development" process feels more of a "graphic designer" process than a programming process. I would love to make games, but it seems that the current "tools" are more tailored to artists type rather than programmer types.
- dobin 5y ago
  Unity uses some kind of ECS, see other discussion. And there is a bit of a difference between game, and game engine. Unity is really for creating games itself, where most part is not engine work. Like most developers, we like to do engine work though, not graphics. If you want some fun, find a lower-level engine which just implements some parts (e.g. while Phaser.js is a big game engine, still need to do a lot of coding by hand). Alternatively, use weird things. ASCII, HTML Checkboxes, voxel graphics, svg, in rust...
  - istjohn 5y ago
    Vanilla HTML Canvas is easy to get started with and can be a lot of fun.

by dobin 5y ago

schemescape 5y ago

Did you release the ASCII beat-em-up? Care to share a link? :)

dobin 5y ago
Sure: https://github.com/dobin/nkeyrollover https://github.com/dobin/nkeyrollover. You can play it with "telnet exploit.courses". It will crash a lot. Stole some animations from "Stone Story" (Steam)
- edf13 5y ago
  That is very very cool
  - dobin 5y ago
    Thanks. Still, abandoned it like the author mentioned after nearly getting the MVP to work. All which is left to do is fixing all the bugs, implementing all the skills, animations, enemies and bosses with choreographed attacks, and designing a lot of maps, add a story... (at least there is no music or sound effects). And of course, what often gets forgotten: Make sure it is fun, somehow. In my opinion, nobody can "make" a good game. Can just pump out a lot of games, and hope one is good. Be it EA, or King Digital Entertainment.
- allenu 5y ago
  This is great! Thanks for sharing. I'm going to share it with some friends. I once had a goal of working on a beat 'em up engine for fun. I wrote one version on Mac and then later thought to write it in javascript. Like many other projects I've done, I got it to a working state and moved on. :) Take a look here if you're curious: https://www.ussherpress.com/yokosukajs/ https://www.ussherpress.com/yokosukajs/ It's not "true" game development, i.e. using modern 3d engines, but it did cover the core issues to think about, and I was learning to write more fp-like code at the time, so it helped me learn functional programming a bit. So, to echo other people's comments, there are transferable skills in game dev.
  - dobin 5y ago
    Hehe, i like it! Except that changing direction quickly left/right feels kinda bad. Seems you wait for the animation to finish before checking for new key presses, not buffering the last pressed key.
    - allenu 5y ago
      Yup, good callout. There's definitely tweaks I could make to get a better "feel". For some background, I have a state machine for the animations and I've set up some to be interruptible starting on certain animations, and in this case, I the "turn around" animation has to play out completely before I allow new directions from the "director". (I call the characters on the screen "actors" and the source of directions "directors", which can be a human or AI.) Anyway, the fun was in coming up with the engine, of course. :)

dj_mc_merlin 5y ago

> Use ECS (Entity-Component-System), its awesome. Seconded. Coding a roguelike in C and the amount of flexibility it gives even with no help from the language itself is crazy. It's really amazing how many concepts that were really hard to abstract become easy. Want a rock to move around and cast fireball? Give it the Actor and Spellcaster components. Do it dynamically at runtime. Now you can make a spell that makes rocks into wizards (.. if only, dynamic effects are more complicated than that, but it's a good showcase of the possibilities)

dobin 5y ago
Exactly this. Something like ECS, where you code your game "outside" of your game, may also be useful at some non-game software.
steve_coral 5y ago
Could you possibly post a pseudo-code example of how the above would work with ECS? How do you attach the components to the rock object if not inheritance? Would you just have them be functions that you call to include within the rock via a header file or something? Or a separate code module you import, if using Python?
- dobin 5y ago
  To give a slightly different example. Basically, entities consist of components. Components should ideally just be data (a struct). Systems work on components (data), they are the code / functions. A system only cares about it's component (but for all entities, which have this component). A entity "player" consists of the components like "texture", "input". A "monster" entity has components "texture", and "ai". The graphic processing done by the texture system doesnt care how the changes in x/y position is happening (via AI statemachine, or keyboard input). Player and Monster should shoot too, so attach a "weapon" component to it. But then it's also possible to also create an entity with components "texture:door" and "portal" (portal system will teleport you to something, e.g. next level). No one stops you to attach the "ai" component too, making the door move around. And "weapon", which makes the door shoot too (then maybe call the entity something else, like portaling-monster). As the components are just data stored outside your code, e.g. in files or a DB, you can change them at will. And load it, without recompiling or even restarting your game! This allows a large amount of creativity and innovation, without refactoring your code all the time. I like to connect my systems with a message bus, where they send messages to each other. Messages change components, data, of entities. These may generate more messages. E.g. player clicking left mouse button creates a message, which gets handled by input system. This creates a message for the weapon system, reducing ammo count by one, and change its texture (-index) to like "shootingstance:1", and creating a new entity "bullet" with the source x/y and destination angle.

boredtofears 5y ago

> Use ECS (Entity-Component-System) If your goal is to make a game in a reasonable amount of time, I kind of disagree with this advice. Implementing an ECS system before anything else is a good way to find yourself spending time yak-shaving instead of actually building your game, and for most 2d games, YAGNI (at least not right away). My personal advice would be program some of the major game systems and objects you want for your game first, they'll probably take you longer than expected but at least you'll have something that actually resembles game play and not just a framework for building a game. If you get to the point where you need ECS for performance or organizational reasons you'll probably have a good idea of how you want it to work by then instead of guessing at how you'll use it.

cableshaft 5y ago
Agreed. Also for some smaller games the core gameplay itself is the easy part. The rest of it (menus, sound/music, levels, animations, game options, networking, localization, input flexibility, resolution/video settings, shaders, cross-platform support, achievements, leaderboards, statistics, a.i., etc.) is what can take forever. For example, I've got game with a core game loop that's been finished for probably a year now, but I've still got a ways to go with everything else before I'm finished with the rest of it.

xtracto 5y ago

A tangential thing that I've found: I also started programming by doing games. Also did a "pong" clone in Basic, a "reverse" UFO game in BASIC as well (you controlled the ship and had to avoid getting shot, get to the bottom of the screen and "rescue" persons [white dots]). I also did some more sophisticated games in C using Allegro. And a bit later I experimented with Direct3D and OpenGL under Windows. I loved making games. Fast forward 25 years later, I have installed Unity, Unreal and some other OpenSource game development environments, and I just cannot find heads or tails. I've followed some Udemy courses, but for me, the current "game development" process feels more of a "graphic designer" process than a programming process. I would love to make games, but it seems that the current "tools" are more tailored to artists type rather than programmer types.

dobin 5y ago
Unity uses some kind of ECS, see other discussion. And there is a bit of a difference between game, and game engine. Unity is really for creating games itself, where most part is not engine work. Like most developers, we like to do engine work though, not graphics. If you want some fun, find a lower-level engine which just implements some parts (e.g. while Phaser.js is a big game engine, still need to do a lot of coding by hand). Alternatively, use weird things. ASCII, HTML Checkboxes, voxel graphics, svg, in rust...
- istjohn 5y ago
  Vanilla HTML Canvas is easy to get started with and can be a lot of fun.