During my day job I create PowerApps fairly regularly for both clients and internal use. The platform has come a long way in a very short amount of time and has gone from interesting idea to amazing enterprise accelerator. So what did I decide to do with all that enterprise capability? Create a game of course!
PowerPush: Dungeon Explorer 3000!
PowerPush is a Sokoban clone made entirely in PowerApps. It has 6 levels, 4 playable characters, music, sound effects, supports right and left handed players, and has only 4 screens.
PowerPush is open source (in as much as PowerApps can be) and you can import it into your tenant to give it a whirl and take a peek under the hood. There are no data connections at all, so it really is as simple as importing and playing.
Get it here: PowerPush.zip
Why?
To push myself and learn some stuff I wouldn’t necessarily learn by creating another form wrapper app. Believe me, I learned a lot! Number one thing I learned was that PowerApps really isn’t a great platform for making games. However, I also learned several really cool techniques (“wonky hacks” might be a better term for several of them). I’ll talk more about some of these below but I’ll also be following up with some individual tips and tricks in the next few weeks.
How it works
There are a lot of pieces to this app, and the best way to understand it is to just download it and take a look. But here are some details about each of the screens:
Screen 1: Main Menu
When the app starts, several global variables and collections are initialized. The most important of which is the levels global variable. This is an array of level objects that define the tiles to be used and details about where the crates start and where they should end up:
The levels object is later processed into a set of context variables and collections to manage current state for the active level and provide details about which image to use for each tile and whether those tiles are solid, etc.
The main menu has some animation based on a timer, but otherwise there are simple controls to set global variables used on other screens (like the character).
Screen 2: Level Start
The level start screen simply shows the current level details along with a randomly selected “tip”. This screen uses the fade navigation to create a nice transition into the level. You can also click anywhere on the screen to skip the automatic navigation based on a short timer.
One of the key things it does, however, is to process the level object into some key collections:
Set(activeLevel,Last(FirstN(levels,currentLevel)).Value);
Set(tiles,{
background: ForAll(activeLevel.background,{
img: LookUp(imgMap,id=Left(Value,2),img),
solid: Right(Value,1) = "1"
})
});
ClearCollect(crates, ForAll(activeLevel.start.crates, {x:Value.x, y:Value.y}));
ClearCollect(torches, ForAll(activeLevel.start.crates, { on: false}));
UpdateContext({tip:First(Shuffle(tips)).Value})
More details will later be pulled out of the activeLevel object to set up initial state for the player, but the info above determines how many crates are visible and where they are along with key information about the tiles. By using an image map collection we can use the strings setup in the level (first 2 characters are the tile image and the last indicates if the tile should be “solid”).
This step greatly simplifies level design by making it a simple array of strings so that you can almost visualize the level while you design it. By processing it here, we get easily usable values in a collection that tiles can reference details from by index.
This is how we can have one screen for the main game with any number of levels! This lets us simply bind to a data model and write logic (movement) to update that model. This is the area that PowerApps really shines.
Additionally, we could easily provide multiple image maps to create “themes” for levels to allow the same logic to apply a completely different tile set. The tile objects could also be extended to provide an additional layer of tiles for foreground elements if we wanted using nearly the same logic.
Screen 3: Main Game
This is where all the levels are shown. The tile system is based on 140 images laid out in 10 rows of 14 columns. Each of these tile image controls hijack their own BorderThickness property to store their “index” value. This works because the BorderStyle is set to None (so that value isn’t used).
This “index” value is used to position each of the individual tiles (the number of tiles, size, rows, columns, etc. can all be changed through some simple global variables). The “index” is also used to pull what the image should be by referencing the tiles object’s background array (shown above).
While not easy, you can reference an item within a collection by index by using this non-obvious formula:
Last(FirstN(tiles.background,tile043.BorderThickness)).img
The actual movement logic is handled in a single spot. There aren’t really global functions in PowerApps, but I’ve got something pretty close in that I’ve added a timer with a Duration value of 0. Then I set the AutoStart to a context variable. In the OnTimerEnd action I update any variables as needed and finally set that same AutoStart context variable to false.
So now to call that “global function” I simply need to call an UpdateContext function. In that call I update any “parameter” variables the global function will reference and set the AutoStart variable to true. For instance, here is the OnSelect for the Left button of the virtual D-Pad:
UpdateContext({requestedMove:{x:-1,y:0,rot:ImageRotation.Rotate180},evaluateMove:true})
Just to show you the power of the “global function” approach, here is the OnSelect for the Down button of the virtual D-Pad:
UpdateContext({requestedMove:{x:0,y:1,rot:ImageRotation.Rotate90},evaluateMove:true})
Both of these calls are nearly identical with the only exception being the “parameter” variable requestedMove.
The key part, however, is that evaluateMove:true. This will cause the timer to start and because it has a Duration of 0 it immediately performs it’s OnTimerEnd actio. This was really important because the move evaluation logic is pretty complicated and I really didn’t want to cut and paste it with some minor tweaks between 4 different buttons. That would be pretty hard to maintain.
The actual move evaluation uses a series of If statements and looks at the tiles collection to determine the current positioning of objects to determine if the requested position of the player is open and what should happen (push a crate, play a grunt since he hit a wall, etc.). It’s pretty convoluted, but you can see that some pretty complex logic can be performed to update our positioning elements (which specific controls like the player or the crates are bound too). Because of the power of PowerApps, all of the controls redraw themselves automatically just by our editing the model!
"Handle movement";
"If no wall in this direction";
If(!Last(FirstN(tiles.background,(playerY+requestedMove.y)*14+playerX+requestedMove.x+1)).solid,
"If no crate in this direction";
If(CountIf(crates,x=playerX+requestedMove.x And y=playerY+requestedMove.y) = 0,
"No crate, just move the player";
UpdateContext({playerX:playerX+requestedMove.x, playerY:playerY+requestedMove.y, playerRot:requestedMove.rot, playerPushing:false,playSndWalk:true});
Reset(audWalk),
"There is a crate, see if it is up against a wall";
If(!Last(FirstN(tiles.background,(playerY+requestedMove.y*2)*14+playerX+(requestedMove.x*2)+1)).solid,
"Not against a wall, check for another crate";
If(CountIf(crates,x=playerX+(requestedMove.x*2) And y=playerY+(requestedMove.y*2)) = 0,
"Push that crate!";
UpdateIf(crates, x=playerX+requestedMove.x And y=playerY+requestedMove.y, {x:playerX+(requestedMove.x*2),y:playerY+(requestedMove.y*2)});
UpdateContext({playerX:playerX+requestedMove.x, playerY:playerY+requestedMove.y, playerRot:requestedMove.rot, playerPushing:true,playSndWalk:true,playSndPush:true});
Reset(audWalk);
Reset(audPush),
"Can't move the crate or player (crate against a crate), but update player look";
UpdateContext({playerRot:requestedMove.rot, playerPushing:true, playSndGrunt:true});
Reset(audGrunt)
),
"Can't move the crate or player (crate against a wall), but update player look";
UpdateContext({playerRot:requestedMove.rot, playerPushing:true, playSndGrunt:true});
Reset(audGrunt)
)
),
"Can't move the player (wall), but update player look";
UpdateContext({playerRot:requestedMove.rot, playerPushing:false});
If(Rand()<.5,
UpdateContext({playSndHuh1:true});
Reset(audHuh1),
UpdateContext({playSndHuh2:true});
Reset(audHuh2)
)
);
"Check crate positions";
ClearCollect(prevTorches, torches);
ClearCollect(torches, ForAll(crates, {on:CountIf(activeLevel.start.targets, x=Value.x And y=Value.y)>0}));
If(CountRows(Filter(torches,on=true)) CountRows(Filter(prevTorches,on=true)),
UpdateContext({playSndIgnite:true});
Reset(audIgnite)
);
"Check for Win";
If(CountRows(Filter(torches,on=true)) = CountRows(activeLevel.start.targets),
UpdateContext({finalDescent:true});
Reset(audMusicWin)
);
UpdateContext({evaluateMove:false})
Screen 4: Credits
This is a really simple screen that has a gallery bound to a custom credits collection. Then the Y value of the gallery is set based on a timer value to provide the scrolling animation. The timer is on a loop, so the scrolling is too.
This screen really exists to thank the tile artists (used with permission, but still greatly appreciated) and to make my kids happy (they’re the testers listed above).
Lessons Learned
I’m going to post a few different techniques I used as separate articles over the next few weeks, but there are several pain points I identified that I’d love to see solved in the future. Here’s a few:
Need for a this operator
You refer to a control by it’s name in your formulas. This works great. Even better, if you copy one or more controls they’ll get renamed and all the formulas updated. This is super powerful. But… if you suddenly need to update that formula on multiple controls (say 140 tiles), you can’t just select them all and update their formula because all of those formulas are now unique because they refer to specific controls. Simply introducing a this keyword that would refer to the current control in it’s own functions would be awesome.
Additional Idea Entry – Go Vote!
Audio should pause in the editor
Currently, if you loop and play your audio file it will continue to play even in the editor. This is weird behavior since, for instance, the timer stops running in the editor. This means if you do something like add really annoying techno music (see video above), you’ll never escape it.
True Image Rotation is needed
Right now you can flip an image control horizontally or vertically and you can rotate in 90 degree increments. It would be far more powerful if you could specify an exact degree of rotation. This would make animations far better.
Custom Object Props Please
To simplify things, I shoved an index variable for the tiles, crates, torches, etc. into their border width property. This works because I wasn’t using this property (BorderStyle: None). This made creating multiple controls that knew what variables to pull from far simpler. However, it would be even better if we could just associate custom properties of a given type directly on controls instead of hijacking an unused property (since this could have unintended consequences).
Reference Media by Name (text)
When you assign an image to an image control you do so by the Media variable. This is true for other controls as well. This is fine, but it can make dynamic assignments difficult since the control will need to be able to reference (know about) the actual media variables directly. I solved this using an image map collection so that I could build strings and then find the referenced image that way. This works pretty well, but it would be even easier if there were just a Media(“MediaName”) function.
Support for Key Down Events
PowerPush was designed for touch controls on a phone using a simulated d-pad. This works, but is clunky for the web. It would be far nicer to move with the arrow keys. Unfortunately, there isn’t a key down event to do this.
Update
I demoed the game on the SharePoint Patterns and Practices General Development call on 1/24/2019. Check it out here:
The Chris Kent 
[…] https://thechriskent.com/2019/01/24/making-a-game-in-powerapps-powerpush-dungeon-explorer-3000/ […]
This is awesome!