Skip to main content


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Beaker

Game Development / Wizard Kings

Download here:

Wizards Kings is a turn based strategy game where you go to war with a rival wizardom. Each turn, assign work to increase your economy, use your economy to increase production, or use it to increase your spellcraft. Then with your production and spellcraft, create units to send to the enemy during the raise phase.

There are three fields. During the orders phase you can click to select a unit you control and then click a neighboring field to send it there. If there is an enemy on that field, units next to each other will fight during the combat phase. A unit on a field can move itself to the right end of the line by clicking the right end of the field when it's selected.

Combat is determined by the unit numbers: attack, health, and reach. During combat, the unit with the highest reach attacks first and reduces the hp of the other by the amount of attack points. Then, the reach number is reduced and that unit attacks again. If the reach number is the same, then both units attack. This continues until the reach number is at zero, or one (or both) units are defeated. So a unit with reach 3 against a unit with reach 1 will attack twice (reach values 3 and 2), and then both units will attack each other
for the next reach numbers of 1 and 0.

When you have your units in your opponents field, then if there are no enemy units there then you will attack. If there are 1 or 2 units attacking, then they will remove some production from the enemy. If there are three or more units there, then they will attack the walls with their combined attack values.

The first player to reduce the opponents walls to 0 wins!

The Controls:
Mouse: Click on buttons and units
Space: Skip to next phase (if not the assign phase)
Escape: Deselect unit

This was made at TOJam this year, but it took me a while to get the time to finish it up, and then some more to upload it.
Game Development / The Other Adventurer 3D

Find the magical golden goat of glory inside the deadly dungeon. You have entered, and lo and behold! It lays right in front of you! But, it is across a gap too wide to reach. You are so close, but so far apart. Explore the dungeon and beat the 4 magical boss slimes to unlock the way into the evil slime king's lair. After he is slain, the path to the treasure you desire will be unlocked! But the way is long and dangerous, so be sure to restock your supplies in the nearby town and ask the townsfolk for helpful information.

Made at TOJam 14.

Download here:

-WASD to move
-Left mouse to attack
-Right mouse to block (sword & shield only).
-E to use (eg: open chests, talk to people)
-1-4 to switch weapons
-Space to jump
-F5/F8 to Save/Load (not yet working)
-F1 to show help
-Escape to quit

Spoiler (click to show/hide)

So this is a simple 3d fps made with Sphere 1.5, using transformBlits for the 3d drawing.  Since transformBlits use affine texture mappings, I allow for up to 16 subdivisions of the quads to help with the distortions (as well as issues around quads spanning between being in front of the camera and behind it).  The engine limits out at about 400 quads on screen at once, which I've noticed before with The Rainis Manuscript with how transformBlits are done in Sphere v1.  As a result, it has an adorably early 90's frame rate.  Also, the distance sort function is a little off, but I couldn't be bothered to fix it.

Game Development / Zell Menace
Zell Menace

Sorry for being a bit late with posting this one here.  Zell Menace is a vertical shooter made during TOJam 13, a weekend game jam hosted every year in Toronto in May. Instead of the typical powerups and bullet-hell of shooters, this game has money drops so you can upgrade your ship, and shield/armor so your ship can take multiple hits of damage (in this regard, similar to Tyrian). However, you only get one life to beat the game, so be sure to upgrade your ship so you can make it through the 5 levels and beat the boss.

The Default Controls:
Move ship: Arrow Keys
Fire Lasers: Space
Fire Homing Missile: Control
Upgrade Forward Weapons: 1
Upgrade Diagonal Weapons: 2
Upgrade Homing Weapons: 3
Upgrade Generator: 4
Upgrade Shields: 5
Upgrade Engine: 6
Upgrade Armor: 7

Game Development / Re: The Screenshot Thread

Currently at chapter 4 in the graphical and story rewrite.  Still lots to do...
Sphere General / Re: Proper way of using Sphere?
Looping music, in particular mp3, has it's issues because of how the format is designed.  The fundamental problem occurs because of this:

You can read further into that if you want here, and while there are ways around it for mp3, it's flaky.  Some engines like Unity can get around it by accounting for the delay and padding programmatically/doing processing on the music file (this is more like what Rhuan was saying with changing the position).

