Sprites & Spells: the PixieEngine Blog

How to Embed PixieEngine Projects on Other Web Pages

Pixie — Fri, 03 Feb 2012 21:28:21 +0000

It’s possible to embed an iframe version of your game on any webpage with the following embed code:

Be sure to change the project id to your project ID and make sure the width and height are set correctly. Also you’ll need to hit “Publish” anytime you want to update code that is displayed in the embedded version.

Another alternative would be to click “Export” and then “Download .zip” then create an index.html file that will look something like this:

You may need to include your own copy of jQuery and add some css to your liking.

I’ll try and get in a feature to auto build an index.html that will be created when downloading a zip.

This week in Pixie: Sep 06 2011

Pixie — Tue, 06 Sep 2011 17:50:11 +0000

We’ve been really focusing on making Pixie as easy to use as possible. In order for all of you to be able to create the best games you can we know it is necessary to have excellent reference material about the available libraries.

Our documentation has been completely revamped and includes tons of code samples to get you up and running as quickly as possible. If you just want a page to look at as a tab in your browser when you have questions, you can open up Documentation or navigate to them through the documentation link in the Wiki. If you are too immersed in the IDE and can’t bear to leave, then you can click on the Documentation book to open them in a new tab.

Documentation is an ongoing task and we are working to improve it daily. If you have questions the documentation can’t answer be sure to ask in the Forum or in the chat and we’ll help you out, then make sure that the answers work their way back to the documentation.

Sadly, the Kongregate export walkthrough is on hiatus. It turns out that they rejected our game because “iframe games are generally reserved for virtual-goods enabled MMOs”. We’re always looking for new places to export games to, that way PixieEngine developers will have the most options available for distribution. The HTML5 world moves fast, new channels are always opening up.

The featured tutorial we have this week is the annotated source of Daniel X. Moore’s Ludum Dare entry from last week, SurfN-2-Sur5 (Extended Edition). The code is very clear and filled with comments explaining each aspect of the game. It includes some important gems, such as setting up a camera to follow your player, debugging your collision detection, and programmatically generating level content.

Thanks for reading, and keep making those awesome games!

This week in Pixie: Aug 28 2011

Pixie — Mon, 29 Aug 2011 18:09:09 +0000

This is a big week for Pixie. To start off, we’ve redesigned your home page to help you find everything at a glance. We also reorganized what people are saying about your sprites and projects so you can easily pick out the praise.

Secondly, we have cross platform support for making games with joysticks! See it here: Boomstick.

There are already a few games on Pixie taking advantage of this great breakthrough. Play Red Ice, a hockey brawler, with up to five friends or collaboratively paint with your peers in WinniPaint.

We have two new forum members to mention this week. Check out the retro console art stylings of Hawthorn and play nickretallack‘s Factor Blaster 2, a game where you destroy your enemies by blasting them with their prime factorization before they go mersenne-saiyan.

Finally, we’ve added more support for exporting your Pixie games to great platforms. We’ve had a Google Chrome Webstore export for a while, but now we have the ability to publish to Kongregate, so you can publish your game all over to get lots of plays and good feedback.

Stay tuned next week for a full Kongregate export walkthrough.

This week in Pixie: Aug 15 2011

Daniel — Wed, 17 Aug 2011 06:50:31 +0000

Hey guys. It’s been a long time and we’ve been keeping busy here making Pixie as great as we can. We’ve come a long way since our last newsletter.

Our most exciting new feature is an integrated forum. Pixie is becoming a thriving community so come on by, introduce yourself, ask questions, and make new friends. A big shout out goes to our newest active forum members: ToxicGamerGirl , Spriter2000 , DFectuoso , PixelZephyr , and Mr Numnums.

If you’re looking for a fun and simple adventure game, check out It’s Dangerous To Go Alone. In this rip-roaring adventure you help an elf boy and kitten solve puzzles to find their way home.

There have been big improvements to the game design tools. Take a look at our full demo about how to make an Asteroids type game: Pixteroids. You’ll learn how to create a spaceship that moves and shoots, as well as how to create and destroy asteroids.

That’s all we’ve got for this week, but stay tuned and we’ll be back next week with more hot new features, games and tutorials.

Optimizing Red Ice

Daniel — Thu, 14 Jul 2011 19:23:24 +0000

