ECS Quest: Part 1

OK, so here I am again! Time to give some details on what I’ve been up to.

Lately, I’ve been working with pure Haxe and OpenFL to make an Entity Component System for game development purposes. In a nutshell, ECS is in part about avoiding heavy encapsulation and inheritance by forsaking traditional object-oriented methodologies and splitting the data (components) and logic (systems) up. So systems, more or less, pull in components and act upon the data as opposed to data objects having their own member functions. Entities (i.e. actors and objects in one’s game) own components and hand them over to systems when they require their services. As a simple example, an entity might hand a position and sprite component over to a drawing system, and the drawing system will update the sprite coordinates based on the position data.

The advantages may not be readily apparent; it might take a little thought. Consider this: how often does one object/entity looking at another object/entity need every shred of data attached to it? Probably not very often. Gluing large, copious amounts of data together into one class or object comes with potential problems, as many seasoned programmers know. It also means that data coexists as a single blob, not necessarily as individual pieces of data. Ever tried to “kill” an object but still need some of its data for aftereffects, enemy reactions, and so on and so forth? This can often involve “ungluing” multiple pieces of data and cluster-firing them into other objects so the dead object’s data is not forgotten prematurely. Not normally an elegant or gleeful process. That or you keep everything and track all the little odds and ends until you can dispose of the object as a whole. But then you also have to keep track of what should be running and what shouldn’t be… which is a problem not just exclusive to death sequences. Complexities to deal with abound in programming, but things can get out of hand in situations like these.

With the ECS, its different. An entity is composed of components. These components are in turn each responsible for a (typically small) chunk of data. This is all done without inheritance, using something like a map instead. It means that an entity can acquire multiple features without having massive inheritance chains or even having to know ahead of time everything it might possibly need. Add what you need and go from there. Cool, huh? Imagine making stronger variants of enemies simply by adding a few components to them in an arcade game. On top of that, each component and its data are free to move about without having to necessarily concern itself about any other component. Now when you kill your object, you can keep what you need and simply pull the rest of it from their corresponding systems as a quick and easy shutoff.

In theory, of course. ECS isn’t without its quirks. Something has to keep track of all those hundreds–maybe thousands–of cute little data pieces flying all over the place. There IS a certain comfort in knowing your data is all accounted for in one pretty (if not big) basket. But remember that we sacrifice some encapsulation for the sake of fluidity. You can put the OO-glue away and build complex objects out of a series of building blocks rather than making them into one inseparable blob. It still takes some work, but the benefit may well be worth it.

So that’s a quick introduction. This is what I plan to run with for Ludum Dare 31. I’m still working out some kinks, but hopefully I’ll be ready. I think I’ve given a substantial primer for now, so I’ll save some of the more in-depth details for a later post. If you want to know more about ECS, click the link above. Stay tuned and thanks for reading!

Posted in Uncategorized

Gearing Up

First off, I’m not sure what happened with my last post and its blank-edyness. Sorry.

So I’ve been relatively quiet lately. I started my new full-time programming job roughly six months ago (I can’t remember if I posted about this already,) and its kept me quite busy and, to be honest, worn out at times. Lately though I’ve been chipping away at things, and the hope is to have a head of steam built up when the upcoming Ludum Dare 31 takes off. I missed the last one because… well, that was even closer to the start of my new job and it was rather apparent I was not zoned in for it. I figured out that, now that I’m working a full-time job, I may have to be a bit more deliberate in my efforts. This time I’m prepping a bit more.

I must say, I’m pleasantly surprised to see that traffic for this blog has been adequately steady over the past months. Thanks guys! As we get closer to Ludum Dare and I fire up the game designer’s engine, watch for updates. I want to talk a bit more about what I’ve been doing lately, but I’m not quite to the point yet where I want to share. Perhaps a loose end or two to tie up, but hopefully soon.

Posted in Uncategorized

Photon Speaks!

Posted in Uncategorized

One Game… 24 Hours… O_O

So kind of last minute, I decided to enter the latest FGL (www.fgl.com) jam that lasted for 24 hours. As a result, I stayed up until about 6 AM this morning cranking out something to match the theme “epiphany”. Was it worth it? You bet! I’ve released a new game (demo) on FGL. These jam things seem to work out nicely for me.

