Time for some thoughts!

I have this game engine called Otter. It's heavily inspired and influenced by Flashpunk which I used for a number of years for a number of games including Offspring Fling.

I really like using Otter, and it was a lot of fun developing it, but lately I'm not feeling super sure if I can depend on it for the future. Otter really fits my coding style, and I've learned a lot making it, and I feel like it can always be improved (often times I have to resist the urge to start a new version of it that would improve on the core of it now that I know way more about .net, SFML, and openGL,) but I'm not sure how worth it is to keep using.

Unity is gobbling up a lot of game devs these days. Everyone and their grandma is using Unity to develop games. I don't have anything against Unity, but I have a hard time leaving my fate to a tool that is essentially a black box. I have a lot of friends that use it, and sometimes their stories about core Unity bugs disrupting their entire project can give me nightmares. Being at the mercy of a crazy Unity bug that wont be addressed for a few versions seems incredibly stressful... so I'm not totally sold on jumping ship to the Unity train.

I think the core hesitation I have with Otter lately is its dependency on SFML.Net. SFML has had a lot advancements lately thanks to the recently formed core SFML team, but I think SFML.Net and the C bindings are going to be left by the wayside as they start making progress on the core C++ version. There's just not enough people using SFML.Net, and often times I feel very isolated when trying to solve weird issues since the community is so tiny.

So maybe one of my options is to go to XNA/Monogame, but that isn't a perfect scenario either. Unity's main draw to me right now is the whole built in editor and inspector thing, and XNA/Monogame doesn't leave me in any better of a position than SFML in that regard. I don't have any editors for Otter, and once I step outside the realm of pixel art there's absolutely zero good solutions out there for editing content (for something like a platformer, for example.) There are a couple of spun up editor projects out there, but they are barely useable and have way too many bugs for any project outside of the scope of a 48 hour game jam.

Another option is Haxe, but honestly I'd do anything to stick with the world of .net and C# for as long as possible. I love C# and it's amazing, and I don't want to go back to anything that resembles actionscript.

I'm just sort of using this blog post to think outloud really. I really like Unity's editor aspect lately, but their 2d support still seems really dumb... and relying on a third party tool is something that I'd rather not do (I've been scarred though my years of using Klik & Play and all of it's successors.) Maybe I can port Otter to XNA/Monogame and that would be a good solution, but I'm not exactly looking forward to spending a month or so doing that. What I was really hoping for was for someone to join up with me for Otter development but unfortunately I don't think Otter is cool enough for that to happen. Really what I probably need is more info about how to get started using Otter. The little info I've put out there has now become outdated, so starting up with Otter can be pretty though for the average person.

All in all I think I'm going to keep using Otter for the time being, and I think the most realistic scenario is a port of the internals to something else. The XNA/Monogame route seems very tempting, but I know there are a number of problems with that that need to be solved beforehand. There were some specific reasons I went with SFML over XNA and I'm not sure how I'm going to get around some of the issues there. Maybe I can cut out SFML and just go straight into openGL or something... but then I know things like text rendering is going to be an even bigger nightmare than it already is now.

There's never a perfect solution for this kinda thing! If only I had a little bit better of a programmer brain I could make Otter into the perfect portable engine for different platforms, and I'd make a sweet editor to go along with it... oh well! Really I have no idea what to do right now, but that's par for the course. Guess I'll just keeping working on Sky Sisters and a couple of other projects I have spun up and see what happens.

I finally merged in all of my pending changes into the main branch of Otter! If you've been using the dev branch for the past few months not much has changed, but things finally stabilized enough to the point where I felt comfortable updating the main branch.

Afterwards I've done some minor adjustments and fixes:

* Using Game.EnableAltF4 now checks for either Alt key on the keyboard.

* The RandomElement() function in NaturalLanguage now uses Otter's Rand class to ensure consistency if you're using a preset random seed.

* Added Snake.AddAllVertebraeToScene()

* Axis and Button keys, joysticks, mousebuttons, etc, are now public accessible.

* Renamed Button.AddButton to AddJoyButton.

* Axis and Buttons can now add keys, buttons, etc, from other Axes and Buttons. Useful if you want to copy a button or axis.

* GridCounter now has MoveUp(), MoveDown(), MoveLeft(), and MoveRight()

Slowly and surely moving towards a 1.0 version!

In case you didn't know I have a free to use open source 2d game making framework named Otter. It's built on top of SFML.NET and uses C#. Here are some recent changes available in the dev branch!

* Color.AddCustom() and Color.Custom() added. This is a handy way to define custom colors by Enum and later retrieve them. I didn't like making my own static colors class for each project to keep track of my custom colors, so I added some functionality to the Color class.

* BitmapFonts have been almost finalized. They should be usable now for the most part and you should be able to import fonts from a handful of different editors. You can check out what editors are supported in the class itself with the Enum BitmapDataType.

* RichText has been updated and fixed once again. I guess I've been doing kerning wrong all this time and I think I finally have it corrected. RichTextCharacters also have some new values to play with like their X and Y offset positions, scale and rotation and more.

* Added Enum.HasFlag() as an extension method. This is a handy way to check if an Enum with a [Flags] attribute contains a specific flag. I guess you can use this if you're not comfortable looking at the bitwise operators or whatever they're called (I sure am not!)