I was able to go a long way without optimizing the Matrix and Point classes. Since most of my games and prototypes were relatively simple or made limited use of points and matrices it didn’t matter too much, that is until Red Ice, which was using 5 physics steps per frame and computing tons of vectors and collision responses.

Optimizing the Drawing

The problems became evident in the profiler. First was the classic of “draw less”. Because Red Ice is running at 1024×768 even clearing the entire canvas can get costly, not to mention copying over the ice and blood canvases to the main one. In order to break through this bottleneck I separated out the rink/background and blood canvases into layers that stay below the main canvas. Since the rink never redraws and since the blood only adds and erases strokes in a semi-permanent way, this saves copying a ton of image data to the main canvas, which in turn saves a ton of time. I still clear the entire main canvas every frame, but implementing selective clearing is a big project and would have limited performance gains (we still need to clear big chunks of the canvas most updates with all the stuff moving around).

Optimizing Joystick Input

Now that we are drawing less the next big bottleneck came from joystick input. This sounds pretty ridiculous for anyone coming from a non-web background, but considering that using 6 XBox 360 controllers as input into an HTML5 game was pretty much unheard of, it’s not inconceivable that the first time it has been done might not be the most optimal. The core of the issue was that every single piece of data that is transferred from the native extension into JavaScript slows things down. Even something as simple as an array of true/false values for buttons. Even an array of six integers for six axes. Even an object with two properties buttons and axes. Each single piece slows things down.

The first performance improvement I made was to use a single integer for all the buttons, holding each one in a bit. This gave an immediate 25% speedup, confirming that going from an array of 10 booleans to 1 integer (reducing the number of items passed across) speeds things up. Next, since I wasn’t using the additional 4 axes I decided to only pass 2 axes as a temporary fix. This also gave a decent speedup, especially at the 6 controller mark, because each additional controller was additional data.

At this point I was stumped for a while, but then I realized that if I could pass a single JSON string across that would only be a single item of data, no matter how many joysticks or axes were active. I assumed that browsers were pretty good at parsing JSON, since that is most of what the JavaScript interpreter does on all web pages, and after a day of struggling getting C++ to spit out JSON it was legit and joystick input was no longer an issue.

Optimizing the Points

This finally exposed the remaining problems of the Point class and garbage collection being the next bottle neck. Due to all the physics updates and point computations it was creating tons of new Point objects and each additional point operation created more because the operations were non-destructive. The good news is that I have a full test suite for the Point class, so that I can refactor and optimize without any fear. This was quite valuable when testing crazy new ideas to see if they would improve performance without breaking everything. I figured that since I was creating so many points that if I added optional destructive methods, and used them in the right places, that could reduce the new point creation and also GC load quite a bit.

I wish that JavaScript or CoffeeScript would allow for a shortcut to use ! as a method suffix like in Ruby, because it is a known convention for destructive methods. The closest I could come would be point["add!"](otherPoint), which was too brutal on the mind and eyes to make it into common usage. If CoffeeScript could auto-compile point.add!(otherPoint) into the index-operator notation like it does with a.class and a.new then it would be okay, but until then the ! suffix is out.

JavaScript does allow for the $ symbol in variable and method names so, by necessity, I have chosen to use $ as the glyph of destruction, which has its own poetry in a way. point.add$(otherPoint) not bad, but not my first choice.

Now, armed with new destructive methods, I set about looking for places in the physics and collisions where I could slip them in to prevent the creation of unwanted/unused points. Then a funny thing happened, the majority of the places I looked needed the operators to be non-destructive, and it was difficult to see exactly where a destructive method could be added without unwanted side-effects except in a few simple situations such as point = point.add$(delta) => point.add$(delta).

While I was cleaning up the Point code I was thinking about a conversation I had on GitHub about the performance benefits from using prototype inheritance rather than object augmentation. This sounded like a good idea in this case, as Points are primitive objects with their x and y properties on the outside and all of their methods using this everywhere. The one sticking point was that I could not abide having to stick new in front of the point constructor in ten thousand places in my existing and future code. If only there was some way to get the advantages of prototype performance, without pushing the syntactic hassles onto the people using the class.

The good news is that there is a way to set an objects prototype. All you need to do is to set the __proto__ property. So now my Point constructor looks like this:

  Point = (x, y) ->
    __proto__: Point::
    x: x || 0
    y: y || 0

You know you’ve been programming in the browser too long when __proto__: Point:: becomes a thing of beauty.

