About this blog
A Hobby Programmer's Rants
Entries in this blog
Progress! I managed to get remote debugging working on the tablet and found the cause of the crash bug at once:
Interestingly during initialisation of the input wrapper I registered for gyro changing events before the basic input setup was complete. And, lo and behold, I received an event before the input init completed. Null pointer, bam! instant crash. Weirdly, this never happened on Windows phone. Seems UWP has some subtle differences between platforms.
So now that crash cause is history and the next release is up.
Now a bit more about the framework I've setup. I've tried two or three times to set up a simple UWP sample app and include the main game code in that. The sample app was setup differently (but I think I didn't do it on purpose, rather the SP of Visual Studio 2015 changed to 3 in between)
With the first two tries the sample app had some XAML stuff (which I don't really like), and I never got the swap chain to work properly. With the 3d try there was no XAML document at all, and this time the swap chain worked (after a few attempts with different parameters)
There's quite a few preconditions and certain parameter combinations that are mandatory. Luckily the runtime spits out a pretty descriptive error message what was actually expected.
Using a generic framework for both Win32 and UWP proves a tad tricky, since UWP wants a managed main method. With a bit of pseudo global magic (I've got one environment instance where several services like renderer, logger, sound and also the main application register) I was able to refactor the main function out.
So for HitBlock Deluxe I have a solution with a shared project containing the actual game logic, and a UWP and Win32 application project; both having the shared project as dependency.
Current gotchas: Since UWP requires assets to be embedded, and absolutely does not want assets from outside the project folder, I share the assets from the UWP project. Ugly, but works.
And there's a new crash, unfortunately without any crash info. Oh well....
Three weeks have passed, a few new people have installed the game. I had the chance to deploy the game also to juniors x86 tablet, where it currently crashes. The tablet does have a gyro sensor, which I thought worked fine when using it on Windows Phone, but apparently the code isn't crash proof enough.
I've been looking mostly for crashes now, and a handful (well, two in the last 3 days) did appear. The crash info is all over the place. Some have a really great stack trace, other nothing. Some seem to be in between. I reckon this is heavily affected by fiddling with telemetry settings.
What I'm also missing on a first glance is the configuration of the crashed app. Since the compile builds executables for x86, x64 and ARM it'd be nice to know which of these were the cause. What's always there is the name, IP, Windows build version and device type of the device that was running the game.
While the stack traces sometimes help they are only that. You don't get a full dump or local watch info. So you can get lucky and the location of the problem is clear, or you're out of luck. In these last two crashes the stack traces hints on a null pointer on a method that is used throughout the game (GUI displaying a texture section). I suspect that it happens during startup and the code path went inside a function when it wasn't ready. In these cases I can only add a safety check and cleanly jump out of the function. Build, upload, re-certify and next try in 1 to 3 days.
Currently I'm struggling getting remote debugging done on the tablet. I can deploy the app via enabled web portal, but the remote debugger is not properly recognized by Visual Studio. I was hoping for USB debugging as that works nicely on the phone, but had no luck with it.
Well, here's to the next version hoping to get those crashes fixed!
A few days have passed since I uploaded the game. I did no advertising whatsoever, but the two blog entries I had here.
So I've been watching the dashboard closely, to see if somebody actually looked at and installed the game. And a handful (literally) did Joy!
I even got a feedback which can all be conveniently inspected in the dashboard. Unfortunately I've also got crash reports. In one case I received a stack trace. I have a hunch what might be the cause (I've called QueryInterface without checking the HRESULT. I should've known better!)
Currently I'm on vacation and have only access to a Windows 7 laptop. And unfortunately on this Visual Studio 2015 prefers to crash when I try to create new packages. I'm pretty happy I can actually compile though; and also the manual package creation via command line does work fine. Go figure. Downside, I obviously can't test or debug the compiled game at all. So I have to wait before uploading a fix to the store.
In the meantime I got access to a Windows mobile phone (which is actually pretty good IMHO). Just for kicks I deployed the game and it worked perfectly. If you disregard no possible keyboard entry or back button support. Over the last few days I've made a few adjustments to the code so now back button works, and overlay touch controls are also available (for phone only). I have also tried to add tilt support (both via Gyro and OrientationSensor - the first one is not supported by that phone, and the latter seems to be lagging quite a bit). Once I manage to get keyboard support I also have to try to make the game GUI somewhat more phone friendly (a tree control isn't really all that fit for big fingers).
Overall I'm pretty satisfied as how well the same app performs as pure Win32, as UWP app on desktop and on phone.
Let's get back to the creating an app package and uploading part, as that is where I experienced some difficulties.
I had an locally working Universal Windows Platform game, a Microsoft account and Visual Studio Community 2015.
So per instructions you'd right click on your app in Solution Explorer, choose "Store->Create App Packages". Sounds easy, but didn't work. A dialog came up and showed an error about not being able to connect to my account and Visual Studio actually hung.
I had no idea why that part wouldn't work. Restarted Visual Studio, updated the SDK, rebooted, nothing changed. Than, after reading that dialog more focused, it dawned to me. A plain Microsoft account does not suffice, you need an actual developer account. This is two different things!
So off on developer.microsoft.com I created an account, paid the required license fee (something akin to 9 Euros) and voila, the dialog would suddenly work!
From here on I created the App Packages, which required a few more settings to enter. Here's another stumbling block I encountered: You need to provide a few logos/badges/icons. All in a gazillion formats, scaled 100% and 200%. Here I wish you could provide one image and have the other formats auto-created. From there you could still polish up or replace the uglier ones. If you ever want to modify the settings of your app either double click "Package.appxmanifest" or via menu Project->Store->Edit App Manifest"
Finally my app packages compiled successfully (per default you'll have x86, x64 and ARM). Then came the Application Verifier...
The Application verifier will run your app several times, check your icons/badges and after a few minutes return a result of either "failed" or "passed". The link behind that will show you the details why something failed. The listed errors are also linked to a web site explaining the messages in detail.
For example one of my failures was explained as "The first pixel of the icon is not 0xffffffff or some other value)". What that message actually means: Those particular icons are supposed to be two colors only. You'd expect that to be shown when you select that image in the app properties.
Next time more details about the uploading part.
As I've just managed to upload my first Windows Store release of a previous play Win32 game I thought why not document my way there.
The game itself, HitBlock Deluxe has grown over the years and I think it's quite a neat game. Luckily I a few years ago I had the idea to allow user created stages to be uploaded and shared. Those user shared levels are now over 1000 single stages!
As I've checked out the Universal Windows Platform (UWP) I noticed it should be doable to port the game. The code is C++ with interfaces for various DirectX objects. So this led me to the decision, should be doable.
I set up a new blank project and began adding the game files. First thing to notice: Actually quite a lof of the Win32 ecosystem is there, but also a few APIs are missing. In most cases changing calls to their xxxEx counterpart solved the problem. One of the bigger problems was CreateThread not being available. Fortunately a async .NET API was available, which albeit horribly clunky with CLR, worked after introducing a few ugly static wrappers to interface with pure C++ code.
So in the end almost the same code runs on C++/Win32 and C++/CLR/UWP. Yay!
More to come about the store upload...
If you want to take a peek, the game is available in the store as HitBlock Deluxe.
I still have no idea if the game generally works for everyone, so if you try and it fails somehow, please let me know!
And that's my final entry as for today. Tomorrow I'm on a 11 hour flight and will probably be completely exhausted.
Not much has changed, two more bug fixes, two more stages and a gold counter as sort of score. I'm pretty pleased with how the game came out, albeit designing decent stages is really really taking a long time. This idea is something I might come back to. Neat things to add: An automated camera (or free look), non-quad tiles (slanted roofs for example), a background story.
I've updated the backup link with the lastest version ( http://www.georg-rottensteiner.de/files/WoA5_Endurion_AssassinsrUs.zip ). Also re-submitted on the WoA page as well (but didn't test the upload)
Great entries y'all from what I can see, can't wait to test them properly! Have fun!
Had a good day, got more done than intended. I've got some early feedback (thanks dmatter!), which led me to fix some bugs. I added the missing jump feature (wall to wall jump) and fixed a few more movement bugs (climbing into walls, etc.)
Now there's three more stages (one a tutorial only) and I've reuploaded the current version on the WoA site plus on my backup. Careful, the backup link has changed! http://www.georg-rottensteiner.de/files/WoA5_Endurion_AssassinsrUs.zip
Looks like I'll also be able to churn out a few more stages (which as I've seen with one of the bigger stages can be quite a task)
Phew. Late night debugging showed that the ray casting code I used for line of sight was hilariously broken since the first usage years ago for straight vertical or horizontal lines. Good fun to debug
Anyhow, line of sight now seems to do what I want. I also managed to get the complete, fail and total win conditions in and get the menu stuff out of may way. All in all I have a short game of five stages that could well be a final entry. Of course I do hope to spend a bit time on more and bigger stages!
The game has thusly been dubbed Assassins'r'Us.
To be safe I uploaded a current preview version with the five stages I have. The game is mostly feature complete (but one feature I'd love to add) and can properly be played. In case I don't have any more time this would be my final entry. The submission is over at https://neonlightgames.com/woa/Submissions
A safety backup is also at www.georg-rottensteiner.de/files/WoA5_Endurion_AssassinsrUs.zip
Unfortunately almost the whole day was unexpectedly occupied with anything but working on the entry. I'm slightly peeved as I was planning with this day and try to get my ideas in before time runs out.
Anyhow, I made leeway in adding the obnoxious guards, that now follow a simple scripted path. Currently I'm trying to get a proper player-in-sight code up and running. First attempt with the good old ray casting, naively enhanced by a third dimension. The code compiles, so it's nearly working
I've yet to see it running, it's my milestone for this day.
For tomorrow it's getting the menu system and winning condition going. Never leave that to the last days, you'll never know what happens!
Here's a happy guard patrolling in the gardens:
Due to sporadic internet, if at all, here's basically a summary of the first two days.
I managed good headway with the engine and a quite nifty editor (thanks to my NIH syndrome sponsored GUI library). The used themes will be castles and assassination.
Infiltrate the castle and assassinate your targets without being seen. As a good assassin you can climb 3d block based castles to avoid footways; better than Lara And since you're there, why not bag a few valuable trinkets as well?
Since there's two days in this entry here's a second glimpse (showing a probable tutorial level inside the editor)
So now a week has gone by and the dust has settled.
I had quite a bit feedback, some good, some bad, but one thing stood out:
The spike collision. The collision box is too big.
And the worst? I knew it. I felt the same way, but for some reason I always thought it would work out. Well, it didn't :)
So far everything else was mostly fine. I had no crashes, no "doesn't work" or hangs or other glitches. Or people didn't tell me.
As stressed on day 6: Feedback is the most valuable thing you can get from a competition like this. I often use these small games to have new features tested. I didn't this time around though.
A similar competition that ends tomorrow had me testing my new DX11 renderer. That one didn't work for one player; this made me realize, I had different renderers (DX8, DX9, DX11), but no fallback routine that would try all renderers before giving up. It's now added, and lo and behold! My engine got a bit more stable.
All in all I'm pretty satisfied with my entry, although it looks retroish. I think the atmospheric idea worked out quite well, even if the game is not too much of a game.
So, when's the next Week of Awesome? ;)
And here's the final journal entry (final before the next).
The game is more or less finished!
A few last minute points:
* Having the editor worked out nicely as I could build the last two levels in the range of half an hour
* Having the annoying GUI stuff out of the way I could concentrate on getting the last few bits working better
* Having uploaded a preview version yielded me valuable feedback (thanks gals and guys!)
Another issue I can't stop harping on about: Feedback. Honest to earth feedback. Even if it hurts, read it. Don't take it personally, try to understand what your player actually means.
Anyhow, my game went pretty much in a different direction as intended, but overall seems to work out fine. I added a small intro text and a bit more help in the V1.1 version.
The final entry, Forbidden City, is here: http://www.georg-rottensteiner.de/files/ForbiddenCity.zip
Due to other real life events I'm out for today, so here's a hurried journal entry.
I added one more stage and made a preview. Having a preview possible was a good exercise as I discovered two first-time startup bugs.
I added a preliminary ending for the preview but I still need to figure out a good one for tomorrow. I have an idea, let's hope I can make it in.
Tomorrow I need to also add some more stages with hopefully differing gameplay. The gameplay options are currently not too diverse, so I'll try to get creative with the given options. Fortunately I have a few faint ideas that could be used...
Here's a link to the preview: http://www.georg-rottensteiner.de/webmisc/WoA4_Endurion_ForbiddenCity.zip
Finally it starts to feel like a game. It's not particularely challenging, but a little bit of puzzly goodness is hidden inside.
Anyhow, today I chose some music (incompetech.com has some really good stuff, provided you credit him properly)
So todays screenshot finally shows something different, my current credits :)
Tomorrow I'll see to put a test version up in the hopes a few people test^H^H^Hcheck it out and leave valuable feedback. The worst thing that could happen after the final upload: Crashes everywhere but on your own place.
Also, if 5 people say a specific event or sound effect is annoying, chances are high they are right. Listen!
Never forgot, credits where credits are due!
Somehow my screen shots all look alike :)
Added ways to die, change levels, a new device and finally ways to die.
As new graphical feature walls now bring an implicit shadow with them which makes them stand out more.
Also started on a graphic overhaul. Due to the time limit of 7 days you can actually have a second go on the graphics (unlike Ludum Dare). One thing common with restricted compos is, that you need to be even more careful about "I'll do that later". Chances are you won't.
Over the course of the next days I need to build a few challenging stages, currently the ruins feel rather bland.
What could this wondrous thing protected by spikes be?
Day 3 has passed and I couldn't do as much as I thought. Anyhow, I added the obligatory keys and doors.
The game play has somewhat changed as in you need to keep your lamp lit. Burning torches are your only safe spots. You can light unlit ones to keep advancing. Once your lamp is out and no light is nearby, the shadows are advancing towards you...
Also, especially neat, I'm going for some nice atmospheric feel of abandonment and dread. It's surprising how good a few step sounds plus distant background effects can work.
Looks like this game will require quite a few scripted events; I'm thinking about cheap ways to trigger events without creating a complex editor. I'll probably hard code them in.
Generally the code is currently surprising clean. Only today I started to add the one or other quick hack (like cheat keys).
I need to work on the graphic variety too, currently the ruins look too much alike. Could be because I've only got 10 different tiles currently.
Here's the player nearing an unlit torch beneath one just lit. What might be lurking in the darkness beyond?
Day 2 is coming to an end. Well, what did I achieve?
As promised touched up my naff lighting system. Now it allows for colored lights. The calculated color is stored in the map (per frame) so any objects can detect the light level.
The player can move about, gets blocked by walls and spreads a light with his lamp. There's a beginning of a game play element in an enemy, who likes to stay in the dark.
Quick boring story: Explorer explores ruins (Theme++). Ground collapsed beneath him and he falls in underground hallways. Armed with only his trusty oil lamp he has to find a way out.
Now the hard part: I have to make a game from that in a few days.
Added an option game state to set control mapping and window mode. This also has an implicit pause function.
Back to the dogfooding part, anecdote of the day:
In my first approach I had a resolution of 640 x 480. Having my trusted engine I feared nothing. Then I tried toggling full screen, and yay, instant bug. Seems that nowadays 640 x 480 is being phased out. Phased out hard as in the card doesn't enumerate the mode (no problem here) and simply fails to set 640 x 480 in full screen. Getting nervous I disabled the valid mode check and simply set 640 x 480. Interesting effect. It fails partially, the mouse cursor kept flickering back and forth. Seems my engine didn't anticipate that a mode couldn't be set.
Short thought attack: Should I use the time and get a proper fallback working or continue on the game?
Instant workaround: Set the game to 800 x 600, which works fine. Yippie Kay Yay.
Long term fix: Moved to the future (I'm management material after all! :) )
At least replacing all the parts where I had the resolution set as constants (will I ever learn?) was quite quick.
For the fun of it added a little message display to let the player utter a few things. This might become handy for a tutorial.
Welcome to day 1 of the Week of Awesome IV competition!
So far the themes are gameplayish Shadows and Evolution, and graphical Undead and Ruins.
First thought: Urgh. Second thought: Urgh.
But nevertheless, I enter, I make a game and maybe get out alive :)
Shadows is a theme that might work out with a quite similar theme from a Ludum Dare back in the days. Evolution, while sounding like a nifty idea, but graphically gives me no idea. I hope somebody does go for it, I'm curious.
That's shadows then. Undead and/or ruins both seem quite fitting, let's see what to make of it.
I spent most of the first day to get a tile system done. I added a custom lighting on top (only vertex based), which is really more or less a copy of the lighting I had in the Ludum Dare game. I intend to give it a decent overhaul though, but I need it to get the intended gameplay up and running as fast as possible.
I can't stress this enough: On a tight deadline, get the required feature running first. If it doesn't work out, you can still go for something else. If you add it last, you're hosed :)
Since I know myself I also added a quick and dirty mouse based editor in the game itself, so I can modify levels on a whim. The game will live and die by its level design, so better make it as comfortable as possible.
Here's a shot of the current state. Showing the player, carrying a lamp.
[sub]Corrected the description of the themes to avoid confusion[/sub]
The competition is over, you got judged, what now?
For one, a main goal at any competition is to get feedback. Especially critics on the things that were not good. A competition like this usually nets you at least a few people playing your game and they will tell you what's good, what's bad, what's missing, etc. in a constructive way.
It's easy releasing a game out there, but do you get valuable feedback beyond "it's cool", or "it sucks"? Neither of which is really helpful in bringing you forward.
Read the feedback; do not interpret it as personal attacks. Instead try to see it from the players point of view. Maybe everything wasn't perfect, maybe there are things you missed or were not explained properly.
I see lots of entries in other competitions (e.g. Ludum Dare) where people make something, upload it and never seem to care again about their game. Which seems to me as wasted opportunity to grow.
Now after all the dust is settled a Post Mortem to my entry Bunny Hop.
What went right
Even before the competition started I was pondering on what to do. In a previous Ludum Dare I had used a nifty 3d side perspective which I hoped to use again. And all in all it worked quite nicely. Built a really simple level loading system which would allow me to build levels fast. Not too comfortable, but it works.
Also, following my own advice from a pre-compo post, I did set up an empty project with base setup. Turned out there were two minor things that I could sort out before => less time wasted during the competition itself.
Getting the boring polish tasks done before the last days worked out nicely. It took me a day to get the displays, menus and settings done. I could afford the time as there were still three days left.
What went not so good
Lots of programmer art. I usually whip up something fast with the intention of touching up during the last days. Changing images is a rather pain free exercise. Unfortunately on saturday I was not able to do anything and on sunday my steam was gone. Therefore most art stayed as it was the first time.
I'm a lazy git :) There's one stage (Platforms!) I reused four times with little changes. The differences do change how to play parts of that stage, but overall it shows. In afterthought I'd probably kick at least one of them and spread the others apart a bit more.
My impressions of the competition
I love me my competitions with tight deadline. It's a reason to force myself to get something finished. That, and the organisation, competitors all went great and fine. However the progress reports are all over the place. It's probably the point of the participating points, but I prefer Ludum Dare's approach to this: There's one place to post, and it is used by everybody.
Here at GameDev there is one competition thread, but there's mostly links to journals and blogs. Maybe I'm old fashioned but I'd really prefer to have it condensed at one place. But that's just MHO :)
Here's my hopefully final entry, unless I find bugs or manage to get more stages done :)
All in all there's 21 stages, try to master them! (Mastering means use as few lives as possible)
Download it here http://www.georg-rottensteiner.de/files/Week Of Awesome III - Endurion - Bunny Hop.zip
More features, and ironed out a few bugs with switches. It's a good time to get the gameplay bug free now :)
And creating the preview forced me to wrap the package up once, which is a good test by itself.
So here's a preview with 3 stages (mere tutorials): http://www.georg-rottensteiner.de/webmisc/WoA3 - Endurion - Bunny Hop Preview.zip
No Bunny Hop without hopping
And got the most boring stuff out of the way. Start menu, options screen, key mapping. Phew. There's no end screen, and I'm thinking about a level selection screen. However the latter requires a certain amount of actual levels :)
Also now there's blood where you expect it to be. And it still looks mostly like programmer art! I tend to have a playable build out tomorrow and then it's stages, stages, stages.
Couldn't think of a better name
And added more gory goodness. Took me bit to reinvent (again) objects carrying other objects; as usual. Added switches with doors which need to keep held down. Also added saws
I'm thinking about finishing the boring GUI stuff tomorrow and then keep adding levels and maybe the one or other new feature. Plus this level makes it bleedingly obvious that I need to do at least a really simple shadow "system". It's hard to guess where the blocks actually float in space.
I just couldn't hurt my poor bunny just for the screenshot
Pro tip: Release a preview version at least one day before dead line. Someone will trigger that one crash bug right away, and you might even find more things you didn't consider.
I spent half the first day doing a bit of GUI all around which in the long run might actually have been a great idea. I really really don't like having to add GUI/menu structure at the last minute.
I'm trying to think of puzzles and on different ways to murder the bunny for puzzly goodness. In the current incarnation the bunny can be impaled on spikes and burned by fire. If you know your Wario Land you know what fire does to you
Also for other entrants: Know your limits, know the dead line. Don't plan too much or there will be ugly cutting near the end ;)
If only you reached that carrot up there!