Game Development, Unity

Learning Unity Again

So no, I really didn’t know Unity that well to begin with, but for the last couple years, I and a few former co-workers (at the time we weren’t former) decided to learn Unity and release some games.   We figured, “What could be so hard?”  We each set off to learn Unity on our own and figured since we were all developers, we could come back together in a few months and start working on our project.

Fast forward 3 years or so later and while we’ve each gone our separate ways, we have kept in touch and are still “learning” Unity.   So, now with the release of Unity 2017.1, we are taking another stab at it.

So where are we beginning?

In my career as a developer, the way I learn the best is typically to just jump right in and start coding.   Well with Unity, that hasn’t worked so well.  I’ve tried and stumbled a few times and this time I need something a little more directed learning, so I’ve found the courses at Udemy.  Udemy has many Unity courses and while their list price is very expensive, you can find discount codes to get the prices down to $10 each.   I’m going through some very basic courses that are actually meant to teach you how to program using Unity and though I’m beyond that stage in my career, they are helpful to see how as a Unity beginner, the common concepts apply.

Inspiration from others.

Not only are the three of us learning Unity together and through that process encouraging each other, we are also taking inspiration from others who have gone on ahead.  One great place to learn about others who many were just like us is on the Made with Unity site, particularly the stories section where there are many tales of those just beginning or creating their first commercial game and the successes and failures.

Just do something.