All the instance methods are defined below as follows:

  Point:: =
    copy: ->
      Point(this.x, this.y)
 
    add: (first, second) ->
      this.copy().add$(first, second)
 
    add$: (first, second) ->
      if second?
        this.x += first
        this.y += second
      else
        this.x += first.x
        this.y += first.y
 
      this
 
    ...

This gives all the performance benefits of using prototypes rather than making an anonymous function for every method as well as the additional side benefit that developers can extend Point.prototype with additional methods for use in their own projects if they want to. Another advantage is that the syntax remains unchanged, no need to use the new operator, and all the tests still pass.

The best news is that this provides a 90% reduction in time that the code spends constructing and garbage collecting points, and was simple enough to pull into the Matrix class with a two line change as well. For primitive objects like Points, Matrixes, Arrays, Numbers, and the like I wholeheartedly recommend this approach. For complex objects that require mixins, private variables, and instance variables I don’t think it will be possible because each object actually does need it’s own functions that are in the correct closure scope.

Another interesting thing is that this last optimization voided the assumption of my previous one about destructive operators. I assumed that because creating points was expensive it would be worthwhile to go to extra lengths to prevent their creation unnecessarily. Using the prototypesque construction the cost of point creation and garbage collection was reduced so much that it’s not worth it to try and squeeze out the now slight performance gains that would produce except in the hottest inner loops. I’ll still keep the destructive methods around for situations where points actually want to be updated in place, like p = p.norm(speed) => p.norm$(speed), but I won’t be quick to begin trying to “optimize” by defaulting to using destructive methods and then spend hours debugging issues that come up because two objects are actually sharing the same point reference.

Points are cheap now, use them freely!

Asteroids

Matt — Sun, 12 Jun 2011 00:20:20 +0000

Greetings friends,

It’s been a while but we’re back with a brand new tutorial. Today we’re going to see how to make the old classic Asteroids in Pixie. I’m not going to copy/paste all the source, so you should follow along here.

I’ll start by discussing some of the nice things I did with the game while refactoring the code base. The first thing is modules. They are easy to make in Pixie. Use them.

In the game Asteroids, all the objects wrap around the screen edges. As a result, I extracted a wrappable module to define this behavior.

Wrappable = (I, self) ->  
  self.bind "step", ->
    I.x = I.x.mod(App.width)
    I.y = I.y.mod(App.height)

The code is very readable and concise. On each step we set the position equal to the current value modded by the bounds of the game.

We also see that there is access to some metadata via the App object.

Now all we have to do to give this behavior to other classes is to have a key called includedModules with the value ["Wrappable"] or self.included(Wrappable) in the class definition.

Even though PixieEngine is highly modular, we also support more traditional inheritance patterns. In the game I noticed that many of my objects had similar properties so I extracted a base class, extending the default GameObject.

Take a look at src/base and you will see a few key/value pairs, a default hit method, and a list of included modules.

With this base class and our recent module in place, let’s take a look at how easy it is to describe a bullet. Open up src/bullet and admire how few lines there are. The only thing we really have to say is, “Hey game, your bullet stays on screen for 40 frames. Aside from that it’s just your standard Base object.” Admittedly, the name of the module “Durable” doesn’t quite capture the intent of it’s functionality but it makes it easy to declaratively specify behavior.

Okay, we’ve gone over 1/3 of the distinct objects in the game (ship, asteroids, ~~bullets~~)

Let’s take a look at our hero, Ship.

Methods
shootPoints: this specifies the points where our bullets will exit the ship. We are defining two points relative to the center of the ship object (the bullets will shoot from the wings).

shoot: Notice the simplicity of the Sound API. We just tell the game “Play a sound. It’s called ‘pew’”. Then we generate one bullet per shootPoint, passing in the position of the ship and it’s rotation to orient the bullet properly.

hit (override): When hit by an asteroid, the ship will transition to an animation state called “explosion”. If you look at the last frame of the explode animation in animations/ship you will see that there is a tag “explode”. This means that the animation will trigger the explode event when it gets to that frame.

Events
explode: We call self.destroy() to remove the ship object from the game, tell the computer to play the explode sound from sounds/explode, and finally turn on the flag saying that the game is over.

step: This is the most important part of the ship class. Here we specify how the ship responds to player input. The first line illustrates a cool trick that D.X. Moore pointed out to me. It uses our number extension Number#approach to decrement the cooldown counter. Here we approach the number 0 by 1.

