About this blog
A Hobby Programmer's Rants
Entries in this blog
After years and more years of manually adding new assets into code I tried a newer approach. I'll use this journal entry to show off my asset
management tool (Asset Studio) but also ask for similar stories.
When I use the word 'asset' I mean images/textures, image/texture sections, fonts, animations, sounds, meshes, GUI dialogs, text tables, value tables, key/value tables, 2d layered free section and tile maps with objects.
In the days of yore (think DOS with Turbo Pascal 3) I added assets in code directly. There were no asset classes, or a manager. Only bits, and even the zeroes were... ahem.
In later days assets were handled classes, external files and complicated to handle. There are images, sounds, text tables, GUI dialogs. You name it. When tackling bigger games I stumbled again and again over the problem, that I wanted to reference other asset types, but couldn't, as they were stored in different files. There were different editor executables which didn't know anything about the other types.
The final solution was to add a asset file, that kept crucial information in one place. This was stored in XML. There were still external files for more complex assets (you really don't want to put a texture in an XML file). And to manage all assets I wrote an asset manager, namely Asset Studio.
This tools incorporates the whole asset type range and even has editors for the simpler assets.
Assets are referenced by name, so both asset type and name combined must be unique.
I used Asset Studio extensively for my Week of Awesome II entry "Building Blocks" (Post Mortem here: https://www.gamedev.net/blog/949/entry-2260318-the-week-of-awesome-ii-post-mortem/)
I'm pretty happy to finally have inter asset type references. I can see the chosen font and images in GUI dialogs, have text tables as source for GUI components, key/value tables as object templates for 2d maps, etc.
The underlying code is not really that clean IMHO but clean enough for now (TM). I do have a base class that stores the type specific asset info. Since my game framework is plugin based, and some assets are plugin specific, there is no real single location to load assets. Basic assets (text tables, GUI dialogs) are loaded by the framework itself, other assets (textures) are loaded by the relevant plugin on "loadup".
Practical problems I'm aware of are:
* Asset lookup is string based, not the fastest
* Theoretically plugins can be switched at runtime, this could lead to errornous asset caching (if I wanted to avoid string lookup). Probably the reason why I do not switch plugins at runtime
* Normal Asset types appear at level 2 of the XML hierarchy. Only exception are GUI dialogs, they allow nesting.
* Prepare binary asset package file
So, how did you approach assets?
In the later times I've come to write more and more games for C64 and my PC development got less and less. I do love me my little peaks in the form of competitions, like Ludum Dare, or GameDev's Week of Awesome.
How to prepare?
Decide which engine/libraries to use. Usually you have your favourite library about, but do you still remember all the little details? Maybe some base code changed and things don't work out of the box anymore?
Set up an empty project that opens up a window and sets up everything. Run it and be ready...
Interested? The competition thread is over here: https://www.gamedev.net/topic/668847-the-week-of-awesome-iii-the-third-annual-unofficial-gamedevnet-competition-administration-thread/
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? ;)
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 :)
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 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
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!
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.
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]
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
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.
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)
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!
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
So the theme is "Death is useful". This actually matches an idea I had quite a time ago but never realised as game.
It boils down to a simple 3d puzzle jump'n'run, where you as the player get several lives to complete a mission. If you die your body may help or hinder you in your task. E.g. jump on spikes, die, new live can now jump on the body and continue on.
I hope to get some nice ideas on how to kill the player in useful ways
On the graphic representation: I used the flat 3d view before in a Ludum Dare game and it's ideal for this kind of game. Also, it's quite easy mathematically
Also, here's a picture of a hastily pixelled bunny as the player!
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.
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!
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)
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.
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!
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?
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: