For the last few years I have been writing code in C#. I think C# and .net are great tools to write software. I find that C# is exactly where I need it to be, I can do low level when I need to work with pretty high level abstraction (ish). However the world (unfortunately) doesn’t do what I want and it feels like the momentum .net had is certainty fading.
These are some reasons why I think this is happening (not all related directly to programing)
- Inherent hatred for Microsoft and anything it does, even if it is good. I think is pretty sad since I see this attitude from people that should be objective from a technical standpoint, licensing can’t always be an issue.
- Windows 8 and WinRT with it’s confusing .net support. It doesn’t help when it comes to .net developers either. It seems like their intention was to bring in the “cool kids(?)” but with that they alienated the people that supported them.
- All the windows phones, and particularly the WP7 fail (no update path for win 8). It is fail from a commercial standpoint and from developer support, how can you spend any significant amount of time with a platform that you don’t know is going to be there in a year or if there is any support for it.
- Half arsed open sourcing, by this I mean, you can read the code but no thanks, we don’t take pull requests .Also, the very common not invented here that MS keeps doing (Monorail vs MVC, Nunit vs MStest, NHibernate vs EF, and many others ).
- Tablets and the fact that MS doesn’t have a significant share on any of this, so for many the digital experience is via apple or android.
- For me, killing XNA. A great SDK, suddenly abandoned. Why? no one ever gave a reason I can remember (can you?)
- XBOX vnext rumoured online only putting a nail on the XBOX coffin.
What could save it (maybe)
- Strangely, Xamarin because of their amazing mobile tools based on mono . Unity helps too, but I do wonder about what they have in mind for the future
Filed under: .net | 17 Comments
Tags: .net, android, xamarin
Mono for android or Xamarin.Android little tips:
- If you turn on GPU emulation, sometimes GPU emulation doesn’t actually start, it downgrades to software rendering, this makes the emulator slower and it doesn’t actually uses OpenGL(if you are using monogame, this means your game would probably not work).
- If you are looking for a grid like component that stretches with a fix number of grids, I couldn’t find one. Had to write my own and the code is ugly .
- You can use ScreenOrientation = ScreenOrientation.Portrait as an attribute in your activity and ConfigurationChanges = ConfigChanges.Orientation is also an activity attribute that prevents the activity from restarting when orientation changes.
Xamarin just announced support for C# 5 features in the mobiles suites, very exciting news… more details here.
Tomorrow, post about monogame stuff.
Filed under: mobile dev, mono for android, UI | 2 Comments
Tags: mono for android, xamarin for android
I did a few presentations about Monogame in Gaming Reimagined (at what used to be the Landsdowne Road Stadium) and in Games Fleadh, if you were there I would really appreciate your feedback (good and bad, please just leave a comment here).
The slides are available here. I will make the code available soon and update this post. There is a video for it here
During both events there was some pretty cool talks. About both the industry and making games.
During Games Fleadh I Particularly enjoyed listening to Steve Ewart from Havok showcase his many cool demos and the guys from DemonWare talk about their experiences in their company and it some of the big games studios.
Kudos to the organizers of both events and Congratulations to all the award winners of Games Fleadh awards: bitsmith got Best Games and an awesome tank.
Pic from Bryan Duggan (https://www.facebook.com/media/set/?set=a.423888310976750.1073741831.113468182018766&type=1)
Filed under: talk | Leave a Comment
Tags: games fleadh, gaming reimagined, monogame, presentation
A few weeks ago I bit the bullet and bought Mono for Android. I also decided to update to all devices to Ice Cream Sandwich as the UI is just so much better. Should have done that ages ago, but I was just afraid Kies would brick my phone again.
Anyway, the new features that I m sure anyone interested in android development already know about: Services, fragments, new UI. Cool stuff, it also meant a lot to learn .
Some things that you might want to try out if you are starting this out:
- Preferably have a device or two , the emulator is slow. The x86 emulator is an interesting option, it didn’t work for me initially but then I tried a few different virtual devices and then you could really see the benefits… way faster. Still is good to deploy to the phone often enough.
- Since android 3.0 there is a new way to do drag drop that works as a state machine. More info in the excellent Jeremie Laval’s blog. Check the other posts, they are really cool too.
- Fragments are trickier to deal with that I thought. Pretty sure I’m doing something wrong (as all times you start learning something new) but I wanted to replace a fragment (with UI elements on it) with another fragment (also with UI elements on it) however if the first fragment was placed there with the layout xml and the second one programmatically, It just didn’t work. It did work when both where placed programmatically. Any hints on this would be great.
- To use the Holo Theme across your app, simply add this snipet to your manifest to your manifest. More on styles here.
Filed under: android, c#, mono for android | 1 Comment
Tags: emulator on x86, Ice Cream sandwich, mono for android, xamarin for andoird
As you might or might not know, I am one of the founders of BatCat Games, the important word about that sentence is games. The fact that we make games put a series of differences into our production that doesn’t generally affect non game software development cycles.
For a start art and animation are key in a game, so are visual effects. In build server terms, that generally means two things: It requires space(for content building) and quite probably a graphics card (for the visual effects). Our ideal solution would be to have a virtual machine per supported platform , but we found that none of the virtualization software (VirtualBox, VMWare, etc) virtualizes the graphics card reliably (if you found a way, please let me know) so we are running our server on a non virtual machine.
The objective is to build the whole game, tools, etc. at each commit. There are a series of tools available in the market at the moment that allows you to do just that. For example: TeamCity, Jenkins, CruiseControl, Hudson.. etc. There is a good comparison matrix here.
We chose TeamCity, mostly because we know it, we find it easy to use and it is free.
Our code is based around XNA and monoGame (recently on version 3).
We have many projects: a game and engine project, a tool, a library and the content builder. This means we have a diverse project output. For example, in the case of the content, we are not interested in the actual build results (yet) however we are interested in knowing that it did build, and to report errors if it didn’t.
The game and engine project reside in one solution and have many unit tests. We need the build server to not only build the project and after that run the unit and integration tests. Initially I set this up using psake (a tool that does the build with PowerShell) this is a great solution if you want to have a one click build, so I gave it a try, I found that setting up the tests assemblies was a manual process and that to get psake to talk to TeamCity nicely it would take more time that I had. So I tried running the build directly from TeamCity, and it was easier and I didn’t loose to much flexibility so, I had to go for that solution (however is a decision I will revisit shortly).
Setting up each of the steps took me approximately 10~20 minutes if done this way. There are a few things that I want to improve on, however the end result is that in a very short time I can have a new project building and reporting.
Some of the disadvantages of the process as it is are:
- If I want to change the build type I need to do it manually, in this case, the target test assemblies will need to be updated
- At the moment we are using dropbox as our way to distribute the builds, it is a process some members of our team really like because they just get the new binaries and they can choose when to update (so that there is no friction). I would prefer if the tools would just auto-update, but this is working for the moment.
As you can see the server setup is not perfect, there is loads to improve on, but setting this up from early on has proven very helpful. It allows us to have a one click build and a functional way to deliver our tools and product to the people in our team.
Filed under: c#, gamedev, Uncategorized, unit-testing, xna | Leave a Comment
Tags: build server, gamedev, monogame, teamcity, xna
I’ve been playing with mono for android the last few days. I have also tried it about 2 years ago. It was a good tool then, and it got much much better.
Getting started is pretty simple, you download the installer, install. It will install all prerequisites for you on your machine. Allegedly this failed the first time but worked the second time, I had a log to look at to give me some idea of the problem.
Once I got set up I started reading the documentation. Not only it was in place, but also, it was written to the right level (i.e. assumes you are a smart individual), I then moved on to pricing, 400 usd ouch, but I will come back to this. If you don’t activate the product you can test on the emulator. It gives you some sort of idea of what the experience is like. The emulator is slow, and brittle, but that is something we should talk to Google about.
At this point I started going over some tutorials, using both monodevelop and VS just for the fun of it. The main thing I miss from VS when I’m in monodevelop is resharper . I had no real troubles getting on with creating a little app (a games reviews collector) .
I went ahead and bought the license, activated and pushed to the device and it is much faster than using the emulator.
One gotcha was that I wanted to write files and then be able to access them via USB, I kept getting a file permission error, I needed to set up the permission on the manifest file, it wasn’t obvious to me, but that is ok. All the information I needed was here.
Deployment to other devices is also pretty simple, you build the app on release mode and use the *-Signed.apk, there are other ways to deploy here.
Mostly the reason for this blog post is that I was a bit surprised with how good an experience it was (so far) .
Next I will be working with some eventually connected storage, I heard good things about Parse.
I gave myself a pomodoro to finish this post, so I’ll have to talk about pricing in tools some other time .
Till the next time
Filed under: c#, mono for android | 2 Comments
Tags: "mono for android" "permissions" "android"
So, after the last post, where I introduced Directory truncator, I present you some extra work I have just committed. My plans for it from the previous post where
- Logging and or console output so you know what happened, I couldn’t so far decide on what is the best approach or if I want to choose one, so I ll do that tomorrow .
- On error, proceed to the next file/folder.
- Have a StartsWith parameter(on both methods), so that it only deletes files or directory that start with
- Turn it into a service
So, this is what happened,
- After thinking a little bit about it, I just went for NLog, it does what I need it to do for the moment. Logs need no test, so I added a few log messages, there is probably some log messages missing.
- For this one, I ended up making a decision I’m still mulling over. I needed to test that if there is an error on file delete, the process will log and keep going. How to do that? well, I created a thin wrapper around the file system, as far as I could see it, there was no other way to simulate the scenario of you have two files to delete and one of them is deleted before we get to it. I have yet to do this for TruncateByDirectory.
This is all for today, and since this is probably the last post of the year. Merry New Year!!!
Filed under: Uncategorized | Leave a Comment