5.approach(0, 1) -> 4

We then check if the player just pressed spacebar. If yes, we shoot if the cooldown counter is 0. If the player is pressing left or right we update the rotationalVelocity appropriately. If the player is pressing up, we transition to the thrust state, set the acceleration, and play the thrust sound. If no keys are pressed we transition to the idle state and tell our velocity and acceleration to start approaching 0.

Two down (~~ship~~, asteroids, ~~bullets~~)

Open up src/asteroid. This class looks a bit nasty but it’s only because the method bounceOff, which does some elastic collision math so that the asteroids will bounce off each other in a cool physics-y way. Check out the math here if you want to read about what is going on. Ignoring that big method, the rest of the class is simple.

When it initializes it chooses a random position and velocity for the asteroid if you haven’t specified one already.

Methods
split: This method defines how the asteroid will splinter into smaller pieces when you destroy it. The large size generates two medium asteroids and the medium size generates 4 small asteroids.

hit (override): We override the hit method in order to transition the asteroid to it’s hit state (it turns red when hit by a bullet). When the asteroid is destroyed we increment a global kill counter, increase the player’s score, and then split the asteroid if it isn’t the small one.

Sweet. We have covered all the object types (~~ship~~, ~~asteroids~~, ~~bullets~~)

Now open up src/main. Note that we change the framerate to 60 with engine.setFramerate.

Methods
Most of the methods here are helpers.

collides: A simple wrapper on Collision.circle

addInstance: A wrapper to help add instances of a class to the game

loadBG: Loads a background in the game from a sprite.

resetState: This clears out the game objects, sets the score to 0 and adds instances of the ship and two asteroids.

gameText: Helps position the title screen and game over text.

Events
update: Here we bind the collision logic. We check each of the different object types to see if they collide with each other and then call hit if they do.

At the bottom of main we set up instructions about the game controls with parent.gameControlData

parent.gameControlData =
  Thrust: "Up"
  Turn: "Left/Right"
  Fire: "Space"

Finally, we configure the background music.

musicSrc = "http://daysofthecondor.com/wp-content/uploads/2011/06/chip.mp3"
 
bgMusic = $("").appendTo('body').get(0)
bgMusic.volume = 0.15
bgMusic.play()

The Legend of Danger Kitten (LD48 Post Mortem)

Daniel — Sat, 14 May 2011 02:10:35 +0000

Crossposted on the Ludum Dare Compo blog

In the Beginning
Going into the competition I didn’t really have any direction. After hearing the theme and looking at the kitten meme and the Zelda text I figured I would start off with an elf kid going into a cave and receiving a kitten rather than a weapon, but other that that I had no idea for gameplay or anything. I knew for tools I would use CoffeeScript and the PixieEngine (I have been creating PixieEngine for exactly these kinds of competitions and wanted to put it to the test). If you’re looking to try out a new development environment for easy publication to the web I recommend checking it out. It’s free! It’s still a bit rough around the edges but with your feedback we can make it better.

It was quick to get the initial level and cave in but I wasn’t sure what direction to take the game. I spent several hours on animating the sprites, drawing the kitten from reference of the meme. Art isn’t my strongest suit but spending time on it gave me time to think and I definitely could feel myself improving. After sleeping on the theme the first night I knew that I didn’t want to just have the cat act as a weapon, because that would be pretty plain and boring. I decided that it would be cool if you had to take the cat around to different dungeons and work together to solve puzzles. I had the idea to make the water impassible for the kitten around this time so that the player and kitten would need to work together to access different areas. I also spent some time getting the mew to sound right in SFXR.

I really wanted to focus on the emotional attachment to the kitten and to make it feel like you were helping each other. It is for this reason that the initial cave the kitten goes into narrows symbolizing a feeling of cramped/claustrophobic danger. This culminates when the kitten becomes trapped in a waterfall and the player is required to submit to entering the water and becoming helpless. Then when the kitten floats back out down the stream the player is given control of the elf character and must rescue the helpless kitten. The relevant psychology is that we develop good feelings towards those who we do favors for (similar to Portal’s Weighted Companion Cube). These locations, actions, and even the sound of the mew, were all designed towards the goal of creating an emotional bond.

The bombs were an ok addition, but didn’t have very much depth. It seemed like near the end of the game (especially at the ending) there was plenty of room to create a wide variety of levels and puzzles, but I had just solidified the core mechanic and core emotional experiences and the clock was still ticking down.

