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

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.
Game Development / Re: The Screenshot Thread

I went "woah..." the second the image loaded. Impressive work. :)

When I started making the images for the first battle tutorial, I noticed that they had a bit of a msdos style to them.  I started on some bigger images and it seems the key takeaways to the style is realistic proportions and colors, grit, and extra use of grays and browns... at least for the style I'm interested in. 

The style seems easier to do, but also takes way longer than more modern styles it seems.
Engine Development / Re: miniSphere 4.5.9
It's a problem with drawZoomedText.  Using drawText will render correctly with the semi-transparent pixels, but drawZoomedText with zoom set to 2 or 1 will not draw them.

Code: [Select]

// main.js automatically generated by Sphere Studio
// Vanilla compiler plugin
font1 = LoadFont("main.rfn");
font2 = LoadFont("main.rfn");
var c = CreateColor(255,0,128,255)


function game()
var txt = "SeT GQwWoO!";
while (true)
font1.drawZoomedText(0,0,2,txt);//renders without alpha
font2.drawZoomedText(0,20,2,txt);// ..

font1.drawZoomedText(0,40,1,txt);//also renders without alpha
font2.drawZoomedText(0,60,1, txt);// ...

font1.drawText(0,80,txt);//Render correctly
font2.drawText(0,100, txt);// ..


Engine Development / Re: miniSphere 4.5.9

There indeed shouldn't be much effort needed to migrate - almost all of the Sphere 1.5 API is implemented.  I tried to make it as painless as possible to phase in the new features too - in large part you can mix Sphere v1 and v2 functions freely (objects are not interchangeable, however).

There's really only a handful of stuff that's not implemented, mostly some esoteric APIs like Complex() and a few surface blend modes (because they're impossible to implement with the OpenGL fixed-function pipeline), but otherwise everything should work correctly.  There shouldn't be any issues with fonts though; what kind of bugs did you encounter there?

In the case of the font, it seems to either switch to a default font instead of the font loaded, or just not draw the transparencies of the font.  As far as I can remember, the only special things done to the font was possibly a color mask and doing the zoomblits.  In the case of the images, it seemed to be transparencies with zoomblits (basically, everything is a zoomblit).  Doing a quick re-look, I can't find the transparency with images problem, but I found a new bug wherein the restart(); function doesn't seem to reread the .sgm file like Sphere 1 does.  Sort of.  The first restart to change resolution works well enough (it doesn't work the same with the 320x240 option, but I assume that was deliberate), but the later restarts which were added to get around out-of-memory issues of (hopefully) yesteryear cause the engine to restart at the options menu instead of going to where it left off.

I also noticed some other differences as well with I think off-by-one pixels when drawing lines of text character by character vs drawing all the characters at once (a bit hard to explain, I'll have to send you a demo to explain that one).  When I finish the rest of the game, I can move over into doing the port fully, and give you a comprehensive list of the things I find.

In terms of the fonts, here's some screenshots:


Engine Development / Re: miniSphere 4.5.9
I'm in the process of porting The Rainis Manuscript over to miniSphere.  It seems very little is actually needed to get it to run, but I have noticed a few graphical bugs involving transparencies and fonts.  It's been a few months since I ran it last since I'm still working on the game proper, but I could try it again if these are not known issues.
Game Development / Re: The Screenshot Thread
A lot of the new battle engine is done, so I started working on some tutorials and redoing some of the intro graphics.  Decided to practice imitating an early 90's vga style.