Recently I pushed a bunch of updates to the default branch of Otter since I totally forgot to for about two months... whoops. Here's a quick recap of the changes you can find now in the default branch.

* Collider.Render() now has a color parameter that can be used to determine what color the collider will render with.

* Fixed a dumb crash in the debugger when hitting tab to autocomplete methods.

* Changed Entity.UpdatedOnce to public get.

* Window position can now be set with Game.WindowX and Game.WindowY, and added Game.CenterWindow() to center the window on the primary monitor.

* Moved Otter to the official build of SFML 2.2, and fixed some weird bugs with that.

* Removed Color.Bytes since you can use FromBytes.

* Tiles on a Tilemap can now use their own color as well as the color that is set for the entire tilemap.

* Moved Otter to .NET version 4.5 (probably going to be 4.5.2 fairly soon.)

* Added GetComponent(Type) which can be helpful for getting a component of a certain type that is unknown at compile time.

* Fruckert added diagonal rotation for tiles.

More changes are always available in the dev branch!

Okay apparently it's been like three months since I've posted about Otter updates, and there's been a lot since then. I guess since my life was in chaos for the past few months I slipped up. Oh well! Here's a quick breakdown on changes and fixes to my C# game making framework thing.

* Fixed a bug with rendering a BoxCollider with a width or height of 1 or 0.

* Fixed a rendering bug caused by changing the font size of a RichText object at runtime.

* Added flags for Sound and Music to check if they're currently playing audio. Sound.IsPlaying and Music.IsPlaying will be true if they're playing back audio.

* Added Color.Shade(float) which will return a color from black to white with the specified float. For example Color.Shade(0.5f) will return a gray color where 0.5f is set for red green and blue.

* Fixed a bug in Input.CharToKey() (a key was missing...)

* Fixed a bug in CollideEntities where an Entity could collide with itself.

* Added Collider.Overlap(x, y, px, py) which will do an Overlap test with a specified point (px, py) Very useful for doing UI stuff and checking for a point overlapping a collider.

* Fixed a bug with LastPressed and LastReleased timers on Button.

* Added Util.ListCombine<T>() to take a bunch of lists and combine them into one list. I don't know if this is already a C# thing so whatever.

* Added Color.FromBytes()

* Added Axis.Reset() to totally clear an Axis's input state.

* Added Button.Reset() to totally clear a Button's input state.

* Fixed a bug where Gradient wasn't blending with its Color.

* Added DataSaver.FileExists().

* Added Particle.ActiveCount but I'm not totally sure if this works as intended.

* Fixed a bug where creating a Text object would not accept an SFML.Graphics.Font.

* Added MouseDeltaX and MouseDeltaY to get the mouse movement since the last update. Mostly used for locking the mouse inside the game window.

* Util.GetFieldValue works for static fields now.

* Added Scene.CameraFocus which if set to an Entity the Scene will then follow that Entity.

* Added Rand.IntXY which returns a vector2 of ints.

* Reworked EventQueue component into EventStack and EventQueue.

* Added GraphicList which is a Graphic type that is a list of graphics.

* Added Anim.OnNewFrame() which is invoked whenever the current frame of an Anim changes. Useful for tying code to specific frames of an animation.

* Huge debugger api changes which uses attributes now instead of RegisterCommand with CommandTypes. Check out the example here to see the new style.

* Added a bunch of stuff to the Debugger like tab auto complete and parameter help when typing in a command.

* Entity.UpdatedOnce is now public (private set.)

* Scene.RemoveNextFrame(Entity) will remove an entity with a one frame delay.

Wow that's a lot of stuff! I'm really happy with the new debugger API that uses all kinds of crazy reflection stuff now instead of a bunch of RegisterCommand method calls.

If you've been using Otter then you should drop by the official slack sometime and hang out with your fellow otter lovers!

This week has been pretty productive but I've neglected to keep up on my blog posts! I'm making pretty good progress and I've started trying out organizing my task list into week by week chunks. I'm trying to figure out the best way to keep my motivation up when I know I have a billion things to do, and I think just sorting tasks on a per week basis is a good start... maybe more on that some other time though!

For now this post is about using Otter's debug console to help run through battles in my current prototype.

I have a bunch of commands for manipulating the stats of different actors during the battle, and also some debug commands for stuff like winning an entire battle (for testing all that end of battle result screen type stuff.)

Also as I worked on this I realized that not a lot of people know about the debug console in Otter, so hopefully my next post coming up will be an Otter example regarding the console.

Did you know that Otter supports tweening? Now you do! Tweening is one of the coolest things in the world in my opinion and it's one of the easiest ways to create sweet effects and animations in games.

(I don't know what's up with the end of this gif so whatever.)

Otter makes use of the Glide tweening library by Jacob Albano. It has a similar syntax to TweenLite from the AS3 days of using FlashPunk, and since Otter is based off of FlashPunk having a syntax similar to a flash tweening library makes a lot of sense to me.

Check out the full source code of this example on the Otter example page!

I've been making some good progress on my latest prototype over the past few days. I got a quick GUI system working in the game but then quickly realized that my approach was pretty bad. After reading up on some articles written about making simple lightweight GUI stuff for video games I scrapped almost all the code and rewrote it.

My first approach was just having each GUI Entity operate independently and that worked for a bunch of simple cases such as a single drag and drop item, or a button that does something when it's pressed. However doing things beyond that, such as multiselect, and having different GUI elements pass info along to one another, requires a different approach.

The approach I settled on for now is something I've done briefly before with a quick prototype a few months ago. I'm now electing to use a single "controller" class as the base of the GUI system. The controller has a list of all the GUI elements it's in charge of, and almost all of the logic for the system is handled inside the controller.

A controller has a list of child elements that it controls, and each element can also have even more child elements added to it. The controller is the only element that receives input from the game, and anything resulting from that input is passed along to the appropriate element on the list of children.

I still have a little ways to go on a few things. I want to be able to get modal elements working so that I can do things like message boxes that have to be cleared before continuing and interruptions when important things happen. There are still a few bugs to sort out with clicking through elements and dragging stuff around, but so far I feel like my progress has been pretty great and I might have something playable way sooner than I thought!

Sometimes when making a video game you can end up with some pretty complicated classes. One way to try to counter act the giant behemoth of code that can easily creep up is to separate some of the functionality into components. In Otter an Entity can have a list of components to run each update.

It can be super useful to put things like movement patterns, weapon systems, health systems, and other stuff into different components and just compose Entities using these various components.

This example goes into detail on how to use components in an Otter project. The example is nearly a game with a player character that can move around and shoot down targets. The example uses components for the movement system that the player uses, keeping track of health, input from the keyboard, using a weapon, and moving bullets fired from the weapon.

This is a pretty complex example compared to the others so far, but I hope it can shed some light on one of the possible ways to organize a bunch of code!