To get looping working for music, the best way is to render it into .ogg format and then test how it loops in a good audio editor (eg: Audacity [it's free]).  If the music should be looping well, but there's a seam or click at the looping point, then you have to go down to the sample level of the audio file and make sure it starts and ends at the 0 volume point.  With monotracks you can do that by cutting off a few point samples, but with stereo tracks the easiest way is to fade out the music over the last few sample points and fade in the first few.

In the above, it can't cut be off correctly in stereo, so instead fade it out over the last 6 samples.  The 6 samples here will only last 1/10 of a millisecond, so it won't be noticeable to the listener and should get rid of the click sound.

From there, in sphere, you should be able to play it with repeat as true and it should loop just like in audacity.

If however, you're talking about more precise looping like, pay this part and then start looping this part, then you'll either have to do it in code by playing the first part and then fading in the loop when it should start (as two separate files would probably be easiest here), or maybe using a tracker format like .mod (more limited in terms of what it can do, but does have more complicated looping options).  I'm not sure if .mod is supported in miniSphere though.
Hellos and Byes / Re: So sphere is still a thing!
Hello again.  Any description of your game company, or the games they make?  A lot of the indies I know are using unity, and it's probably the most popular engine/framework for a team to use at game jams that I've seen.

Sphere General / Re: Promoting Sphere?
Regarding that resolution switch: I was under the impression you couldn't do that in Sphere 1.x without actually forcibly rewriting the .sgm file and then calling RestartGame()?

Yep, that's called changing resolution mid-game in 1.x.  Also works to limit heap size growth if that's an issue for you and it's 2005.

Doesn't work for changing the graphics driver though.
Sphere General / Re: Promoting Sphere?
If you're referring to miniSphere with this, it's about to get even more exciting, as I'm switching to ChakraCore--a modern JS engine with JIT (so performance blows Sphere 1.5 completely out of the water) and native support for pretty much all of ES6 including modules.

I was referring to TRM instead.  In terms of engine updates, there hasn't been much added since 1.0 that I've needed (a few features here and there but not a lot).  The main benefit of upgrading versions, especially for TRM has been to use an engine that's stable under current operating systems and allocates enough memory to the JS heap to allow the scripts to run (TRM was dead for a while between 1.101984-1.2 [I think, whatever the last crazy version number was] because of this).  Performance hasn't been that important since TRM was initially designed to run on Pentium 2 era machines (300-500mhz), and for the type of stuff I'm interested in doing (mostly pure pixel art, fairly low res), the engine has been fast enough for quite some time.  While performance issues can always (well, usually*) be worked around by being creative, it's the hard limit stuff like the draw order of map sprites (RTD:E**), bugs because of newer OSes, or something like steam integration that is exciting to me.

But getting back the main topic.  A lot of people seem interested in that steam integration, I guess because even if one doesn't really want to commercialize their game, the possibility of doing so is appealing, especially to someone starting out.  Besides that, are there other things that a fully commercialized game should have?  For instance, in Sphere-v1 (I haven't looked deeply into miniSphere yet), while you can change the resolution mid-game, you can't change the graphic drivers, which means you would have to make your own prelauncher to do something like that since most games don't expect you to go to the install folder (or the program files menu) and run a different .exe to change configuration - you just click play in steam or on the desktop icon and then change it in the prelauncher or the game itself.

(*) RTD:E needed to use its own build of sphere to get around the fact that GetPerson calls were being mapped from the person's name to the person_id number via an array lookup.  That's fine for a low number of sprites, but for updating a large number of sprites at once (for example, gore globs or large number of enemies) would quickly slow down with increased numbers of persons on the map.  Rouge Rogue Rabbit Puncher also had this problem, but only after defeating the mid-boss.

(**) The draw order of the sprites on each layer was determined by sorting the y-position of the sprites in vanilla sphere.  This is reasonable for an rpg, but for a platformer where a lot of sprites are on the same y-value and can overlap, it makes a lot less sense when you start seeing the sprites glitch in front and behind each other, so RTD:E set the order to be fixed instead.  By now, it may be reasonable to implement pure js map engines, which would make patching something like yourself this just a matter of loading the js library and overriding some functions instead of asking for a feature request/building the engine yourself.
Sphere General / Re: Promoting Sphere?
I think marketing sphere with some kind of notable game, released on steam, would make a lot of sense.  So, some kind of library to support steam achievements (maybe some other platforms) would do a lot to tell indies that sphere is a viable engine to make and release a game.  Once there's attention, that's when good tutorials become really important.

I have been considering a steam release for The Rainis Manuscript.  First I have to finish rewriting the dialog and adding the new scenes, then finish tweaking the new battle engine, then get it working in miniSphere (currently with 1.5 it crashes quite a bit due to what I *think* are segmentation faults, but I haven't looked into the actual error), then consider adding in other features like multiplayer networking, QA and finally release.  Over the past year it's become a lot more compelling, and I'm more excited about it now than I have ever been before.  While there are no modifications needed to release on steam itself, having support for achievements in particular would certainly be nice, even if it's just some kind of external library interface.

I know other indies would be interested in trying out new engines and technologies at game jams when they hear about someone else using it, and at least one person I know was interested in trying it out after seeing me use it at TOJam for the past 9 years (though probably more half-heartedly since he's really used to making games in unity).
Firstly, I want to say that when it comes to optimization, never ever assume something is faster "because it should be."  Besides the issue of testing your assumptions, there's also the problem of readability/understandability vs speed, and if you're going to be sacrificing one, you'd better be making up for it with the other enough to warrant the change, and you better know how much you're gaining in one area over the other. 

Case in point, the ++i vs i++ debacle in C++.  When i is an integer, it's argued that ++i should be faster since it increments i, and then returns it (2 ops), instead of i++ which stores the value of it, increments i, and then returns the stored value (3 ops).  Since the 486 era of cpus, these two should actually go the same speed since each core of a cpu can do a limited number of operations in parallel (if the operations are independent of each other), so both end up returning after 2 ops.  Moreover, in the case of loops, i++ should actually be faster since it can do the loop check while it's storing i, so if the value of i is not immediately used in the loop, it can start the loop after 1 op whereas ++i has to increment the i and then do the check.  But, really this is all a mute point because compilers will optimize out stuff like this anyway, so why the hell bother in the first place?  If your code needs to know the difference between i++ vs ++i, then you're making your code more complicated and harder to understand for an optimization that doesn't even exist anymore.  The only case where ++i vs i++ makes a difference is when i is a complicated class and you're overloading ++ (though I'd worry about this as well since it's also potentially making the code less readable).

So the moral of that story?  Don't listen to other people, and test your optimization assumptions to make sure there is a speed gain and that it's worth the reduction in readability.  Don't even listen to my argument above, test the difference between ++i and i++ yourself in your compiler, language etc.

Ok, with that out of the way, I would always use the standard for loop to add stuff to an array.  For the reverse fill example you gave, my guess is that JavascriptCore doesn't realize that your array is going to be a fixed-size array and should be implemented as a list type instead of a hashmap.  Once you do it in the forward direction the compiler figures out it should be working on a vector and does it that way.  Then with the fixed size array, it knows from the start how big to make the list ahead of time.
I'll put some of my cents in.  I'm not sure if this will be helpful.

The first organization of code that I do is state vs representation.  The state says what is currently in the game/battle system, while the representation shows the graphics and sound.  The representation parts never modify the state, and are idempotent (running it twice gives the same output both times), and the output is determined by the state.  The last required part is the code that updates the state.  It only modifies the state based on the current state and user input.  In programming speak, this is the model-view-controller idea. 

Second, when making a battle system, you have to determine if you need a scripting engine or not.  In some cases you do, but most cases not so much.  In an engine it's possible to have multiple actions happen at once (for example, multiple people moving at the same time in the default map engine), but there's added complexity with the control flow.  An active battle system like FF6, should be in an engine since a monster can attack while the player is in a menu, while a turn based system like Dragon Quest can be done without one.  Without an engine, the battle loop goes through the players and enemies running the DoTurn(character) functions until victory or defeat, and the control flow is much easier to follow.  In an engine, the engine is constantly running and you're queuing events to happen n units of time later, which breaks the control flow, but is needed.  In short engines are asynchronous, so only create one if you need it.

Third, don't be afraid of globals.  You're making a game by yourself, it's not a web application.  I could give a long speech about what is a global, what is not a global, and what types of globals there are, but in short for this, the rules change according to what the program has to do and how many people are working on it.

Fourth, get a non-moving spec in place for what the battle system has to do before anything else.  Once you're fine with what you have to make, start with the most abstract layers and lay them out, and work your way down through the abstraction until you're done.

Game Development / Re: The Other Adventurer

Question for you Beaker: how much of this game's engine (map handler, movement, combat etc) did you write in the 3 days? If you did all of that as well as making the maps that is insanely impressive.

All the code was written from scratch starting at the beginning of the jam.  It came to about 2500 lines, the same as RRRP, but I felt like I got a lot more done this time around since I was able to do other things besides mainly coding during the jam, like I felt I did with RRRP.  There's 80+ maps in the game, which is an improvement over GaMc, which had more like 40.

You do three day game jams for ten years, you get good at getting stuff done in those three days.
Game Development / Re: The Other Adventurer

Hm, somehow I didn't know about that function.  Go figure!

I was going to mention it, but I forgot.  I've done it a bit before in order to do things like 2x+ scale factors, though the scaling of the tiles isn't that good at times (depending on the driver). 
Game Development / The Other Adventurer
The Other Adventurer is a short action RPG in the style of the original Zelda, made at TOJam 12. You must explore a dungeon maze and collect the four elemental keys to unlock your path into the lair of the final boss and save the princess.

The jam's theme was "Prepare For Disappointment," which should explain itself as you play the game.  My guess is about an hour to beat. Saving/Loading can be done by going to the screen to the south of the starting screen and moving over the save/load section for the three save slots.

Arrow Keys: Movement
Space: Sword attack
Ctrl: Fire bow (when obtained)
Tab: Toggle minimap
M: Toggle music

Engine Development / Re: miniSphere 4.5.10
Good to know.  When I'm further along the development process for TRM, I'll send you a release to help debug some more issues.