* Shader.AddParameter() is now available to register your shader parameters as an Enum. Now you can just define it once and use the Enum everywhere which should reduce pesky typos when working with shaders.

* StateMachine has been scrapped and StateMachine<> has been upgraded a little bit. It's now possible to use a stack of States in a StateMachine<> and it will run the top most state. Also now if you call ChangeState (or if you push and/or pop states) during a StateMachine's update function the StateMachine will wait until the update has finished before applying the state change!

* Fixed a typo in the Shader class whoops (SetParamter?)

* Surfaces now have their Display() function exposed. This is crucial in using a Surface that doesn't render at all, like if you're using a Surface as input to a Shader. Without calling Display() the texture will be upside down.

* Updated Collider and Entity and Graphics with more stuff like SetPosition(), SetOrigin(), and other handy stuff.

* Surface.SaveToFile() will now automatically save with a timestamp file name as a png if you don't specify an output file path. Handy for taking a bunch of screenshots during a session.

* NineSlice has some new utility functions like SetBorderPadding. I found it easier to define the areas of a NineSlice object in this way instead of trying to figure out what the bounds of the rectangle inside the texture was.

* RichText now will always round its origin since setting the origin to a 0.5f value results in blurry text!

* Fixed a bad bug in the PolygonCollider which resulted in the collider not using the transformed polygon for collision checks.

* Added 3D Audio support thanks to Fruckert.

* Lots of little bug fixes and tuning changes here and there.

Once again this is all available on the dev branch. I'll be pushing a whole bunch of changes to main branch as soon as I can sit down and write some documentation up for the new and changed stuff.

Things are moving along for Otter, my SFML.Net based game making framework!

I pushed a lot of changes this week that is bringing it closer to the big version 1.0. I overhauled a lot of the code in the Graphics classes, fixed some bugs, and updated all of the documentation for mostly everything. I also went through and cleaned up a lot of the code and organized it into nifty regions.

Right now my plan is to just keep testing things for awhile yet to make sure there's no crazy show-stopping bugs before I publicly announce to the world that it's officially version 1.0. Some of my recent changes have not been tested that thoroughly yet, and there have been a few bug reports popping up that I've been fixing up, so I can only imagine there are more bugs lurking in the shadows.

As far as sprite batching goes, I decided that I'm holding off on official sprite batching support until after version 1.0. There is some stuff set up in the back end of things to turn on sprite batching, but there are a handful of bugs that need to be resolved first and I don't think I'm going to be able to get them squished quickly enough. Aside from that, my performance tests seem to indicate that sprite batching isn't really that helpful anyway.

If you're using Otter and encounter any bugs, you can let me know on the forums or directly on the BitBucket issue tracker.

Sorry for the total lack of posts over the past week. I guess I have gone into a heads-down mode for the updates I've been working on for Otter.

About a week and a half ago I went in and tore apart a lot of the code for Graphics and the sub classes. This resulted in rendering being totally messed up for awhile as I tried to figure out a good way to batch sprites using common SFML RenderStates.

So far this seems like a fruitless effort, as even when I have basic sprite batching working the performance remains exactly the same. If anything right now the bottleneck for rendering just seems to be iterating through all of the entities to render, so for now I'm going to hold off on officially supporting sprite batching until version 1.1 or higher.

I did make a pretty big breakthrough on Sunday and finished the last of the collision detection functions. The last ones on the list were all using the PixelCollider class. Some of the functions could be optimized better, but for now this will work for a version 1.0 release sometime in the near future. I don't imagine seeing the PixelCollider class being used that much anyway.

For the time being I'm going through every single class now and organizing it and documenting it (if I haven't done so already) Soon Otter will be a very neat organized package of code all set up with fancy regions and comments. Then that will bring me to the beta of (hopefully) version 1.0. If nothing goes horribly wrong, I would image Otter will be at 1.0 status in a few weeks!

It's not as exciting as working on an actual game, but there were some things lurking in the shadows of Otter that I needed to address before they came back and bit me later. Thanks to everyone that has been finding bugs and suggesting things for Otter! It's pretty awesome and terrifying to know that people out there are using the engine.

Over the past week I've finally pushed some updates to Otter after managing to rip out the Spine animation stuff. It turns out that in order to use the Spine runtime you need a purchased copy of Spine, meaning that if I include the Spine code in Otter everyone that uses Otter would need a copy of Spine... not ideal. (I wish Spine wouldn't license their code like this.)

So now the Spine runtime for Otter lives in a separate repository. It can be used along with Otter if you import it into your solution also using Otter. After you import it you need to give it a reference to Otter (also in your solution) and then give your game project a reference to OtterSpine. Then you should be ready to roll with SpineAnimation.cs.

Other updates to otter include:

* Renamed GetClass to GetEntities on Scene
* Add Vertices graphics type
* Added Color.Mix()
* Corrected issue between game angle and graphics angles
* Fixed issue with BoxCollider constructor
* Fixed some collision bugs
* Added shortcut of Left-Alt in Debugger to hide debugger (useful for screenshots)
* Minor updates to Particle
* Added LerpColor to Util
* Slight changes to Vector2

If there's any bugs or horrific things broken then let me know in the Otter forums!