Tag Archive for 'xna'

Fuuuuuuuuuu-

So we spent about 6 hours attempting, reattempting and double reattempting to give the GUI textbox support for multiple colors… which by itself isn’t all that hard, but then trying to word wrap at the same time made it a pain in the ass! Eventually we figured it out and we were so excited.

Then we found it had an incredible FPS drop with a lot of text…

…so we reverted…

…then we found out that even without multiple colors there was an insane FPS drop with a lot of text…

…back to the drawing board.

True story bro.

What a difference a skin makes

Update on the GUI, started working on skinning. As always, make sure to view it in HD:

HD link

From the ground up

Even though most of us are slightly derailed with real life shit, Arcadium Software has continued to progress on our flagship game, Zinger.

One interesting thing I keep reading on different sites is people referring to XNA as a beginner language for writing games. Although it can be interpreted this way, I have to disagree. In my opinion XNA (or C# w/ the XNA Game Studio… whatever) isn’t as much of a beginner language, but more that it has the possibility to be a rapid development language.

Yes, working with managed code is always easier than unmanaged code, but that doesn’t mean its anymore beginner friendly than the next. There is just as much of a learning curve writing C# applications as there are C++ applications. In the first few steps of writing a C++ application you echo “Hello, World!” to the console… and in C# its pretty much the same thing except you’re printing “Hello, World!” to a windows form.

Aside from that, coining it as beginner tends to assume it lacks the ability to be mastered… that there’s a skill cap on it. I’ve only been working with XNA a few months now and have already learned things I wish I knew at the start. Which is a perfect segway into the meat of this post…

When we first started writing Zinger it was with the mindset of “hurry! go go go go! do it! do it!”. We didn’t pay much attention to anything other than making leaps and bounds of progress. And it worked really well! We accomplished goals and milestones we could only dream about in the past. Only problem was the code became so concrete in its current application it made us worry. What if we want to use this code in a different game? Would we need to tear it all apart? Would it even be worth the effort?

About that same time we also started to notice a few issue with some of our implementations. There we limitations on features we knew needed adaptability down the road. Things like the GUI scaling properly as the resolutions changed while in-game… or the XML based menus requiring tricks and hacks for displaying screen resolutions. If you’re writing anything from scratch, you should NEVER have to use a trick or hack to make something work. Yes, I am personally responsible for most of the problems but hey… I’m new to the language and we didn’t set out to make an engine. That had to change.

After exploring a variety of artist styles, we’ve designed a new style of graphics we want our game to use, and we’re going to write an engine tailored to it. Why? Because we absolutely love the style and its very unique. Once we’ve completed the engine and Zinger, you will forever recognize the style to be an Arcadium Software product. Sort of how you can play almost any Source Engine game and say “yea, this is totally the Source Engine”.

As much as I would like to refrain saying we’re rewriting what we had from scratch, that’s exactly what we’re doing. Except now we already know how to do everything and have our code right in front of us to reference, which speeds things up tremendously. This time we have the right layout and I can’t even begin to explain how much better its already turning out.

In before tl;dr

Zinger! progress and stuff

New splash screen, the sunbursts are actually animated so they spin around… quite a trippy effect in full screen:
Arcadium Software

We made that for S & G’s. And now for a something completely different:

Chad started some clientside interpolation for our prediction. Our goal is to have a smooth and enjoyable multiplayer experience. Basically what happens is the client (you) doesn’t rely on the server 100% for exact values of visual things like, for instance, the position of a ball. If your screen rendered exactly what the server told you and the game happen to have a little bit of lag, you’d see the ball warp across the screen. Instead using prediction and interpolation, it smooths out the movement to look more realistic even though the lag is still there.

Additionally, Chad just barely started implementing the physics, BulletX. Really looking forward to see what he’s going to manage.

Me? I’ve been doing crappy shit like advancing our GUI library to include tools for building a settings menu and shit. It’s really boring and I can’t wait till its done. Even though I hate it so much, I know its really needed. Such a simple tool yet so necessary for any decent game. Some games missed out on this feature and it really shows the lack of attention to detail. Although Infiniminer is a wicked fun game, it really blows ass to have to exit the game and edit a text file to change settings… oh well.

I’ve also been reworking the audio system thus far. Mainly improving performance and moving away from the MediaPlayer library. That thing sucks all sorts of donkey anus and I won’t go into how laggy it can be (you play a song and it waits 3 seconds while it blocks the rest of the application before you can actually hear anything).

I also emailed Steam, which you can keep up-to-date with here.

XNA Color Chart

I don’t know if anyone needs this, but I sure as hell did:

http://www.foszor.com/blog/xna-color-chart/

Basically I made an app to generate the HTML code. Enjoy.

Zinger: Milestone 2

Zinger screenshot

Not going to bother reposting everything here, so visit this link.

Zinger! XNA

arcadiumlogo

Arcadium Software is well on its way into the Zinger! game developed in XNA.

Chad and I have had our struggles trying to create a game… mainly because we go “too big”. For two guys programming a game in their spare time, its a bit overwhelming to try and write a fully networked game engine from scratch… and then create a game for it. We gave it a shot but it was just a bigger undertaking than we had expected.

Seems like we couldn’t get our footing when it came to developing a stand alone game. We went back and forth on a “company” name (I use that term loosely, as its just a branding we’ve put on the software we develop), then it was the game engine itself, which we kept redoing and redoing from the ground up… ugh! What a mess!

We finally found the sweet spot. Not only do we have a name we love, but a game we love too! We said the hell with doing it all from scratch and use what tools are available to us out there. XNA has been a godsend! Sure its managed code and adds some prerequisites for the end user; like .NET Framwork 3.5 and XNA 3.0 Runtime, but it speeds up development time exponentially!

So far we have a working GUI, console and basic commands. Plus we’ve been able to connect to the server and transmit data back and forth (including syncing entities). We’re super excited!

One thing that’s really helped is we’ve set milestones for ourselves. Stuff like “compiling a level by tomorrow”, “connecting to the server in the next 6 hours”, “syncing the entity list by yesterday”. These are what keeps us driven and going in the right direction. We don’t always code the cleanest, but once its working we go back and sort it all out. SEEING our OWN progress has helped so much too, keeps us motivated.

If you want to see what we’ve got so far you can download it here. There’s no server to connect to right now, but enjoy anyways. Make sure you download the stuff I mentioned above.