Platform Decisions

22 October 2019

OK. A repository exists, a blog is set up, and my git environment is working well. Now to start coding. But wait, which language shall I use? :/

Platform Decisions

For me, this is not such a natural choice. I spent a lot of years developing UI’s in C# before switching to C++ for mostly backend work. Ultimately I find C++ to be by far the more pleasant language to work in, but the lack of a single standard UI toolkit is counting against it in this project. Since I want to limit the number of things I’m trying to learn at once, it seems that C# is probably the way to go here, although that somewhat limits me to a Windows experience. Oh well, this is only a learning project, so limited deployability isn’t going to hold me back.

However, having selected C#, I’m still left with a choice of UI frameworks. I’ve done lots of WinForms and some WPF. In terms of sheer experience, I should go with WinForms. That said I’m also aware how much of a pain in the ass customising WinForms controls is and how much more smoothly a primary Wpf control can be made to look better. So at the risk of biting off a bit more than I can chew I’ve decided to give this a whirl in Wpf.

Choosing a Framework

Naturally, any game is more than just an action experience. There are things like Options, Saving/Loading, Credits and ScoreBoards to consider. In my head, I’m thinking about these as ‘Menu Screens’, and that these can be built using standard Wpf controls with a bit of theming applied.

As opposed to the main gameplay itself which should be fullscreen (or at least window filling) action and is unlikely to be made of up standard controls. The game area is the biggest unknown for me in Wpf, using WinForms it would have been merely a double-buffered custom control. With Wpf, the most apparent solution looks like a Canvas, but I’m leary of the performance capabilities of it. On the other hand, being able to use vector graphics might give a nice feel to it.

A quick scan around the Net suggests that a viable approach might to be to use DrawingVisuals as a lightweight way of getting stuff on the screen. Since I’ll probably be taking full control of the input, and therefore won’t need all the built-in Wpf complex handling, its limitations don’t sound too bad.

The only way to know for sure will be to build something and see how we get on.

Wpf App

I don’t know about you, but I’m no fan of the App.xaml approach to starting applications. Maybe I’m a bit old school, but I like to find a Program.cs with a clear entry point. So after creating the project that is the first thing I plan to change.

Most Basic Start

It doesn’t look like menus, buttons, etc. won’t be a problem with Wpf, but the game area itself is a significant unknown. Therefore, I plan to start by getting some kind of game area up and running.

I think the first most minimal thing I can build will be to draw a blob in the middle of the screen. And then expand that to look something like a rocket.

So, onward to code.