I just posted one more quick example for using Otter!

The Input and Basic Interaction example deals with using the Input class to check for keyboard keys being pressed and held down, and responding to that by moving an Entity around the screen. This is the first example to really get into potential video game looking code.

Also as a side note I started an Otter slack team that is open invite to anyone that wants to chat in real time with other Otter developers. Hopefully we can get a solid crew of folks in there to push the framework foward.

Making use of Couch CMS I've finally gotten around to making an example page for Otter!

The first three examples are a very basic introduction to setting up Otter and using it to start putting stuff on the screen. I plan on adding examples every so often since the videos I made a long time ago are now sort of outdated. Otter continues to grow and evolve over time so it's tough to keep a solid set of examples to go with it. For example the controller class has gone through some changes over the past year which makes a lot of the tutorials written for it outdated. Hopefully I can keep examples up to date though using Couch.

Just a little bit about CouchCMS too: this is one of the coolest things I've used in my web dev days. I really wish I had tried it earlier because I think it's going to forever replace my need to write my own CMS every time I make a new site for myself. It really seems to cover everything and it feels way easier to customize than something like Wordpress or Tumblr. Sure it might not be as powerful as those right off the bat, but I think Couch really fits my style more. It also comes with an awesome file uploader and browser which makes image and file uploading a breeze. It makes everything a breeze! You should definitely check it out if you do web work of any kind.

Some quick Otter updates!

* OnAdded() timing has been changed for Entities. When an Entity is added to a Scene the OnAdded() method is now called after the Entity has updated its component lists. This is so that a component can register with the Entity's OnAdd method before the Entity is added to the Scene.

* Added GetTopEntity() and GetBottomEntity(). These methods allow you to pass in a bunch of Entities and find the top most and bottom most entity in the rendering.

* Added GetComponent() shortcut methods to Component.

* Added CollideEntities<T> method that will return a list of a specific type of Entity.

* Possible graphics changes. I want to explore the possibility of reworking the rendering system to allow for multiple transformations to be applied to graphics. This would possibly allow easier parent to child relationship transformations and more. Mostly because I noticed when working on games that I want to have multiple scales, rotations, and translations applied to graphics at times, and it would be nice if Otter had built in support for it.

That's all for now!

I swear I'm finishing Super Sky Sisters... I had a friend try a copy of it for his multiplayer game night and apparently it was a big hit there, so I'm feeling pretty good about it! It's extremely tough to test it since I'm playing it by myself most of the time.

In the mean time between all of the other stuff I'm working on I've been playing around with getting a drag and drop system working in Otter.

I have an idea for a thing that involves dice... and I think a big part of it might actually having the dice be "physical" objects. I have a little prototype going, but that version doesn't have dice rolling and instead just buttons that show you what you rolled, but that doesn't seem that fun compared to actually seeing the dice bounce around on the screen. I don't know if this idea will work at all, but for now I'm having fun getting some of this drag and drop stuff working. I might be able to extend the system I made into something generic enough for other uses, like maybe some sort of basic editor for Otter games.

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.

One of the last things on my to do list (before animations) for Super Sky Sisters was optimizing the crazy results screen that players will see after a session. This is a screen that shows a graph of your orb's health, each player's health, and your score over time. On top of that you also see the timeline of the game events that the players had to endure.

My first attempt at this was pretty crude but I did whatever I had to do to get it done. I basically just have some dictionaries with timestamps as keys. My first attempt at this screen would just render out the graph by iterating through all of the keys of each dictionary and plot the value using a draw line method in Otter. This worked fine except the players can also zoom and pan around the graph. Needless to say on long play sessions this lagged horribly since whenever the graph moved or zoomed it had to redraw the entire thing based on the new zoom and pan values. At least it only rendered the graph when it needed to be updated though, right?

My first attempt at fixing this was moving the graph rendering to a coroutine. The coroutine would be fired off when the graph needed an update, so you could see the graph redrawing itself without the game itself slowing to a crawl. So while the framerate maintained itself at 60, the graph updating was still very slow. I tried making two different surfaces for the graph to switch to, and render to one behind the scenes and swap it out when it was done. Some kinda fancy double buffering or whatever, but the fact remained that the graph rendering was just way too slow for this.

My solution was to render different zoom levels of the graph up front at the start of the scene. This causes a small hiccup at the scene transition, but after that everything is as smooth as butter, or something like that. There are 4 different graphs that are rendered, and when the players zoom in and out the graphs are being scaled up and down. When the scale reaches a certain threshold the graph will be switched out for the higher zoom level one. The final result is that you can zoom and pan freely and there's no lag at all. I guess this is sort of like mipmapping? Maybe? I don't know, but it works.