Anyway, the game isn’t public yet and probably won’t be for awhile, but if you have an FGL account and the appropriate credentials, you can take a look at “StarCaptain” here (bear in mind its still a work-in-progress):

https://www.fgl.com/view_game.php?from=dev&game_id=31868

StarCaptain Logo

Posted in Uncategorized

Some words from Photon!

Hehe… yeah. It’s been awhile since I’ve made a post. If you hang around the Stencyl forums you know I haven’t gone away, but otherwise…

Well, I’m still here. Basically, between the holidays, multiple “events” such as losing heat, and getting quite sick, I kind of fell off the blog posting for a bit.

On the other hand, I recently got my hands on Stencyl 3.0 and have gotten into that some. Exciting! As well, as I struggle with starting a new game project, I want to potentially discipline myself to release a GDE on a weekly basis to help focus myself and sharpen my design skills. How does that sound?

So as I’ve said before, stick around. I’m still here!

Posted in Uncategorized

Photon’s “Steps” for Beginning Game Devs

Well… I’ve been at this whole game design thing for over a year now. Its still definitely a work-in-progress, but I’ve been trying!

Having been at it for awhile and watching other game designers, I decided I wanted to share some of what I’ve learned and seen over the last year or two. Presented below are my “20 Steps” for the beginning game developer. This isn’t any hard-and-fast formula for making a game, but some pointers and how to respond to some of the different “stages” of the development lifecycle. Trust me when I say I’m not perfect either; as I said, trying to apply what I’ve learned takes work! But hopefully this can help you if you aren’t sure how to get going on your first project.

