By popular demand (and burning need for my game to be playable on platforms other than Windows!) Dr. X’s Rainbow Arena now supports keyboard only gameplay! No longer are you bound by the length of your 360 controller’s cord, or lack thereof, when you wish to partake in the development of the greatest nano-virus the world has ever seen! ADVANCE!
http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=15756
– The Chemist
WOULD YOU LIKE TO ENABLE STICKY KEYS? no
However, I would like to make a multiplayer game for LudumDare! How is this possible? Telnet. Yes, telnet, you read that right. Using the Boost async IO lib my intent is to make my game as a small, text based multi-player experience.
It’ll be written in C++ using Visual Studio for primary development and GCC for the linux server builds. I’ll probably use my JSON library LawlJSON (https://github.com/chromex/LawlJSON) for data and maybe my factory system LawlProps (https://github.com/chromex/LawlProps) for loading preset objects from file.
Does this make me a mad man? Why yes it does. I have no idea how I’ll get to test the multi-player elements to a meaningful extent while pursuing development but that is part of why I’m interested!
Anyways, if you want to track me I’ll be posting to my blog PublishingNothing.com and my project source code will get posted to https://github.com/chromex/gamejaming as I work on everything. Also, I hope to have a live server up, running, and crashing the first day so I’ll post a link to when its up.
ONWARD, FOR STICKY KEYS.
Multiplayer! With telnet! Yeah!
Players can connect, create accounts, and issue basic commands to the server. A basic data layer has been implemented, multiple telnet clients have been tested, and it is finally time to implement the gameplay.
All of the code and my notes can be found at: https://github.com/chromex/gamejaming
The premise of the game is that everyone is establishing contracts to make money. Before a contract can be established the two users entering into the agreement specify how much they’ll put forward (public) and if they would like to stab the other guy in the back (private). Once both bids are in, the contract is established and lasts for an agreed upon amount of time. The longer the time, the more money is made. However, in normal prisoners dilemma fashion, to really win you have to screw over the other person. Since a user can only have so many open contracts at a time, not earning money on a slot can be super bad (TM).
More to come and I can’t wait to bring the server live tomorrow night!
It is done! A from-scratch multi-player game in 48 hours! I can only hope I draw enough players for it to be fun, hehe.
http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=15756
Plan is to use purely Pico-8 for the jam. It'll be a fun switchup from previous jams using Flixel, Unity, or even straight C++. Also looking forward to the fact that I've setup a jam space for some friends to join in as well. Hard to be a communal experience for an otherwise solo jam.
Ludum Dare 40 was, as is normal, stressful. While I was trying to finish in 48 hours to qualify for the compo, the scope of my project and the amount of testing and polishing required was at odds with the goal. My final build was uploaded a nice 20 minutes prior to the close of the jam and in the preceding (almost) 72 hours, I believe I worked about 45-50 of them. During this time, I revisited the story progression three times, published 63 builds, collected bugs and feedback from 10 different testers, and fell pretty far off of the caffeine-free wagon. Again, stressful.
The game itself that I set out to make was an incremental/clicker game using pico-8. We are all familiar with incremental games now, but only a few years ago games like Candy Box! set some of us loot addicts on fire but were otherwise unheard of. While they aren't really considered "games" by most, they leveraged progression systems that were being spearheaded by popular social and mobile games. Most critically, these games use the timed release of rewards against a certain amount of perceived effort to create a positive feedback loop of engagement.
While these games inspired me, I wanted to try something a bit different. Most of them depend on conveying information relatively directly. Numbers like "cookies per second," "wire per second," and how many factories you own are generally up front as a statistic. So I set out to try to create this style of game but where all but one number is displayed in a more abstract visual form. Some are still overt such as a crate representing a certain unknown number of marshmallows and which is worth $20 if you watch, but others are less so such as the speed of the loader automatons and what a speed improvement means for them.
This meta goal created an interesting problem. Without the numbers to focus on, everything else needed to be both entertaining but also visually meaningful. According to feedback I managed to meet this challenge with some success. The crying robots, the news ticker across the top, the weight gain of customers, and other elements all created an environment where it was fun to watch, try to see what was changing and what your actions meant.
Unfortunately, all of this richness (cough complexity cough) also created a problem. See, when I set out to create my game I didn't have a clear path on how to build it. These games generally depend on a tapered rollout of gameplay elements, with phases gated on time, player triggers, resource triggers, and sometimes just RNJ prayers. Only having an inkling of what this really implied for the implementation, I started building my game around a primitive manual trigger system and hand coding each individual element in a system easily controlled by such a basic scheme.
The result? A game with a number of totally unique game objects but no game object concept, just a system of uber controllers and their draw calls. Smattered amidst this are magic numbers for the triggers, duplicated logic segments, and generally a complete mishmash of "engine," gameplay, input, and system management code. This was all exacerbated by my determination to do all of it "the pico-8 way" and not use an external editor which made mid-session refactoring extremely tedious as pico-8's code editor is put down by all but maybe ed.
While I'm happy with how the game turned out for the jam (it's fun and short), I'm less pleased with what I shipped in general. I'm setting out to release a V2 of the game with audio, overhauled progression, and a slightly longer story that may gasp take a day or two to beat if you want to leave it running in traditional incremental game fashion. I plan on documenting this process and the horrors that I committed across those first three days so check back for progress on my quest to right my wrongs here or on my site loren.io.
If you'd like to try out the game in the meantime (and who wouldn't, its GOTY material) you can find it here: Happy Happy Marshmallow Factory
o7
Where to start. In between getting ready for the holidays, crafting presents, visiting friends, and playing games, I’ve spent some time refactoring my LD40 game. Sadly, that work has been everything but fruitful for the most part. Let’s start with what has been done and where we started.
To begin, pico-8 reported that Happy Happy Marshmallow Factory was sitting at around 50% symbol utilization and 52% compressed build output utilization. For those that haven’t played with pico-8, these numbers are arbitrary restrictions that exist to create a limited development environment in an effort to simulate a “retro console.” The first number, symbol utilization, is actual programming symbols such as ‘(‘, ‘:’, or ‘function’ with each symbol in source code counting as one use. You are only given 8192 symbols maximum which is quite small when you consider that even an empty function declaration consumes 5 symbols. Compressed build size is much more nebulous with the lua output bytecode being compressed and measured against a maximum size.
While neither the symbol count nor the compressed size are yet hitting problematic levels, they are both measures that you need to keep track of when building a larger pico-8 game as they are hard maximums. Important too is the fact that many techniques for keeping these numbers down are the opposite of what we think of as good coding practices today: global variables, short names for members, etc. Between these two facts it becomes especially important to track these values since my goals with HHMF are to improve data isolation, code readability, and most importantly, make the progression system more tweakable. And all of those are not necessarily good for either number.
The first changes I made was to start containing the data and methods that were only relevant to a specific state: menu, game, or credits. I did this by creating simple lua objects for the states that had their own ‘update’, ‘draw’, and ‘debug_draw’ methods as well as whatever local properties they need. This allowed the top-level update and draw methods to just call the current state’s method rather than determining the method based on a number which was done in multiple locations. It also allowed repeat variables between the states to use the same name (since they were now scoped to their object) such as the scroll factor used on both the menu and credit states. This change immediately improved isolation of about half the code though at this point only the menu and credit states have all their members isolated out of global state.
Overall, I felt that this change was worth it at the high level it was applied, and I would do it again in another pico-8 based game. The downsides of it is that symbol and compressed size numbers slipped about 5% each from the change. I believe the two big drivers of the slip are that any member variable or method accesses must now be prefixed with ‘self.’ (two symbols), and any member accesses are now string based dictionary lookups in the object since lua doesn’t have compiled types. Worse still is the fact that the conversion hasn’t been fully applied to the codebase and I believe the tax would be closer to 15-20% if completed.
To counter the issue there are two big tools at hand: continue to use globals for heavy use items, maintain functional programming discipline for as many functions as possible, and to create local copies in functions that repeatedly access the same value. The last one is a relatively micro-optimization since it is only a net positive change if there are at least three accesses in the case that there are no updates to the value. In the scenario that the value is being updated either in that function or another that it calls then it becomes more difficult to measure since additional code will be required to ensure synchronization between the original and local copies. Yuck.
At this point I weighed the initial state object conversion as a success and wanted to extend it to game objects. I did this in the same general form with a lua object having update and draw methods, as well as common elements such as position and animation data. This allowed me to create a generic draw method that could be shared rather than separate and repetitive implementations scattered throughout. To test the system I converted the robots to use it. Overall the number of lines of code didn’t change much with a 10% sloc decrease however the symbol and compression count degraded 6% from the conversion. That is a big slip considering the bot gameplay logic only represents about 7% of the codebase. I expect that continued conversion to the system will amortize some of the gameobject system’s overhead however it appears that the tax will be probably be consistent for conversions.
The refactoring is no longer looking so good. While only a small part of the code has actually been updated, the symbol count and compressed size are now both in the low 60% range. I expect that continued conversion will result in utilization hitting around 90% without any additions to the game such as new progression phases, map areas, and the like. This makes me really doubt this effort is worth it. Unfortunately, not refactoring the code leaves the game in a very difficult state for tuning and extending. I’m going to continue playing with it to see what I can achieve but this may be the last post for the game since fighting these limitations are less interesting to me. Meh.