Sign in to follow this  
  • entries
  • comments
  • views

Entries in this blog

I figured I'd write a quick post about the incredibly painful upgrade to Windows 10, mainly due to their brutal DRM/key system... now that I finally have the dev systems running again.

Originally I was running Windows 7 as I chose to skip version 8 for obvious reasons. I've been using Mac OS as my primary system for many years now, but as we're focused on our Windows build I've swapped over and decided to install Windows 10. After using it for about a week I can honestly say that I feel it is the best operating system out right now, and definitely the best Microsoft has put out... but at the same time their activation DRM burned a countless amount of hours.

The initial upgrade from 7 to 10 didn't go very well... ethernet no longer worked, power management and sleep functionality was destroyed, and slight glitches here and there. So I made sure that the system was activated properly (as per the MS site), and blew away the drive and performed a clean install. Wow the difference was night and day... zero driver problems, zero glitches, and everything just runs absolutely smooth... a massive upgrade from Windows 7.

But... unfortunately the system wouldn't activate... even though it was supposed to work automagically.

I tried everything from forcing activations, running slmgr /ato in a loop for awhile, rearming the key, using slui 4 and going through phone activation and talking to someone. Absolutely nothing would activate the system.

I then blew away a second drive and reinstalled Windows 7 to dual boot... fully updated... and installed Windows 10. It activated! Bravo! Of course it was just as broken as the first time I upgraded, but I figured at least now I could boot into my clean install and it should just work.


So I break out good old slui 4 again, fail the phone activation, and talk to someone regarding the activation status. Unfortunately there was nothing he could do so he forwarded me to another department, and I figured I was screwed.

After waiting about 15 minutes an awesome employee came on the line and she went through everything with me, and eventually ended up remoting into the system, changing the product key, and activating the system. So the machine is now finally working properly! She was also really nice to talk to, and I am extremely happy about the customer service from MS when something gets escalated to that department.

Of course I'm not happy that I'll have to go through this exact same process again on the other system... although I actually hope I get the ability to do so as the other times phoning I was never forwarded to the other department like today.

So I guess the rule of the day... Microsoft get your crap DRM working before putting it out there and saying the system is working. I nearly broke down and paid $199 on the Windows Store for my "free" Windows 10 upgrade because it was costing me too much time.

Funny note: ironically these are MSDN keys that they know are valid, and when they ask me for the Win 7 key I have to log into their site to read them off the number smile.png
Wow getting this major build ready has been much more work than I had originally anticipated, but we're finally rounding the corner and checking off the majority of tasks for this milestone. Over the last month it seemed like there were a billion and one changes happening at exactly the same time, and it's all over the place... art, UX, code, design, writing, you name it... so at times it was quite frustrating to say the least!

It's a pretty important build for us, as it not only brings everything together, but it's our first time showcasing our polished art and UX/design decisions. We've wanted to cut a trailer and gameplay videos for quite a long time, but we just couldn't afford to make such a major time investment until we were truly happy with the game and what we were showing. We're finally in a place where we've locked down our UX, aesthetics, and design and so we just recently started production on our trailer, turning storyboards into visuals, so I'm really excited about that.

So here are a few of the major changes we implemented over the last few months:


When we first started on Empyrios I personally designed the HUD that is used in all the gameplay scenes. It has changed and morphed over time but for the most part it has always kept it's original design. The major problem here is that I'm not a UX/design person, and it was actually quite bad... I just didn't realize how bad until I sat in on a few UX/UI talks at GDC this year. I honestly have no idea why I continued on with that design for so long, especially considering we have an in-house UX/graphic designer who really wanted to spend the time to properly design and fix the problems, but we finally worked out the kinks and made it pretty.


The old design displayed a lot of data and flavour text, but wasn't very good at conveying the actual information you wanted at a given time. It was also spread out across the entire screen, which is great for building strong neck muscles, but not exactly the most usable interface for this type of game.

To remedy this we condensed the important information and collapsed the HUD into a single component, so now you only have to look in one place to get all the information you want. We also cleaned up the design by killing off the large text box we used for describing the currently selected ability and replaced it with a mouse hover. Not only does it look a million times better but now you can actually see what each ability does without having to click and make it your active selection!

Another thing that was cleaned up is our "hex grid" and selection graphics, which have actually never had any "real" assets as we were always using temporary "this will be replaced later" art. The smaller circles show the actual range of the ability, some being a radius (such as the example above), others only straight lines, etc... and the larger circles obviously being the characters you can affect. The large white selection circle, which is your currently selected unit, slowly rotates making it stand out from the others.

Lesson learned. Let your interface be designed by the people that actually specialize in UX and graphic design. Also a huge thank you to Derek Sakamoto ([twitter]figluster[/twitter]) for the amazing Hearthstone interface talk this year at GDC, I owe you a beer next year if you see this.

Updated Characters

As you may or may not have noticed in the prior screen, our artist Jove actually went over the entirety of the game art and ramped up the detail level so everything looks much nicer at higher resolutions. Some characters had pretty massive changes, such as the Dvergar changing their outfits and proportions while the Caelum were actually rebuilt from scratch.


During this process we also realized that there was somewhat of a gender imbalance, which for whatever reason hadn't been noticed in the past, and so we wanted to correct it at this stage. While it meant that Jove had to go back to the drawing board and completely rework some characters, we've now evened things out more, and while doing so it actually influenced some of our lore and story arcs in an extremely positive way. Below is an example, as the Inquisitor is one of the units who has had their sex changed.


We're now environment and character complete other than a few outstanding bugs and polishing issues, with the bulk of the remaining work in interface and campaign art. I may be a little biased but I am extremely happy with how the game's aesthetics have turned out, Jove has done a seriously killer job on everything.


Major Campaign Updates

In Empyrios you can play through the campaign as either faction, basically giving you a totally different viewpoint while you play through the story. People seemed to really like this concept, and once we had the dynamic campaign system at least half working we started getting even more positive feedback.

When playing through the campaign there can be any number of objectives active on the war map at a given time. These are dynamic events that will either be triggered by a specific action, or based on a chain of events that has already occurred during the course of the campaign. These events will not be available indefinitely, so you'll have to make tough choices on where to bring your squadron.


Your reputation with the various races and leaders will not only be affected by the choices you make, but on the outcome of battles, therefore changing the story based on your actions. So if you made the choice to help the Dvergar defend the auralite mines from the attacking Lithos, the Aduro may be questioning why you did not help them push the raiding Az'modai war party back into the desert.


We also finalized the design of the campaign screens, which I now absolutely love the look of, especially since we haven't had it included in previous builds and were only using a temporary text box. As a player you just feel so much more connected to the actual story and characters by presenting it this way.


The campaign screens number in the hundreds and work is constantly ongoing with them, but hey at least we've nailed the aesthetics!

Moving Forward

There are still some kinks to work out in the build, but right now we are laser focused on getting our trailer cut so that we can get it out to the public and launch our Greenlight campaign. We've also been looking into some areas such as joining the Square Enix Collective to promote our game, as well as running a Kickstarter campaign allowing us to build things out to completion and get more direct player feedback and involvement. The major risks have been killed off with our game design, aesthetics, and UX nailed down... so at this point I have zero worries in regards to project completion and I'd like to get some backer involvement allowing us to move forward at a quicker pace and including some things from our "nice to have" list.


Another job we've been tackling is updating both the company and game websites to be static, rather than running on wordpress. For content such as blogs we're now preprocessing everything using Jekyll so that we can serve static pages straight from Amazon S3 / Cloudfront CDN. So we'll be infinitely scalable and they actually load 10-30 times faster now. The company site conversion was just finished the other day and I'm hoping to get it moved to Amazon over the weekend, and the Empyrios site has a bit more work due to the dynamic bits such as forums that run on the ephemeral EC2 instances, but it's slowly coming along and should be ready quite soon.


Well I think I've touched on nearly every major point, other than the horrible pain of not having proper tools for our artist and how we've started to correct that, but that's an entire post on it's own at some point in the future. Needless to say things could have gone a lot smoother if we had invested in building more and better tools up front.


Ok it's time for me to get back to working on the trailer, but if you like our stuff come follow us, we appreciate the support!


[font=arial] | [/font]


[font=arial] | [/font]


[font=arial] | [/font]


Cathedral Battle

I've been working on the animation editor all day but took a break to work on a few campaign events... finally fixed up some bugs in the Aduro Cathedral and promptly got beat down dry.png


Also the proper loading screen is now working for that mission:


Back to working on the animation editor!

Polish that build!

We've been insanely hard at work getting ready for our next major build, which is what we'll be using to record our Greenlight trailer and various gameplay promotional videos. I was really hoping we would have been able to put the video together sooner... much sooner... but I decided to wait until we had the characters and maps fully polished so that we'll be showing our top quality rather than a WIP.

Our artist Jove has been working on detailing the characters to their final state, and that has been coming along absolutely amazing. Right now we're aiming to have the entire set of characters and environments completely polished within the next three to four weeks!




We also spent some time polishing up more loading screens that showcase the various races:



Another big project going on right now is work on our in-house animation editor. Right now our tools are quite primitive and it has really been a blocker as getting art into the game/engine and tested takes a bit of manual work and hackery. So I've been building out an editor that will allow our artist to load up any map, load up characters on the hex grid, and then walk around and/or perform any actions and animations. This way he can play with things such as timing the walking/movement animations and being able to be more creative with those, as right now it is a really hard back and forth process for testing. I've also been working on some usability features of the editor such as hot-loading freshly changed assets, and loading up the UI components so that the character ability icons and portraits can be previewed in the editor as well.

If all goes well we should have the entire set of characters and environments polished and ready to start shooting the trailer and gameplay videos within about 3-4 weeks. Right now I've been storyboarding the trailer in between tasks, but I'm hoping that in a few weeks I'll be able to sit down and dedicate a lot more time to it so that once we have all the assets complete the only thing left to do will be to render the portions of gameplay and stitch them together... as it will still need to go out to our composer to add custom music once that is complete.

Phew... the polishing of this title is roughly 99% of the work at this point smile.png

Oh also we started using Tumblr as a screenshot / image dump of progress on Empyrios, so if you're interested check that out here:

Loading Time

Well it was great to meet up with old friends, make new friends, and learn a lot at GDC... although now I'm paying for it trying to catch up! So not much has changed in the build since last week, but we've been closing out a few issues here and there.

Right now I'm working on some lower level tech and async loading issues, and at the same time we're getting a lot of the loading screens polished to final versions.



We're still pushing really hard to get the Empyrios site and greenlight trailer ready, and we also have some plans for other gameplay videos we want to put out along with various marketing materials.


Hopefully by next week I'll have a much better update on our progress!


Who's going to GDC?

Since it was the last day of online registration I caved and bought a GDC pass since I really didn't want to miss out this year with all the uber cool new toys that'll be on the floor. Who else is going?

I finally had time to update our site announcing iPhone support, our new team member, and briefly what we've been up to and what's next.

Last but not least... I really like the Lithos race in Empyrios ph34r.png


Kitchen Sink Week

Definitely a kitchen sink week. Since the last time I posted I've hopped around and worked on probably 10-12 completely different things, which is quite interesting but at the same time extremely draining.

One task was getting more marketing materials tasked out and more planning on that side of things. We still have a lot of work to do on this front but it's coming along quite well and we'll start marketing much heavier in the coming weeks when we have our trailer ready, greenlight page launched, and finally launching the Empyrios website. The home page is nearly complete with a bit more copy to be written & edited, but for the most part it's ready content-wise:

We also finally got around to updating small things like our company LinkedIn page with a nicer header:

Our writer Mike has done a lot of work on the Empyrios site content wise with race descriptions, class descriptions, and work on the home page. Next he'll be working on some writing and editing to finish off the site, as well as writing a few lore pieces that we'll be showcasing when the site launches.

While all of the above has been going on we made some great progress on actual game tasks as well. As we're currently reworking some of the campaign, I wanted to have the world map ready as in prior alphas we actually had a temporary stand-in which as a list of available scenarios. We're still missing a few locations on the map, and the guild hall isn't showing as that will change depending on faction and there hasn't been enough time to get this working, but it sure beats the old scenario list!


This will be progressing and changing constantly as we work on the writing and campaign changes, and we're still figuring out the best way visually to show that a scenario is active. It doesn't show on the above screen but right now a small red notification type icon appears over the active areas, but again this is only temporary as we test the new system.

After showing our composer the above shot he sent over two tracks (one per faction) that work perfectly! They were ones that were created during the soundtrack composition, but were a little slow for actual battles so they went unused. I popped them in just today and it goes extremely well!

While all of this has been going on I've also been working on our core tech and prototyping a few things. I have some changes planned over the next few weeks in order to make things a little more maintainable in the future, as well as support the multitude of platforms much nicer. Originally the game was targeting the iPad only, which we than added PC/Mac, and finally added iPhone/Linux to the mix. This has made a lot of the lower level code really gross as it happened over time in production, so rather than accumulate technical debt I'm going to burn 10-12 days on fixing the problem once and for all and having a strong foundation to launch, maintain, and build on in the future.

Outside of that we started the final pass on the in-game HUD and we'll be implementing some changes over the next week or two which will be the last time we touch how it both looks and works. Most of the changes are cosmetic but there is one UX difference that we're just finalizing our thoughts on right now. Below are a few screens showing the HUD in our current build:



[color=rgb(40,40,40)][font=arial]If you want to see more on our upcoming game check out: [/font][/color]Empyrios Announced!

[color=rgb(40,40,40)][font=arial]You can also follow us on our blog, Facebook, or Twitter to get future updates![/font][/color]
Creoterra[color=rgb(40,40,40)][font=arial] | [/font][/color]Facebook[color=rgb(40,40,40)][font=arial] | [/font][/color]Twitter[color=rgb(40,40,40)][font=arial] | [/font][/color]Google+

What an alpha!

It seems I haven't posted in quite some time... which is ironic considering I wish I had been posting more during development, but unfortunately there haven't been enough hours in the day!

During our alpha build we hit a lot of things that we realized just weren't ready yet. Could we launch as-is? Sure we could have proceeded with beta and tried to clean things up as quickly as possible before release, but considering we have the luxury of time I decided to push back our planned launch by 6-8 months and get everything up to the high quality standards that we hold.