My brother was in town and late Saturday or early Sunday, in the course of viewing the game he came up with the idea for the ending. I spent several hours Sunday grossly copy/pasting and hacking the functionality in. This cost me a bit in terms of level design. An additional cost of adding screens was due to some excessive manual steps (like hand coding doors). In the end there were maybe 1.5 dungeons and 1.5 puzzles, but people really enjoyed the ending so I think it was a decent trade-off. As the level editor and game object tools improve it should become easier to add more levels with fewer manual steps.

All in all it went pretty well. I didn’t stay up too late or stress out much, but the time limitations were significant. Next time I should make a stronger effort to discover a fun core mechanic sooner to leave more time for level design. The risk of this is that I may lock down the mechanic too soon, before it is actually fun, but I think that’s the main conflict throughout game design.

The Good
The pixel editor, level editor, and sound editor integration in PixieEngine really helped me get a playable prototype up quickly. I was able to get a guy on the screen and moving around in minutes.

The API for many of the core components was simple to use. If I wanted to play a sound I would create it in the embedded SFXR, then call it by adding Sound.play("mew") at the appropriate place in the code. Similarly for loading sprites.

The engine Object Query Language was great for hacking together quick functionality engine.find "Player", engine.find "Item", engine.find "Cat" all came in handy.

Experience with CoffeeScript and the PixieEngine system was also a big plus. I knew what the strengths and weaknesses of the system were and was familiar with the workarounds (like using git integration to copy files to get around the missing “Save As” feature).

Publishing to the web was immediate and 100% hassle free because the entire engine is online to begin with. I didn’t have to spend anytime thinking about packaging or distribution.

I actually got to make a serious attempt at sprite animation, and some of the two-frame walk cycles actually look decent. Also the things I was drawing basically looked like the things they were supposed to. Still room to improve immensely but so far a personal best.

The Bad
As a home grown engine there were many parts that were still rough around the edges. The tilemaps and game engine had no built in concept of rooms, persistent entities, and transferring state from one room to another, so I had to just hack it in.