Enjoy:

  1. Actually start making a game. A lot of people have “ideas”. Now be different and actually try to execute one of them.
  2. Once you start doing #1, get over your pride when you realize how extremely unlikely it is that your first game will be a masterpiece that will shake the very foundations of the gaming community. In short, your first game probably won’t be that revolutionary and may actually be kind of bad… but that’s OK! You have to start somewhere as a beginner, and being a beginner does not mean you’re a loser. Game design is hard, especially if you are handling every aspect of the game yourself: coding, graphics, audio… all that good stuff. Even then, handling just one can be hard. And besides being hard, it can also be time-consuming. Why do you think major game studios with big teams can work for a year or two on a single game?
  3. Once you come to grips with #2, take a deep breath and set realistic goals. Start small. A game that is simple to play is not necessarily simple or fast to build. You may already be realizing just how much work goes into handling physics, managing health, and all that good stuff that seems so natural in most games. And don’t get discouraged; this stuff takes time… lots of time. But that’s part of why you want to start small; you don’t want to take on a huge project for six months then realize you are way over your head. Despite the greatest amounts of determination you wish to have, don’t shoot yourself in the foot. Keep things in perspective, learn, and start SMALL.
  4. Once you have your goals from #3 you may realize even these seem tough, so find some good help and get involved with a game dev community. Vets and other game designers can be good to bounce your ideas off of and can potentially help you solve annoying bugs and other dilemmas.
  5. Realize the vets from #4 may have their own game projects (and lives) just like you. In other words, they aren’t necessarily there to wait hand and foot on you. Don’t get angry when no one replies to your pleas for help within the hour of you posting it. Its even possible you may not get an answer; no one may know the answer! Perhaps the answer is a project in and of itself, in which case the initiative may lie on your shoulders to figure it out. When this happens, head back to the drawing board, do some problem-solving and creative thinking, and if push comes to shove change direction if you really have to. But don’t blow a fuse; don’t expect many people (on either side of things) to win when that happens on the internet. Trust me.
  6. For best results and to avoid frustration from #5, pay attention to and actually read your community’s rules. If you want to get taken seriously and actually solicit good help and feedback, then follow the guidelines set out by your community. Chances are they aren’t there to make your life miserable and if you think “no one really cares about proper grammar or etiquette on the internet”, think again. On the other hand, if you actually want to at least pretend you know what you are doing, then follow the rules. Seriously. Act professionally.
  7. Part of the professionalism from #6 comes from “being a game designer first”. Now I’m not saying change who you are or act out of character. What I mean is this: don’t try to be a funny guy or know-it-all when you first step foot onto the forums. You can have some fun, but let people know that you are serious about game design first. If you flood the forums with funny pics and random posts in your first few days (or weeks), that makes you look more like a ham than a guy who wants to make games, don’t you think? Establish a good reputation first, then people will know you actually aren’t a total clown when and if you decide to act like a clown for a few brief posts. Make a good first impression.
  8. Don’t forget to make your game by spending too much time with #4-7. The internet can be a great tool but also a massive time sink. If you find yourself spending more time on the community forums than on your game, take a step back and evaluate. Remember that the point is to make a game, right?
  9. If you’re struggling to stay motivated and focused on #8, code and design anyway. Most people can and will hit the wall sometime in the design process. Yes, the wall… that mighty blockade that can knock you over just when you thought you were unstoppable and were going to get the game out months ahead of schedule. But its hard work. You probably will have those days where things just aren’t clicking. But do your best to maintain some momentum; stopping for a week or two can be shattering to your overall determination and make things ten times worse when you try to pick it back up. Keep the ball rolling.
  10. If you’re still struggling with #9, enter some short-term game jams. Ludum Dare is one good example. Even the game developer vets take advantage of these jams; they are excellent motivators, foster experimentation, and can force you to keep your scope small. After all, you can only do so much in 48-72 hours (Ludum Dare timeframes). You don’t have to abandon your old project; but you can take a break and preserve momentum another way by working a smaller less ambitious project. Plus, you can ride the momentum of other designers who are working on their games and sharing their progress and energy. TAKE ADVANTAGE OF GAME JAMS!!!
  11. One great allure of #10 is the audience. You have a great opportunity to solicit feedback from people. The same can be true in a regular game dev community. Get your game out in the open, be it in prototype-form or beta, and see what people think.
  12. STOP; before you tell me about getting ignored on #11, remember #5. If you are serious about getting feedback, then give feedback yourself. Give and receive. Go after people. Make sure your game is visible and that you are “marketing” it, even if only to a small group of people in a particular community. Sure, you may be busy too, but if you show that you care about someone else’s project, they might be more motivated to take time out of their schedule for you as well.
  13. Once you’ve handled #12 and the feedback starts flowing, STOP AGAIN; now remember #2. When people start telling you all the things wrong with your game, don’t lash back. Remember our big name studios? Even their masterpieces can catch avid criticism. Yes, it can feel like you are under attack, but do NOT take feedback specifically on your game personally. We are trying to improve your game and game design skills, remember? Even if someone does go on a bit of a rant, look for what truth is there and shake off the rest. Don’t let it shoot you down.
  14. When you start incorporating the feedback from #13, keep an open mind. Be willing to look at your game through different sets of eyes. As designers we don’t necessarily see things the same way as the players, and furthermore we can be prone to “falling in love” with our precious project. Carefully consider feedback and try to see how your players think. Be willing to make changes… even major, time-consuming changes if such is necessary.
  15. Persevere, especially near the end. Sometimes the last 10% of your game is what can take the most time. All the polish and little details that you may have put aside temporarily still should get your attention. It may be grunt work, but someone has to do it, right?
  16. Persevere more. You’ve put a lot of hard work into your game up to this point. Stay strong and make it count!
  17. Persevere even more. Even if your interest is waning and you feel the project isn’t going to win any “game of the year” rewards, getting your first games out there into the open can be huge. Eye-opening, even. Remember, don’t be afraid of criticism! Absorb it and grow!
  18. Persevere yet more. This is important! Why else would I mention crazy muffin-launching robots?
  19. You have no idea that I said something about crazy muffin-launching robots in #18, do you? Why’d you skip that one? Because it said persevere and you thought you knew what I was going to say? Listen, as you near the end, don’t get hasty and start forgetting things and skimming over critical parts. After coming all this way, do you really want one little control bug to ruin half your game? Take some time to do things right, and get more (beta) feedback if necessary. Keep doing things right.
  20. FINISH THE GAME. RELEASE. CELEBRATE.
Posted in Uncategorized

Game Design Elements #5: The End-goal

Let’s face it: a game is pretty pointless if you don’t have some sort of goal for the player to strive for.

But let’s face it (again): do you have any idea how easy it is to neglect this? If one comes up with some cool gameplay mechanics, that may be fine and dandy, but what do they mean? What are they helping the player to accomplish? One can’t assume that a deep combat system or crisp physics will add substantial value to a game by themselves. And yet that’s what can happen. The power to do great things becomes next to nothing if there are no great things to do in the first place.

So don’t forget to make sure your game not only has an end-goal(s), but a strong one at that. Everything the game does is going to (or should) filter into your end-goal(s).

Element Overview

Does this really bear much explanation?

Yes. Yes it does.

Example time: think about the game of chess. What is the goal of chess? It’s to capture the king piece of the other opponent. Simple enough to know, but can be extremely difficult to execute against a smart opponent. You also have a bunch of other pieces like knights and bishops to help your cause.

Some pieces are particularly “powerful”; that is, they have very flexible movement abilities. The queen in particular is a very good piece. All in all, the king is one of the more limited pieces in terms of movement.

As a player, you want to get the other king and protect your king, but you also feel compelled to utilize and protect your more powerful pieces like the queen. In fact, its easy to get caught up in trying to make sure you don’t lose pieces like your queen. You strategically place and move so that the queen can do damage while not being caught itself. Great value is placed on the queen. Smart opponents can exploit this: if they can get you to lose focus on the king and pay more attention to protecting your queen, look out.

In short, you can forget what your most important piece is: the king. It doesn’t matter if you have every other piece but the king; if you have no king, you’re cooked in chess.

In chess, you are working towards something. In your game, your player needs to be working towards something as well. Cool-looking fluff in your game that doesn’t give back to the end-goal is… well, fluff. It may have a fleeting novelty to it, but eventually it will lose its worth to the player and potentially lose that worth quickly. The queen in chess, though not the most important piece, helps protect the king and attack the enemy in pursuit of the other king when used properly.

Let the player give to the end-goal of the game, and then let the game give back.

Element Incorporation

When you think about it, this is perhaps the enigma of gaming itself, and one of the reasons video games in general fascinate me. Something in a made-up, fake universe can hold meaning to a real-life individual? But then again, if we were so anchored in reality, why did we spend so much time as children imagining ourselves flying out into the deep cosmos or becoming superheroes who rescued the world? Or why do we place value on putting balls and pucks into nets?

Though at the end of the day I’m a big proponent of keeping things in priority, you can hopefully begin to see where I’m going with this. Things like these let us compete, socialize, and even grow. They put value on “skills” that may not otherwise have much value, or perhaps even reinforce the value of already useful skills. They give us opportunities to do or feel things that we may not have experienced otherwise or been motivated to experience.

Therein lies one of the greatest allures of gaming: that somewhat inexplicable ability to tap the energy, emotion and curiosity of our being. Video games are not (and should not) be a total replacement for reality, but not unlike many other mediums (movies, painting, etc.) they can in part forge their own atmospheres, challenges, and connections with the player.

This is what you should be figuring out. What does the player expect to get out of the game? Think about (1) what are they working towards and (2) how are they going to get there? It is the cooperation of the these two things–solid gameplay and good direction–that will help your game to excel. This could be the toughest part of the whole design process. Will the player connect with the game? Will they feel compelled enough by the direction of the game to keep playing? Will the gameplay itself be fun and enable them to accomplish their priorities?

Element Optimization

Know Your Focuses: Recognize immediately that gameplay and goals need to work in tandem. If you are interested in developing a particular gameplay mechanic or game genre, don’t get tunnel vision and focus exclusively on that. Think about how your mechanics and end-goals are going to work together to make a fluid experience, whichever you come up with first.

Know Your Audience: If you’ve decided to target a specific mechanic or genre, know what your potential players are already expecting from such a game. That doesn’t mean you can’t take risks, but familiarity can totally change someone’s outlook on a game. If a player has grown accustomed to a kind of game being a certain way, it can transform their way of looking at all games of that kind. In short, have some idea of what your target audience is, and go after them to make sure they actually want to and will play your game. Address concerns if need be as well.