So what did we find out in our big alpha build?

  • While the world and basic story framework for both campaigns was received amazingly well, the actual story content and dialogue itself wasn't up to the same quality level as the rest of the game.
  • Multiplayer gameplay was splendid, but the AI in campaign and practice mode just wasn't smart enough, we didn't have enough data.
  • We needed more UX and design work on the "out of game" user interface, cleaning up some issues and usability.
  • Players wanted to have more personalization over the characters they were using in squads, small things like being able to name them, and having persistence even if they are replaced in the squad as they may wish to return later.
  • The amount of requests we've received to launch on the iPhone was staggering (our initial targets were iPad/PC/Mac).

    How do we remedy this?

    For starters one of the latest things we have done is bring a writer onboard to help with all dialogue, lore, and campaign story flow. He's also working on lore and written work for the Creoterra and Empyrios sites. I can't begin to explain how much nicer everything is turning out now that we have a real professional working on this rather than using our amateur writing skills. We have a ton of great world building, lore, and concepts, but when they were put to words they just didn't feel right and seemed a bit too technical. Our new writer Mike is injecting a ton of creativity into the writing and everything he does is coming out just amazing!

    What could I say about the AI other than... oops. The code hasn't been changed much and there are only a few minor features needed in the tracker right now, but I had to go back and evaluate our tools and how exactly we queried the data on the AI playing against itself as well as players. We have quite a large dataset but a lot of it is deprecated due to gameplay changes or major unit reworks, and so I decided to throw out a good portion of the data and start having robots play against each other all day. It has been constantly improving but it's an area that I'm still working on constantly and will likely end up being the hardest part of development to get perfect when all is said and done.

    In regards to the UI both in and out of game we've made a lot of changes and a lot more are forthcoming. Mind you I am sooooooo glad that we had to go through this process again, which is the fifth refinement I believe. During the UX/design process of making changes on the HUD our designer came up with some great ideas on how we could run on a smaller screen without sacrificing any quality. We smashed heads together for awhile and finally have a UX design that works tremendously, and while the iPhone version will have different UI/HUD in comparison to the PC/Mac/iPad version, it works extremely well for the platform and is very intuitive. So in the end we have burned (and are still burning) a lot of time on the UX of the UI/HUD, but out of this work arose a way to support a platform that we all wanted to play on!

    Until the alpha the idea of naming units and various other small customizations didn't even pop into my head. We had a ton of major customization such as squad building, team colour, sigils, mastery trees for units, and a few other systems and just hadn't thought at the level of micro customization as simple as naming. We're still in early stages on this as it's completely UX that we need done as the code is dead simple, but right now we're bogged down with too much UX work.

    Regarding persistence we've actually changed a few things up and it's working out extremely well. We added a "guild hall" on the world map which is really just a glorified menu system full of art. When you enter the guild hall you'll see the stable of characters that you have access to (as our game is completely about building/battling with your guild) and you can swap them in and out of your active squad freely between battles maintaining their levels, masteries, and all customizations. This will also be the area where we add small micro customizations such as unit naming, etc.

    As I mentioned above the main UX hurdles that were holding us back from launching on the iPhone have been solved, which makes me happy as I'll now be able to play the game on my 6+ when I'm out somewhere! Considering we support the very first iPad, technically it was dead simple to get running on the iPhone and it's really just UX hurdles that we're solving along the way.

    Ok so after proof reading my post I realized... it just isn't as cool without pretty pictures. So I'll end with a screenshot of the Empyrios site that is nearing completion, part of the game guide, which showcases some work from our new writer!

    and yeah.. yeah... I realize there's an orphan word in the first paragraph... the design is still being tweaked to accommodate all our new content smile.png


    [color=rgb(40,40,40)][font=arial]If you want to see more on our upcoming game check out: [/font][/color]Empyrios Announced!

    [color=rgb(40,40,40)][font=arial]You can also follow us on our blog, Facebook, or Twitter to get future updates![/font][/color]
    Creoterra[color=rgb(40,40,40)][font=arial] | [/font][/color]Facebook[color=rgb(40,40,40)][font=arial] | [/font][/color]Twitter[color=rgb(40,40,40)][font=arial] | [/font][/color]Google+
I spent the majority of the week polishing design, although that pretty much amounted to ability naming and drafting our final HUD design and functionality. Until you sit down and try to name 120 abilities and make them all both represent the action as well as sound interesting, you don't really realize the amount of time and effort this takes! I still need to make one more pass on the descriptions as I'm not happy with a lot of them, but that's going into the "do this later" bucket for now.

We're going over the draft for the final HUD one last time tomorrow before we start working on production for that. It's mainly a polishing and usability pass where the health and power bars now have small representative icons, and the ability description box loses the power cost in brackets for a shiny new power icon. Also a small duration icon is being added beside the power cost for actions that occur over multiple turns, as right now they are only listed in the description and it eats away too much space. The final component is cleaning up the right side, which in current builds as you can see below has three icons, but will now only have finish turn and surrender icons. A slide-out panel is likely going to be added which will have the exit game (or in multi return to game list), and a few other options you might want to change on the fly such as showing the grid at all times and it's opacity level.

Finally I posted up a new #screenshotsaturday which is still using the old icon set as I don't want to put the new set in the build until we have the HUD changes and artwork finalized.


[color=rgb(40,40,40)][font=arial]If you want to see more on our upcoming game check out: [/font][/color]Empyrios Announced!

[color=rgb(40,40,40)][font=arial]You can also follow us on our blog, Facebook, or Twitter to get future updates![/font][/color]
Creoterra[color=rgb(40,40,40)][font=arial] | [/font][/color]Facebook[color=rgb(40,40,40)][font=arial] | [/font][/color]Twitter[color=rgb(40,40,40)][font=arial] | [/font][/color]Google+[color=rgb(40,40,40)][font=arial] [/font][/color]

Evolution of Icons

One of the things we're working on finalizing right now on Empyrios: Prophecy of Flame is the HUD for selecting unit abilities. Our artist Jove is working on upgrading and polishing the final artwork for the icons, and we also need to make one other small change that I've meant to for about a year but haven't had a chance.

What is the ability bar? It's the UI component used when you have a unit selected which enables you to quickly swap between the various abilities (and movement) resulting in the available tiles being highlighted. The example below shows the priest unit selected and in this case the ability bar would have the movement icon selected:


While getting some of the latest assets in the build I thought it would be fun to show how our ability bar has progressed throughout development.

Initial Prototype

We put together a rough working version of the ability bar in order to test out our ideas and gameplay. This actually lasted for a few weeks of hackery while we tested how everything was going to work and as we solidified the core game rules. Every ability had an unseen power cost and damage as we played around with things, and so this initial working version was quickly upgraded.


Second Prototype

As the prototype was progressing we needed to actually be able to see the changes to abilities without having a spreadsheet open. With the previous version we were mainly testing animation and UI so this wasn't an issue, but once we really started concentrating on the unit abilities themselves we started loading the icons and descriptions from unit files.


Alpha Production

The ability ideas were solidified at this point and so our artist Jove set out on creating the actual icons, and we started to give more informative descriptions. The build was fully playable and as the ability descriptions and types are pulled from the unit files at runtime it was now simple to start tweaking abilities and balancing units.


Beta Production

This is our current phase and there is still a little bit of work left but we're finally nearing completion. The icons themselves are being upgraded to the same quality and style that we use in the mastery tree and other areas of the UI, the ability names are almost complete, and descriptions still need a little work but they're getting there. There is still one core change that we're making in the HUD and that is with the power cost (i.e. the 16 in brackets) which I've meant to have swapped out since the very beginning but just haven't had the time. Our final version is going to have a small lightning bolt icon that we use elsewhere to denote power, and then have the cost beside it. The design on that is still being finalized but it'll both look much better, as well as provide actual information to the player rather than just a random number.


I'm really happy with how the ability bar turned out in the end and I personally love it for gameplay, especially in comparison to digging through menus or other UI components.

If you haven't checked out the upcoming game this UI belongs to, check us out: Empyrios Announced!

Follow us on our blog, Facebook, or Twitter to get future updates and take part in upcoming contests we'll be running.

Creoterra | Facebook | Twitter | Google+

What's in a name?

We have finally completed the work needed to correct the naming/branding issue I mentioned in my last post. It took a lot more time and effort than I had originally hoped, but in the end I'm extremely happy with the change. I previously mentioned that we had selected a new name, and I thought we had, but after thinking about it over a longer period of time I wasn't completely satisfied. This put us into brainstorming mode, and after roughly 50 cumulative hours between a few people strictly going over name ideas, we found something that I was extremely happy with.


So why that name? and how did we come up with it?

Initially we started looking at words used throughout the game lore, and then looking at combinations of words, and we came up with a list of a few hundred ideas. Nothing really stood out as something that we wanted to use, so I decided to go back to the drawing board and try to put something together like we did with Creoterra using latin or ancient greek.

Eventually I managed to put together Empyrios, which I found by sheer coincidence is an actual latin word, a plural meaning fiery, burning, etc. I took "Empyr", basically a license plate type spelling of "Empire", and added the name of the Aduro god of fire "Pyrios", which in latin translates to a singular case of fiery/burning. So the meaning I took out of it was something along the lines of "empire burning", which fit the lore absolutely perfectly.