Developing a game, whether you use Unity or not, is not an easy process.  You must take into consideration some many facets from graphics, sound, gameplay and so much more.  And if you’re learning a new tool, as in Unity, at the same time it can feel overwhelming at times.  But simple words of advice that carry` way beyond Unity game development, is just do something.  Never have a day where you do nothing on your project.  It will take discipline, but it could be as simple as changing a color on a texture or adjusting your design document with a small detail.  Perhaps tweak in animation or adjust a sound.  It could have nothing to do with development directly.  Perhaps you can read an article teaching you a new aspect of Unity you’ve not tried before.   For me, just doing something small can often generate that motivation that I’m lacking and I accomplish more than I ever set out to do.  Momentum breeds more momentum.

Conclusion

We will see how far we will come this time.  We’ve been “motivated” to do this before.  But I hope to share my stories in learning and future development here and perhaps it can motivate someone else to pick up the gauntlet as well.

Game Development, Monogame

Screen / Camera Shake in Monogame

So any time I spend working on my game(s) during the week, I’m trying to move it forward with features, gameplay or whatnot. But on the weekends, I like to polish stuff up and add little effects or fun things that while not necessarily important to the game, add that extra bit of pizzazz that I’m looking for. This weekend I wanted to add something when the player died the screen would shake like a great impact. Here’s a quick video of my game with the finished effect.

I like the effect but it’s one of those things that might not necessarily make it to the final release. Code to do so was really pretty simple (and written pretty quickly so if you see improvements that could be made, by all means let me know. (I also can’t take complete credit for this code as I stole some pseudocode from, http://bit.ly/2aqGzee)

In my main Draw method:

      Vector2 offset = new Vector2(0,0);
      if (shakeViewport)
      {
        offset = new Vector2((float)(Math.Sin(shakeStartAngle) * shakeRadius), (float)(Math.Cos(shakeStartAngle) * shakeRadius));
        shakeRadius -= 0.25f;
        shakeStartAngle += (150 + rand.Next(60));
        if (gameTime.TotalGameTime.TotalSeconds - shakeStart.TotalSeconds > 2 || shakeRadius <= 0)
        {
          shakeViewport = false;
        }
      }

When I want to trigger a shake (on death of player), I set the shakeViewport flag, which is a property on my main game object. All I’m trying to do is change the offset of the draw viewport by random amount in a random direction for a limited amount of time. The shake radius also helps to dampen the shake as the frames progress.

Once I’ve got the offset calculated, I simply add a transform matrix to all my spriteBatch.Begin calls as follows:

spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.Additive,null,null,null,null,Matrix.CreateTranslation(offset.X, offset.Y, 0));

pretty simple effect that fits well for those big impacts.

Game Development

Game Development Update, Arkanoid clone.

While on vacation from my real job, I spent a bit of time working on a new game.  No, I’ve not wrapped up my Asteroids clone, but I had the urge to do something different so I started my own Breakout/Arkanoid clone.  Is there anyone still out there that doesn’t know what Breakout or any of it’s derivatives are and how they play?   If there is, checkout this video (not by me, just a random one I found) of some that are available on Steam now.

So mine is much more basic than any of those…..here’s a few early screenshot (very early with some graphics that I stole or whipped up really quick…those will change at some point).

malyonball-2 malyonball-1

Nothing real fancy yet.   This game I’m putting together more for fun and hey my young boys are enjoying playing it so far.

One thing I’ve done a little different this time as compared to the Asteroids clone I showed last time, just about everything is based off the Entity class.   Anything that is essentially drawable is an Entity.

Entity is simply an abstract class with just a few properties and methods.  This is it in it’s entirety.


public abstract class Entity
{
  public bool IsDestroyed { get; private set; }
  public Vector2 Position { get; set; }
 
  protected Entity(Vector2 position)
  {
    Position = position;
    IsDestroyed = false;
  }
 
  protected Entity()
  {
    IsDestroyed = false;
  }
 
  public abstract void Update(GameTime gameTime);
  public abstract void Draw(SpriteBatch batch);
 
  public virtual void Destroy()
  {
    IsDestroyed = true;
  }
}

So everything else is inherited from that.  So now my main game loop, my Draw is not much more than

public override void Draw(SpriteBatch batch)
{
  EntityManager.Draw(batch);
}

and my update is:

public override void Update(GameTime gameTime)
{
  EntityManager.Update(gameTime);
}

Makes that all pretty simple. Next time I’ll go into a little more depth on how my EntityManager works, it’s a mishmash of bits of code I’ve found in other places, but it’s really pretty simple and seems to work pretty well for simple games like this.

Game Development

Game Development 101

The 101 is not for you reader, but for me. I’ve been coding for 20+ years professionally and many more before that as a hobby back in the 80s. Short history to follow, so if not interested, skip to the next section.

Commodore-64-ComputerBack as a child of around 10, my sister had purchased a Vic20 and had a few games. I was enthralled. I recall some sort of PacMan clone and a few of the old Scott Adams Adventure, in particular AdventureLand. It wasn’t long after, that they became bored with it and I talked my mom into buying it for me. I was in heaven. As a natural tinkerer, I began to dissect the games, mostly in an effort to cheat and slowly, but surely began to create my own.

I wrote a few text adventures, dabbled with some graphical games and continued on that vein, when I had saved up enough money to by a Commodore 64, which was a killer machine back in the day, or at least I thought so. I learned Basic of course, taught myself assembler and some rudimentary graphical work. My neighbor at the time, also a 64 owner, was my partner in crime and we designed a few games together. Nothing ever finished, polished or even close to being released, but we learned a lot and had a blast (we still talk fondly of those days now).

That time prepared me for what would become not only my career, but also a passion. Aside from my faith and my family, it is probably the biggest influence in my life and something I enjoy doing in and out of my job.

History Lesson Over

History aside, I’ve not done much game development over the years. I’ve still dabbled here and there. Even fell back into the text adventure community (yes it’s called IF, interactive fiction, now… but it will always be text adventures to me) and dabbled developing some games there. Heck I even released a couple small ones for various jam style competitions. Check out my profile if you’re interested in seeing those efforts, http://bit.ly/29K06of Not the greatest of achievements, but it was nice to just get something completed and released.

I then dabbled in tool development, taking over the maintaining of one of the communities favorite IF mapping tool, Trizbort (www.trizbort.com). This has been a lot of fun, kept me involved with the community, but used my talents as a non-game developer to support and improve the tool.

MonoGame_LogoMoving forward though I’ve found a love of creating small games. Using Monogame, I currently have an Asteroids clone that is playable, but probably won’t be released anytime soon. Too many assets; music, sounds and art that I’ve “borrowed” from around the net. Mostly developed as a learning experience as I’ve dove back into the intricacies of modern game development tech. And my young boys enjoy playing it, which is reward enough for me. They’ve also become nice little play testers and have helped more than I ever imagined in designing the game.

asteroids1 asteroids2

Why am I telling you this?

Mostly because I felt like posting something…but really, I’m hoping to start writing more articles here on this site and focus on some of the more interesting things I’ve learned through my game development travels as disjointed as they may be. I’m sure I’ll share things that have been learned by others countless times. You’ll be the first to learn of any new game development or if *gasp* I ever plan on releasing anything.

So let’s end this boring post here and get back to development so I can share more interesting things.