Take Your Time: When we’re talking about the driving force of your game, take the time to make it right. If something’s not working, fix it or start over or do whatever you need to do. No matter how cool something sounds, still make sure its fun!

In Conclusion

To close, I’d like to remind you that there is a wide variety of goals you can choose for your game. Your goals could capitalize on no-nonsense heroism, the thrill of the hunt, or strong character development. Games have played and catered to a wide variety of interests over the years. And as I like to say, risks aren’t always bad. Better game design is one of those things that can come with experience, and as you move onto bigger projects hopefully you’ll find yourself with a well-rounded skillset to pull off what you are looking for.

Now go. Make games. Have fun. B)

Posted in Uncategorized

Looking Ahead…

So now that the initial game development of Ludum Dare 28 is done and over with, what lies ahead for me in the game design world? Let’s see…

  • Back to the 30/30 ChallengeI still plan to get back to this relatively soon. I’ve had some family coolness going on this past week and the wonderful holidays are upon us, but do not fear. I think it’s still a great challenge for myself and it will help my overall dev skills in the long run.
  • Post-Compo Version of the LD 28 entry “Batteries Not Included”

    I feel like Max and I did pretty well on this thing. I’m thinking I’d like to add some more levels among other features such as a cumulative high score for end-level battery power and “medals” for completing levels with certain amounts of juice left. Due to the constraints of the LD timeframe, I feel there is potential still left to be taken with the gameplay and its concepts. When and if I touch all of it up (and Max is cool with putting it elsewhere), I’d like to stick it on Kongregate and see how it does.
  • The Dawn of a Bigger Project…?

    There’s something about this game (it’s my LD 27 entry)…

    While I finish the post-compo version of “Batteries Not Included” and I work the 30/30 challenge, I may start writing up and brainstorming a new design and re-haul for this game. Will the mighty Belchworm yet belch once more?

    Maybe in due time…

In short, I feel Ludum Dare 28 really was a nice kick of energy. I felt excited to get another game out into the open, and hopefully that trend will continue. Stick with it!

Posted in Uncategorized

“Batteries Not Included” Post-Mortem

In case you haven’t played yet: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=7658

So, my second Ludum Dare  is in the bag and in my opinion, I think it went A LOT better than last time. The game is significantly more polished and I’m very pleased with the end-product and reception to said product so far. So now its time to share my thoughts:

What Went Right:

Game Concept and Theme: I really didn’t want to go the obvious way with Ludum Dare 28’s theme. “You Only Get One” was a good theme but there were some pretty common avenues I could take with that. Though not necessarily bad ideas, I wanted to be unique in my game design. But how? Mainly, the theme struck me as one that could key in on consequence. Having “only one” wasn’t supposed to be merely an inconvenience; I wanted it to mean something gameplay wise. One of the ideas I thought about was a system where you might have multiple robots, where one was randomly assigned to you at the beginning of the game and, should it die, you might not see it (and its special abilities) again for many playthroughs because of the random select. Unfortunately, this would have taken a lot of time to put together, both mechanics-wise and art-wise, and I knew pretty quickly it wasn’t a very viable option for me or the artist. But I liked the idea of having multiple robots with different abilities, and from it stemmed the driving idea behind “Batteries Not Included”: you would have multiple robots, but you could only use one at a time because you only had one battery. Though swapping characters isn’t particularly new, that idea combined with the shared battery gauge I felt gave me a solid interpretation of the theme and a good basis for gameplay.

Coding and Workflow: Teaming up with Max Glockling Games from Stencyl meant that I could focus on my strong point: programming and logic. Sure, I used placeholder graphics a lot at first, but up to that point I’d sort of underestimated them. Problem is, in the past I’ve been reluctant to use them; knowing my artistic abilities on pixel art and what have you, I was leery of assigning a certain “level of detail” to my art prematurely per size. However, this time I could shoot some dimensions at the artist and he would come through. And I must say, looking back it’s a little eye-opening to see just how efficient I was as a result. On Saturday, with art not so much a concern for myself, I was in the zone with my coding. Code, code, NOT art, and more code. Thanks Max! I did eventually take a “break” and whip up a quick musical tune, but mostly it was me coding away and designing levels. I think its definitely shown me in part how I work best when it comes to games, and its certainly something I need to take into consideration for future projects, particularly those where I’m doing everything myself.