I also wanted to add the subtitle "Prophecy of Flame" to give it a bit more meaning, and again tying in with both the name Empyrios as well as the lore and campaign story.

Once that was settled and we had the basic idea drafted we spent another 20-30 hours on creating the logo and branding. This consisted of rebuilding the font and texturing (similar to our original), deciding on how to style the subtitle, and then cleaning up the actual logo image above the title. Of course once that was done there happened to be a million places that it needed updating, on, our blog posts, screenshots, my original post here at GDNet, etc.

The overall cost of this mistake was roughly 80 person hours. Obviously I'm not exactly thrilled about burning that amount of time, but it was something that needed to be done, and in the end we have a non-generic name that ties much more into the actual game story and lore itself than our previous idea. I can't say that I'm happy with the process, but I'm extremely happy with the end result.

If you haven't yet, check us out: Empyrios Announced!

Creoterra | Facebook | Twitter | Google+
Whenever people ask me what it's like to build a startup, not just in games but in general, I often equate it to driving a car with no breaks down a road full of speed bumps and road blocks. If you're small and self funded you'll be wearing many hats, and like it or not you're going to miss things along the way and run into a lot of issues, but to be successful you just have to find a way to continue moving on. The only sure fire way to lose is to stop trying.

During development we've hit quite a large amount of speed bumps. Myself moving from a predominantly tech/engineering role to production/design along with taking care of engineering has proved to be quite a challenge, and you have a constant feeling of "this is all wrong, I have no idea what I'm doing". Trent posted a great article about his experience here, and that's pretty much what I've experienced through the entirety of our production.

Ok so why am I on GDNet babbling about this?

If you're reading this blog than I'm guessing you saw the recent announcement of the game title we've been working on for an extremely long amount of time. We basically soft launched the company site and posted here on GDNet, in another forum post, and to friends and family on Facebook. Our purpose was just to make sure that everything was working fine technically, as we're working on getting the actual game site launched within a week or so, and at that point we planned to start to marketing the game everywhere. So we figured, let's get things online a piece at a time, test them out and make sure we have no issues, and then we should be good to go. I was expecting a technical hiccup or two, and we encountered a tiny bug that's still in the tracker for me to fix, but nothing major stood out at all and everything seemed like it was ready and we could move on to step two. Then...

bizzang! wham! pop! crunch! wtf!

I received an email sent from the site contact form, and the person was asking whether we are related to another game/company with an extremely similar title name. Panic set in.

It's quite funny actually. We operated as a numbered company for over a year because I was so picky on naming, and it took about a year and a half to get something I really liked. I wanted a made up word, that also has meaning, and I could register the domain, trademarks, etc. Eventually we settled on Creoterra which is really two latin words "Creo" and "Terra"... with a loose translation of creating earth/worlds... and we added our tagline "Bringing worlds to life!". This worked out extremely great!


When naming the game title we decided again on the latin word Imperia, which is the plural of Imperium (supreme power, dominion, commanding the state, etc). We searched the trademark and copyright database, made sure we could secure the domain we wanted, registered the name on the markets we want to sell on, and decided that we liked the name. This is where we made an extremely key mistake... for whatever reason we didn't search the name on Google.

As you can imagine a title already exists using a variant of the name, and therefore not only could we have future legal issues, but even worse we could be confusing our own potential customers, as well as those of the other company. This is probably the worst road block hit throughout production, strictly because we've been calling the title by that name throughout the entirety of internal development and this was something that was completely avoidable but overlooked due to time constraints. Now the only sane thing to do is to change it.

After a crazy amount of hours brainstorming, and crying to Drilian on the phone for awhile (in reality venting in IRC but that didn't sound as powerful), with his help we finally settled on a new name for the title and we're working on rebuilding the logo and branding as I write this. Mind you the funny thing is that what started out as shock and panic has turned into a really great thing! The new name we selected is a word that we made up, is used nowhere in the world, and is very core to the actual story of the game world. I was also told a few times that Imperia sounded pretty generic, but I always just brushed it off. I'm not sure if it's Stockholm syndrome or not but looking at it now I agree that it does have a generic ring to it, and luckily the new title is a much better fit for our game.

My lessons learned were things I already knew, but I also have to be a little more careful with in the future:

1. It doesn't matter how busy you are with writing code, game design, production, management, or really anything else... you should really take care of any issues that could become perilous in the future. The only reason we ran into this one was from being too busy doing everything else and not taking enough time to properly go over the business issues. Skipping something as simple as searching Google cost us a great amount of time brainstorming and rebuilding artwork.

2. You likely want to either retain legal counsel for searching and filing for your trademarks or have a business representative that knows what they're doing handle it for you.

3. There is always a great benefit to a soft launch, and you'll find that sometimes it isn't only for technical reasons smile.png

So hopefully I'll be able to have everything updated by late tonight, correct the naming in my previous post and on Facebook, and walk away with a red face, lesson learned, and damage avoided.

We're a tiny studio and we finally found the time (well made the time by staying up about 50 hours straight) to finalize our site and announce our upcoming strategy RPG Empyrios for the iPad/Mac/PC platforms. Also I saw a posting by GDNet on facebook regarding being in the banner, and I'm hoping to get some consideration as three long time community members have worked on this title (myself, nsmadsen, drilian).

Check out our site:
Imperia announcement and details:
Twitter: @Creoterra

And some screens!




While working on our current game title on mobile platforms I ran into the need for extremely efficient texture loading. Now that I have some free time I figured I would write an article on the most efficient way of loading texture data on iOS/Android devices that are using a PowerVR chip.

What problem does this solve?
The main reason was a need for streaming textures during gameplay due to memory limitations. This could be due to having a complex 3d world and needing to stream objects into the level, or in our case it was having to stream a lot of textures for use in 2d rendering (we pre-render our world, objects, and character animations to texture atlases and UV them to billboards to achieve high quality visuals, lighting, and complex environments/characters).

If your issue is needing some milliseconds back, loading textures on the fly in a 3d world the problem is much less pronounced as you would be using compressed PVR textures, but there is still a great performance benefit to this method.

If you are in the same boat that I was in the latter case of needing to load them for texturing billboards, you are likely loading them from a lossless format such as PNG (the most common I've seen people using), BMP, TGA, or uncompressed PVR. Using the techniques outlined in this article you can achieve massive performance benefits by changing the format you are using and how you are loading.

Step One: File Format
If you are using your textures on objects in a 3d world then you will definitely want to use PVRTC format as it is a lossy, fixed-rate texture compression format that supports both 4bpp and 2bpp ARGB data.

For lossless textures your best option is to use the uncompressed PVR file format. This consists of the PVR file header along with your data in an allowed format such as RGBA4444, RGBA8888, BGRA8888, etc. If you are using 32bit data (like we do for the most part) there is really no reason at all to be using RGBA8888 as the driver has to process this cpu-side and you can easily pre-process your data to BGRA8888 for a straight upload to memory.

(Notes of Interest)
- If you are using an RGB8 data format you are making the CPU do even more unnecessary work as it will have to add a byte of padding so make sure to always use RGBA/BGRA even if you don't need the channel.

- Using an uncompressed texture format obviously has the end-result of requiring more space on disk. This won't affect the download size of your application (IPA/APK will have your content zipped therefore providing compression) but when installed will take more space on disk. If you find yourself using more disk space than you would like you can always supply your textures in .zip packages and at initial load time or as a threaded job decompress what you need and delete them when your application exits/terminates.

Step Two: File I/O
From most articles I've read online or code I've seen people write they are loading their texture data (either on their own or using a library like stb_image) by opening a file, reading the data, decompressing the data if needed, and then calling glTexImage2d(...) specifying the RGBA format. While this approach works fine if you're loading all your texture data up front, as soon as you need to stream textures with the game running you'll hit some serious bottlenecks. There are some unnecessary allocation/copy (and possibly decompression depending on format) operations that you can get rid of extremely easily giving you a noticeable impact on the time taken during the frame.

The way to avoid this is to use memory-mapped file I/O. This means that the file contents are not read from disk and so do not use physical memory, instead they are cached by the OS in kernel memory space and paged in and out when needed. This can actually add a little latency to file access, say your average is roughly 0.012ms for the kernel to load the page on access there are times I have seen up to 0.135ms, but as it reduces an alloc/memcpy (which cost well above kernel page load time) the performance gains are well worth it (not to mention you won't need to worry about memory fragmentation if you are using platform malloc/free calls).

To achieve this you would do the following (to simplify the example I pulled out error handling):
[source lang="cpp"]
#include < sys/stat.h >
#include < sys/mman.h >
#include < fcntl.h >
#include < unistd.h >

int32_t file = open("my_texture_file.pvr", O_RDONLY);
struct stat file_status;
fstat(file, &file_status);
int32_t file_size = (int32_t)file_status.st_size;
void* data = mmap(0, file_size, PROT_READ, MAP_PRIVATE, file, 0);
// Note this will not close the file/mapping right now, as it will be held until unmapped.

// When finished with this data you call this to unmap/close.
munmap(data, file_size);
Now we have now created a virtual mapping and promised at the kernel level that we are only using it for read-only access which can give us optimization benefits.

(Note of interest)
In most cases memory mapped files are only effective with large files having a file size with a multiple of the page size (i.e. a multiple of 4096 bytes) in order to avoid wasting page space. Obviously there are times when textures will not adhere to this, although for our use case it has never been an issue and we have always achieved a net performance gain.

Step Three: Texture Upload
The first thing you want to do is get the PVR header struct from the file which contains all the needed info. This way you can verify the format using the magic 4CC and have all the needed metadata. Once you've achieved this you can upload your texture data to the GPU for use.

Below is a simple way of doing this (to simplify the example I pulled out error handling, made assumptions on constants, etc)

[source lang="cpp"]struct PvrHeader
uint32_t header_length;
uint32_t height;
uint32_t width;
uint32_t mipmap_count;
uint32_t flags;
uint32_t data_length;
uint32_t bpp;
uint32_t bitmask_red;
uint32_t bitmask_green;
uint32_t bitmask_blue;
uint32_t bitmask_alpha;
uint32_t pvr_tag;
uint32_t surface_count;

static const uint32_t kPVRTC2 = 24;
static const uint32_t kPVRTC4 = 25;
static const uint32_t kBGRA8888 = 26;

PvrHeader* header = (PvrHeader*)data; // data being your mapped file from step two
uint32_t pvr_tag = header->_pvr_tag;
// Here you would check the pvr_tag against the 4CC "PVR!" to verify

uint32_t flags = header->flags;
uint32_t format_flag = flags & 0xFF;

void* data_start = data + sizeof(PvrHeader);
if(format_flags == kBGRA8888)
// Note: I am assuming that you have already generated, bound, and set texture parameters.
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, header->width, header->height, 0, GL_BGRA, GL_UNSIGNED_BYTE, data_start);
else if(format_flags == kPVRTC4 || format_flags == kPVRTC2)
// You would do the same as above but using glCompressedTexImage2d(...);

Step Four: Effective Use
At this point you are using the most efficient texture format for your needs, you have the file mapped, and you can upload the data to the GPU by simply getting the kernel to load the page and copy. It should be obvious but these are not steps that you want to be doing consecutively each time you want to load a texture. For efficient usage you would build a cache of mapped texture files (storing the header and pointer to the data_start) by mapping them all when you are initially loading the game (John Carmack found that on iOS for whatever reason you only have about 700MB available so if you need more you will have to manage your cache more efficiently by using mmap/munmap with your job pool). When a texture is needed you glTexImage2d and the kernel loads the page, uploads the data to the GPU in native format, and you are ready to go. On termination you destroy your cache by unmapping all of the files.

What Next?
Depending on how many textures you were streaming in and their size you should already have a really great net performance gain by implementing the above solution, although with iOS6 you can go even further resulting in greater performance gains. I'll save this as a topic for a future journal post, but for anyone that wants to implement this the addition I'm speaking about allows you to reupload texture data without having to go through the usual binding process. This allows the driver to work much more efficiently with managing memory and avoiding allocs, fragmentation, etc. You are able to build a much more efficient caching system and basically doing your GPU allocs up front and never having to do them again. If you are interested you can find a video regarding this (and other additions in iOS6 such as cheap nearly free programmable blending woohoo!) here (you need an Apple ID) in the video Advances in OpenGL and OpenGL ES.

If you run across any errors in this post please let me know right away so I can make sure to correct it. Thanks!
With my last post it seemed like there might be a little interest in giving some free pixel art characters for people to use so I got everything ready and packed up. The package includes the individual png sprite frames, the .gal (graphics gale) files, and the two full character sheets. It includes ten characters with the humans nearly complete and the undead needing some additional work.

(note: you can easily select the magenta portions in the palette and color them how you want, or do it dynamically in-game by checking for R==B&&G==0 and multiplying that value by the team colour, etc)

Feel free to use them for anything you want as they are under a "do whatever you want with them" license... so either internal pre-production / stand-in artwork or for commercial use. As I mentioned in the last post I'd much rather have somebody use them instead of rotting away on our company backup server after burning capital on their production.

Download link:

For anyone that missed the last post here is a preview:

gallery_2352_515_16169.png gallery_2352_515_2978.png
During pre-production on our current title when we were defining art style and world design we built 10 characters before completely changing direction and art style. They are in various stages of completion (the human characters have all 3 directions with multiple animations such as different actions, hurt, death, etc.. while the undead characters are much less complete) but I'm wondering if anyone could get any use out of them either as placeholder art in (pre)production or even for commercial use if they wanted to. I'd much rather have some people using them (for free of course) than packed away on a backup drive somewhere considering they took time and money to build.

gallery_2352_515_16169.png gallery_2352_515_2978.png

The magenta portions of the sprites are R=B && G=0 so that way you can easily team colour them (either check for R==B&&G==0 and multiply by the target color.. or change the G channel to represent saturation and only check R==B, or whatever suits your needs). As I mentioned they are animated but you could always use them as static sprites like game board pieces or something as well.

If people could get some use out of them I'll upload all the PNG frames as well as GAL files (for GraphicsGale animation editor) with a "do whatever you want with them" license.... so let me know! Otherwise they are doomed to live out their life on the Creoterra server backup drive forever!
Sign in to follow this