The file management was similarly rough: there was no “Save As” (though there is now because it was my #1 issue)

Our animation/model system isn’t as integrated as the sounds/images/tilemaps so I had to hack together my two-frame walk animations by hand.

Still don’t have an integrated music editor. I was able to do all the art and (most) sound effects from within the editor suite, but had no option for music. I really want to make some sort of online Mario Paint Composer style editor, but realize that it would be a pretty big project in its own right.

The lack of a shared “object toolbox” of all the classes of objects was a pretty big negative. This meant that for each screen I had to recreate the tiles by dragging them in, and manually setting their class and data properties. This especially sucked for doors where I needed to hand type the destinationPosition. The good news is that this is the next feature on our list and once it is fixed things are looking great!

The Best

Because I coded in PixieEngine, everyone is free to view the source, fork the game, make alternate levels, and more. (Though the engine is not quite “easy to use”. Your feedback is greatly appreciated!).

Though I wasn’t able to get in all the levels and puzzles I had hoped for this was still a personal best LD for me. I have had a great experience this LD and am looking forward to the ones to come. Additionally, all the feedback was helpful and it was nice to see that people enjoyed the game. If you haven’t yet, please play through and let me know what you think!

Hello Box2D

Matt — Thu, 14 Apr 2011 06:03:52 +0000

Now that we’ve done the obligatory Hello World let’s make something more interesting.

We’ve integrated Pixie with a JavaScript port of the excellent physics engine, Box2D. I’m going to show you how easy it is to leverage it in your Pixie games.

As before, you need to initialize your game engine. Paste the following into main.coffee

window.engine = Engine 
  backgroundColor: Color('sky blue')
  canvas: $('canvas').powerCanvas()
  includedModules: ['Box2D']
  PHYSICS_DEBUG_DRAW: false

The line to pay attention to is includedModules: ['Box2D']. This tells the engine that you want to enable Box2D physics. We make our game libraries as modular as possible so you aren’t constrained when you want to build that Frankensteinian aberration of a game.

Next, add the following

obj = engine.add
  color: Color('pink')
  dynamic: true
  includedModules: ['Physical']
  friction: 0.1
  width: 50
  height: 50
  x: 50
  y: 50

As with the engine initialization, you need includedModules: ['Physical'] so this object behaves according to the laws of Box2D physics. There are a few more important properties here. dynamic: true tells Box2D that the object is a dynamic body (one that moves), rather than static body. Lastly, friction: 0.1 assigns the object a coefficient of friction.

Next we want to make walls that our pink box can run into.

2.times (n) -> 
  engine.add
    color: Color('beige')
    includedModules: ['Physical']
    width: 640
    height: 10
    friction: 0.5
    restitution: 0
    x: n 
    y: n * 470
 
2.times (n) ->
  engine.add
    color: Color('beige')
    includedModules: ['Physical']
    width: 10
    height: 480
    x: n * 630
    y: n

There isn’t much new here, except for our extension method Number#times. It works just like the Ruby counterpart. Check out the documentation link in your file tree if you want to learn more about it. One last thing to mention is that we are setting the floor’s friction and a new physics property, restitution: 0, which amounts to bounciness.

The last thing we need to do is enable some player input.

engine.bind 'update', ->
  if keydown.left
    obj.applyImpulse Point(-50, 0)
  if keydown.right
    obj.applyImpulse Point(50, 0)
  if keydown.space
    engine.add
      color: Color('navy blue')
      duration: 75
      dynamic: true
      friction: 1
      includedModules: ['Physical']
      restitution: 0
      rotatable: true
      width: 10
      height: 10
      y: 20
      x: rand(600) + 20
 
engine.start()

We start off with engine.bind 'update', ->. This will execute the function we provide each time the engine updates. keydown.left checks to see if the player is pressing left on their keyboard and if so, applies an impulse to the pink box we made earlier. If keydown.space is true we add ‘rain’ objects to the system.

There are two new properties on these rain guys. First duration: 75 destroys the rain object, and the corresponding object in the Box2D simulation, after 75 engine updates. rotatable: true enables the rain objects to rotate based on the objects the collide with.

Finally, engine.start() starts the game.

Hello World

Matt — Tue, 12 Apr 2011 21:23:36 +0000

Let’s make a Hello World app.

First, create a new project on Pixie. This will include our core JavaScript language extensions and our game library extensions.

Put the following into your main.coffee

engine = Engine
  backgroundColor: Color("sky blue")
  canvas: $("canvas").powerCanvas()
 
engine.bind "draw", (canvas) ->
  canvas.fillColor(Color("Fuzzy Wuzzy Brown"))
  canvas.font("40pt Helvetica")
  canvas.centerText("Hello World", 100)
 
engine.start()

There are only a few important lines for getting something on screen.

The backgroundColor key does exactly what it sounds like, it tells the engine what color to fill for your background.

Our color library can make a color out of many different inputs: 3 numbers, 3 numbers and an alpha value, an array of 3 or 4 numbers, hex values, rgb and rgba strings, and also just plain strings for named colors. We recognize around 2500 named colors, including these.

canvas.fillColor and canvas.font set the colors and the font.
canvas.centerText writes the text centered at the given height.

Run the project and you should see “Hello World”.

If you are feeling adventurous try replacing Color("Fuzzy Wuzzy Brown") with Color.random()

PixieEngine Launched!

Pixie — Tue, 12 Apr 2011 11:34:27 +0000

The PixieEngine is a web based game development environment that makes use of modern technologies to enable magically rapid prototyping, development and deployment.

Because it is on the web game developers are free to create from anywhere, and sharing is instant. Collaborating, experimenting, and gathering feedback have never been easier! Get started right away with our demo application. For another example look at the simple, 10-line Hello World demo.

Our use of open web standards enables us to integrate easily with many free and open source libraries, leveraging the work of diligent creators worldwide. Box2D physics integration is only a few lines of code. Github integration runs deep, we edit all of our core libraries using the same tools we use to make games and push them straight to github.

Watch Laser Shadow Deathmatch Arena for real playtest footage of yet another game developed with the Pixie engine. Or explore the Mystic Cavern.

It’s important to us that our users have all the storage and freedom they need to make games, so we created Pixie Premium accounts to ensure you’ll have ample storage space for all your projects and game assets.

PixieEngine is undergoing active development so your feedback is very important. Give it a try and let us know what you think!

If you have any questions or comments don’t be afraid to contact us! We’re more than happy to hear from you and will get back to you as soon as we can. Anything from simple support to detailed technical questions is fine.

Keep up to date by following this blog, or our twitter account. Visit our forums get involved and to share your creations with the community.

Now go forth and make games!