Strong Gameplay Mechanics and Overall Level Design: Though I can’t say I necessarily got to fine-tuning everything to perfection, I feel the game is moderately balanced and diversified in terms of gameplay. Each robot has its ability, specific shape, and battery consumption. The combination of all of these gives some good flexibility, even if I lacked the time to utilize every aspect to its fullest. In short, I had a good set of advantage(s) and disadvantage(s) for each robot. Although I might argue the Floater/UFO guy was harder to balance than the other two, there were certain nuances particularly about his tractor beam that I could exploit to prevent him from making the game too easy (and he’s the biggest battery hog for good reason too).

What Went OK:

Audio: No sound effects, but I did get music in there. It would appear though that the music got to be very repetitive and annoying after awhile to some… at least per the responses on the livestream playthrough I was watching. I actually laughed (I wasn’t the only one). When and if I release a post-compo version, I may have to change things up and look into getting some sound effects too. Ultimately though, I think I made it somewhat satisfactory.

Collision Coding and its Quirks: This. This arguably is what consumed the half or so of my coding time. I dealt with this A LOT. I tried to make certain objects pushable under different circumstances. I tried to make it so the UFO guy couldn’t pick up objects from the side with his beam. I tried to make it so the dozer guy could move past certain objects at times and push them when he needed to. And it wasn’t necessarily unusual for me to get past one problem and have it introduce another. Trying to program all these nuances, in essence, around Stencyl/Box2D’s way of handling collisions was definitely a task! But, in the end, I got it to work. Having that clear dedication to coding definitely helped.

What Went Wrong:

Number of “Planned” Levels: I didn’t get to the amount of levels I wanted; I had been shooting for at least 15, and I only got to 12. On top of that, the first 8 were pretty straightforward because they were sort of introductions to different mechanics. That being said, the last four levels picked things up nicely… sort of. That brings me to my next point…

Somewhat Unbalanced Difficulty: Fortunately in the gaming world these days, people seem a little more forgiving of the super-hard difficulty. The people I watched play my devious Level 11 spent probably 20 minutes trying to figure it out (I went on to claim I probably should have made that one the last level instead of what was Level 12). That being said, they found beating the levels quite rewarding when it was all said and done. Nonetheless, with more time I could have potentially balanced the difficulty a bit better. I kind of cringed a bit as I saw them trying to get past even the first parts of the level, but they hung in there and still seemed to have fun while doing it (although on one occasion they cried my name out in “anger”).

Collision Problems: Hey hey… guess what? Still had some issues here. One issue was more of a collision box tweak that I thought I had fixed, while the other issue behaved like I would have expected it to but caused undue difficulties in certain situations. The latter happened on Level 11 many times in their attempt, and it was a bit hard to watch, especially since the game has that perpetual, looming battery drain going on that can cause total level restarts.

* * * * * * *

All things considered, I think Max and I managed to make a pretty great product. I’m quite encouraged by the feedback I’ve gotten thus far, and we’ll have to see how the ratings turn out. However, getting to see someone play it over livestream was big, and I’m glad I got to see that. This time, if all goes well, I would like to release a post-compo version to Kongregate. I have some ideas I didn’t get to implement, would like to add some more levels, and perhaps iron out a better difficulty curve; I think there is some solid potential still left to tap. If you’d like to see a post-compo version, say so! After all, I’m making the game so people like you can play it, right? 🙂

Thanks for reading.

Posted in Uncategorized

Batteries Not Included is Live!

Phew. Made it. Here it is:

http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=7658

I’ll probably update the Games page in the near future and write a post-mortem. But I’m a little worn out from doing LD alongside exams, so… maybe later. 😛

Big thanks to Max Glockling Games (maxglocklinggames.com) for the art.

Posted in Uncategorized